Clip cut with Avidemux no longer listed as HDR in Mediainfo?

[tecc]

I have a collection of movie clips on my flash drive to test the playback ability of standalone players. I've recently added a 2 min HDR clip of a movie encoded in 2160p with Dolby Vision. When I check the original file, Mediainfo reports:

HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU

but after saving the clip in Avidemux 2.6 set to video:copy, audio:copy, mkv, Mediainfo shows this line is gone. Is Avidemux dropping this info or simply the flag? Or is Mediainfo at fault here?

[szlldm]

2.6 is a very ancient version. Try latest release (2.8.1)

[sark]

2.6 is a very ancient version. Try latest release (2.8.1)

Better still, version 2.8.2.

https://www.avidemux.org/nightly/win64/

[eumagga0x2a]

2.6 is a very ancient version. Try latest release (2.8.1)

Better still, version 2.8.2.

https://www.avidemux.org/nightly/win64/

Only builds prior to Sept 2023, see https://avidemux.org/smif/index.php/topic,20301.0.html

[tecc]

I get the same result with 2.8.1,

HDR format  : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU

is lost. Installing the 2.8.2 nightly results in this error message:
---------------------------
Avidemux 2.8.2.230924 (64-bits Release) Setup
---------------------------
Unable to elevate, error 0:\Users\tecc\AppData\Local\Temp\nst3293.tmp
---------------------------
OK 
---------------------------

[eumagga0x2a]

Installing the 2.8.2 nightly results in this error message:

Was I unclear?

Only builds prior to Sept 2023, see https://avidemux.org/smif/index.php/topic,20301.0.html

If you re-encode, the video will be SDR, of course. If you copy, the video stream will be unchanged, but container metadata might need manual configuration in the extended settings of the muxer (available only for MKV and WebM muxers). "Dolby Vision" is just a trademark, mediainfo should report the actual color properties used by the video.

[tecc]

Was I unclear?

Only builds prior to Sept 2023, see https://avidemux.org/smif/index.php/topic,20301.0.html

Kinda. Only builds prior to Sept 2023 do what? Drop the info? The link you provided leads to the forum's main page, not a specific topic.

If you copy, the video stream will be unchanged, but container metadata might need manual configuration in the extended settings of the muxer (available only for MKV and WebM muxers). "Dolby Vision" is just a trademark, mediainfo should report the actual color properties used by the video.

When I post the video part of Mediainfo's output, the forum software flags it as spam. But there's not much color properties mentioned anyway, only this:

High Efficiency Video Coding
Main 10@L5@High
Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU.

I wasn't aware manual configuration in the extended settings of the muxer was necessary to carry over that information.

[eumagga0x2a]

Only builds prior to Sept 2023 do what?

Are not broken. The latest VC++ ("vsWin64") build contrary to latest MinGW ("win64") buildes might be actually working, but I cannot tell for sure at the moment.

The link you provided leads to the forum's main page, not a specific topic.

Factually incorrect. The link points directly to the pinned topic that explains why well-meant advice by sark is very wrong at the moment.

When I post the video part of Mediainfo's output, the forum software flags it as spam.

CleanTalk, an external anti-spam service, used by this forum, indeed has a strange allergy against MediaInfo output, probably due to the presence of @ sign. Please attach the info as a text file instead of trying to post it inline. I'm sorry for inconvenience.

I wasn't aware manual configuration in the extended settings of the muxer was necessary to carry over that information.

The container-level metadata may be not needed for some video players while others may insist on it being present and correct.

[sark]

Installing the 2.8.2 nightly results in this error message:

Was I unclear?

Only builds prior to Sept 2023, see https://avidemux.org/smif/index.php/topic,20301.0.html

There are currently ten 2.8.2 versions that are pre Sept 2023. Are these considered unbroken?
Also. How does this affect the zipped r230924 Qt5.8 version. I'm having no issues with this (Win 7 offline). Is there any reason to step back a build. Or is this just an executable issue, and only affecting installation.

[eumagga0x2a]

There are currently ten 2.8.2 versions that are pre Sept 2023. Are these considered unbroken?

Yes, take the latest pre-Sept one or build from the current git master yourself. The issue is presumably with official packaging, not with code, albeit the dependency on libbrotlidec looks strange for me. I cannot rule out that MXE has changed something again. It is a fast moving target, difficult to chase.

How does this affect the zipped r230924 Qt5.8 version. I'm having no issues with this (Win 7 offline).

I cannot test on obsolete platforms like Windows 7, but on Windows 10 and 11, icu4c libraries, now needed by Qt, are not packaged by the official packaging scripts, making it impossible to run at least the graphical executable (the command line one might be fine).

Additionally, the NSIS installer fails to elevate with the shipped UAC.dll, making it impossible to use the installer the way it is intended to be used.