Avidemux converts MOV video with much more contrast into MP4 than original

[thoste]

In general I am satisfied with the resulting videos from Avidemux.
But now I experienced a heavy conversion problem:

I got a *.MOV video and wanted to convert it to an *.MP4 video.
Furthermore I
- reduced the bitrate to 3500 kbps
- resized it to a resolution of 720 * 1280
- and rotated it by 90 deg.

As you can see I didn't change any color or contrast parameter.

When I look now at the resulting MP4 video then it appears with a heavy increased contrast.
The horizon over the ocean is almost white whereas the original shows clouds and light grey sky.

When I convert other videos this never happened before (with MP4 videos).

Reducing contrast or brightness with Avidemux filter does NOT help.

Whats wrong?

Is it because of the *.MOV (palette)?

How can I really keep the colors of the original MOV video. Nothing should be changed

I have put (short) original and result video into zip file.
Downloadable here:

https://filetransfer.io/data-package/cffLeErm#link

[eumagga0x2a]

I get pretty good results with RGB Hable in adaptive mode and both saturation and boost increased by factor 1.10 (clipping: compression). Indeed, no chance without adaptive mode and therefore with the default "Fast YUV" algo.

[Elstar`]

Actually, there is no color information in converted video (original says it's BT.2020). And it appears, you have converted 10-bit HDR color to 8-bit, it is definitely not lossless.

[eumagga0x2a]

Actually, there is no color information in converted video (original says it's BT.2020). And it appears, you have converted 10-bit HDR color to 8-bit, it is definitely not lossless.

Of course it is not lossless. The tone mapping algoriths the TO used was unsuitable for HDR to SDR conversion in case of the sample video.

[thoste]

I get pretty good results with RGB Hable in adaptive mode and both saturation and boost increased by factor 1.10 (clipping: compression). Indeed, no chance without adaptive mode and therefore with the default "Fast YUV" algo.

Thank you for answer.

BUT where do I find (for HEVC encoding) "RGB Hable in adaptive mode"?

I have searched all video parameters without success.

Or is it a filter?
Which?

@Elstar: How can I keep 10-bit HDR colorspace (for HEVC encoding)?

[sark]

BUT where do I find (for HEVC encoding) "RGB Hable in adaptive mode"?

I have searched all video parameters without success.

The button menu. It will appear to the right of the filter preview button when relevent content is loaded.

Note: No warning is given if you save in copy mode without the required encoding.

[thoste]

BUT where do I find (for HEVC encoding) "RGB Hable in adaptive mode"?

I have searched all video parameters without success.

The button menu. It will appear to the right of the filter preview button when relevent content is loaded.

Note: No warning is given if you save in copy mode without the required encoding.

Maybe I am stupid.
But here is no button right of "Preview" button in Filter section (see attached snapshot).
Where is it exactly?

You cannot view this attachment.

[sark]

@thoste..In the main AVD window there is a button menu bar with Open, Save, Info and Filter Preview buttons. It will appear here when applicable content is loaded.

You cannot view this attachment.

[eumagga0x2a]

thoste, why do you use the unaccelerated "Qt" path (indicated by "RGB" in the status bar)? Does everything else crash?

"Qt" video display is meant to be used as the last resort, it performs scaling and pixel format conversion for display exclusively on the CPU instead of invoking fast and efficient paths offered by the graphics card via interfaces like DirectX (in Avidemux: "DXVA2") on Windows, VDPAU and VA-API (in Avidemux: "LibVA") on Linux or OpenGL on all platforms.

HDR tone mapping (HDR to SDR conversion) in Avidemux is technically implemented as a pre-processing step, i.e. tone mapping is performed between video decoder and the editor cache. Video filters live between editor cache and video encoder.

[thoste]

I get pretty good results with RGB Hable in adaptive mode and both saturation and boost increased by factor 1.10 (clipping: compression). Indeed, no chance without adaptive mode and therefore with the default "Fast YUV" algo.

Interesting. It works.
Thank you.

I didn't know this setting before. I thought all color manipulations are done with color filters.

[thoste]

thoste, why do you use the unaccelerated "Qt" path (indicated by "RGB" in the status bar)? Does everything else crash?

"Qt" video display is meant to be used as the last resort, it performs scaling and pixel format conversion for display exclusively on the CPU instead of invoking fast and efficient paths offered by the graphics card via interfaces like DirectX (in Avidemux: "DXVA2") on Windows, VDPAU and VA-API (in Avidemux: "LibVA") on Linux or OpenGL on all platforms.

I never changed this setting.

How can I change this?

When I go to Preferences--->Display and change it from "QT" to lets say "DXVA2" and click OK
then "RGB" in the status bar remains.

You are talking about using a graphic card.
I have no separate graphic card.
I am using the embedded GPU in my Intel Core-i-12000 CPU.
This GPU is powerful enough to show videos without stuttering or any other problems.

However I am willing to improve Avidemux setting.
If I should switch from RGB to another display mode (e.g. DXVA2) then how can I achieve this?

Thank you in advance

[eumagga0x2a]

How can I change this?

When I go to Preferences--->Display and change it from "QT" to lets say "DXVA2" and click OK
then "RGB" in the status bar remains.

The change has no effect on currently loaded video, so close it and load again (in doubt: close Avidemux and launch it again). If you still get the unaccelerated fallback renderer instead of "DXVA2" despite "DXVA2" being selected in the Preferences, please provide admlog.txt from launching Avidemux and loading a video.

I have no separate graphic card.

This doesn't matter, the GPU just shares the same piece of silicon (and the same physical memory) with the CPU. The fallback path avoids interacting with the graphics driver, providing an already converted and scaled to screen resolution picture – that all done on the CPU, which is orders of magnitude slower at this.

[Elstar`]

@Elstar: How can I keep 10-bit HDR colorspace (for HEVC encoding)?

For HEVC, try profile main10? Or output bit depth 10 if you use advanced configuration. Then set on "display" tab something that matches your exact color information (it's just metadata setting, though).

[eumagga0x2a]

For HEVC, try profile main10? Or output bit depth 10 if you use advanced configuration.

This would be pointless as Avidemux can pass only 8-bit YUV 4:2:0 down the filter chain to video encoders. The only way to preserve high bit depth is to use copy mode.

[thoste]

How can I change this?

When I go to Preferences--->Display and change it from "QT" to lets say "DXVA2" and click OK
then "RGB" in the status bar remains.

The change has no effect on currently loaded video, so close it and load again (in doubt: close Avidemux and launch it again). If you still get the unaccelerated fallback renderer instead of "DXVA2" despite "DXVA2" being selected in the Preferences, please provide admlog.txt from launching Avidemux and loading a video.

Ok, I changed the settings in Preferences--->Display, then exit Avidemux, then re-launched it and load video.
Still "RGB" in status bar.

Here is my admlog.txt:

See attached zip file

You cannot view this attachment.