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
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.
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.
Quote from: Elstar` on August 10, 2024, 05:39:34 PMActually, 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.
Quote from: eumagga0x2a on August 10, 2024, 04:14:54 PMI 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)?
Quote from: thoste on August 12, 2024, 02:20:32 PMBUT 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.
Quote from: sark on August 12, 2024, 04:33:48 PMQuote from: thoste on August 12, 2024, 02:20:32 PMBUT 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?
snaparr20240813-090316.png
@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.
Untitled-1.jpg
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.
Quote from: eumagga0x2a on August 10, 2024, 04:14:54 PMI 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.
Quote from: eumagga0x2a on August 13, 2024, 09:36:01 PMthoste, 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
Quote from: thoste on August 15, 2024, 06:05:04 AMHow 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.
Quote from: thoste on August 15, 2024, 06:05:04 AMI 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.
Quote from: thoste on August 12, 2024, 02:20:32 PM@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).
Quote from: Elstar` on August 16, 2024, 12:11:43 AMFor 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.
Quote from: eumagga0x2a on August 15, 2024, 01:53:06 PMQuote from: thoste on August 15, 2024, 06:05:04 AMHow 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
admlog.zip
Thank you, from
[admD3D_initD3D9Ex] 04:19:33-111 D3D Device: Intel(R) UHD Graphics 730, Vendor: 8086, Device: 4682, Rev: c, Driver Version: 8725724284655062
we cannot get a hw surface for YV12 pixel format:
[dxvaRender] 04:20:32-472 creating Dxva2/D3D render.
[init] 04:20:32-472 Initializing dxva2/D3D render
[init] 04:20:32-473 D3D Checking device capabilities
[init] 04:20:32-473 Power of 2 : 0
[init] 04:20:32-473 Square only: 0
[ADM_FAILED] 04:20:32-473 Failed with error code=0x8876086a
[init] 04:20:32-473 D3D YV12 not supported
[setup] 04:20:32-473 D3D (re)Setting up
[setup] 04:20:32-521 DXVA2Render : device created in D3D9Ex mode
[ADM_FAILED] 04:20:32-521 Failed with error code=0x8876086c
[setup] 04:20:32-521 D3D Cannot create surface
[init] 04:20:32-521 Dxva/D3D setup failed
[~dxvaRender] 04:20:32-521 dxva2/D3D clean up
[cleanup] 04:20:32-521 D3D cleanup
[~dxvaRender] 04:20:32-526 dxva2/D3D cleaned up
[spawnRenderer] 04:20:32-526 Dxva2 init failed
Just in case, it is Windows 8 (which is unsupported), isn't it? Is already the most recent graphics driver version installed?
Anyway, if DirectX display cannot be used, please try OpenGL.
v2.8.2r240804free[x64]
Just curious, is it an official build put into a differently named directory, a third-party repackaged official build, a local build or a third-party inofficial build?
I am using Windows 10
More precisely: Microsoft Windows [Version 10.0.19045.4780]
Driver version snapshot from HWinfo64: See attached snapshot
I downloaded latest *.zip package from
http://www.avidemux.org/nightly/win64/
and renamed (as suggested) avidemux.exe to avidemux_portable.exe
Switching to OpenGL and restarting Avidemux and reloading the *.MOV video doesn't help either.
Status Bar still shows RGB
Used Driver.png
Did you actually enable OpenGL or only switch the video display to OpenGL? Both must be enabled and Avidemux must be restarted when the global switch for OpenGL wasn't enabled for this interface to be used (for Avidemux to try to use OpenGL).
Will look into Windows version detection in Avidemux, something might be off there.
Quote from: eumagga0x2a on August 18, 2024, 03:31:44 PMDid you actually enable OpenGL or only switch the video display to OpenGL? Both must be enabled and Avidemux must be restarted when the global switch for OpenGL wasn't enabled for this interface to be used (for Avidemux to try to use OpenGL).
Will look into Windows version detection in Avidemux, something might be off there.
OpenGL is installed.....and it doesn't work either :-(
From my point of view: If OpenGL is installed it is always automatically enabled (=can be accessed by other prgms like Avidemux).
If I am wrong: How can I enable an installed OpenGL?
Do I have to do it in Avidemux or in Windows?
Let me ask for another confirmation:
Display mode is only important for playing videos and not for encoding.
So if my videos play without problems in RGB mode then it is not really urgent to switch display mode.
Correct?
Quote from: thoste on August 19, 2024, 02:24:13 PMFrom my point of view: If OpenGL is installed it is always automatically enabled (=can be accessed by other prgms like Avidemux).
The OpenGL interface, implemented by the graphics card driver, can be accessed by applications if they choose to do so. In case of Avidemux, the user determines whether Avidemux should try to use OpenGL.
[initGUI] 04:19:33-042 OpenGL enabled at build time, checking whether we should run it... no.This line means that the user (you) had not enabled OpenGL in Avidemux by the time as that Avidemux log file was created.
Quote from: thoste on August 19, 2024, 02:24:13 PMDo I have to do it in Avidemux or in Windows?
In Avidemux Preferences --> tab "Display" --> "Enable OpenGL support".
Quote from: thoste on August 19, 2024, 02:24:13 PMDisplay mode is only important for playing videos and not for encoding.
Right. But when playback is involved, like for locating suitable start and end point, it is mind-boggingly wasteful to scale pictures for display on the CPU instead of in the GPU.
Quote from: thoste on August 19, 2024, 02:24:13 PMSo if my videos play without problems in RGB mode then it is not really urgent to switch display mode.
It is urgent to find and assess bugs in Avidemux, so that some of them can be fixed in time for the 2.8.2 release. This is the reason I am here.
I've pushed a tentative and entirely untested patch (https://github.com/mean00/avidemux2/commit/f5a1883da1d1625e2a2cefbac22f965840c3cd6a), which should make DirectX AKA "DXVA2" video display in Avidemux work for you, to the repository. I'll test it for regressions tomorrow. However, it is unlikely that a new official nightly will be built soon.
Even if the patch works as intended, the benefit of using the "DXVA2" display will be somewhat lower as Avidemux will have to perform YV12 to RGB conversion on the CPU. At least the most expensive scaling step will be done in the GPU then.