Color range with DXVA2 vs OpenGL

[Urik]

GUI goes often completely unresponsive (navigation slider and time indication not advancing, it is impossible to stop playback) when playing a video with fps exactly matching the display refresh rate (60 fps in this case).

Now that makes sense, as I mostly deal with 60fps files. Along with weird "pixel undersampling" and gamma shift at 4K resolution, these were all reasons I stuck with OpenGL.
Just tried phone (4k 30p) files with DXVA display, and the GUI responsiveness is totally fine (win/nvidia), whereas with 4k 60p the play/pause lags and after a few presses freezes entirely for a few seconds (like some kind of buffer overflow, I don't know)

[eumagga0x2a]

There haven't been any nightlies reflecting the current state of development (which is entirely my fault as I can't make my mind regarding some aspects of color range handling), but there should not be any "gamma shift" depending on particular renderer anymore, this is all fixed in code (at least in my local codetree ).

What is not working properly as libswscale, which is normally in charge of color conversion in Avidemux, is not really helpful here, is bt.2020 (HDR) handling in yuv420p10le --> yuv420p conversion. Not only we have to lose 2 bits of color depth (this is unavoidable for now), but the projection of HDR onto normal 8-bit YV12 colorspace is wrong, independently of renderer.

[eumagga0x2a]

Along with weird "pixel undersampling" and gamma shift at 4K resolution, these were all reasons I stuck with OpenGL.

I actually managed to mix up three different contexts — HiDPI scaling, Qt event handling / multithreading and colorspace and -range conversion along the chain from decoder to render or encoder.

[Urik]

Yes I was using the wrong term, not gamma shift, it's more like flattened/de-contrasted look. Shadows are slightly raised, highlights lowered. Sounds indeed like may be color range related. But it's ok with OpenGL.
Here's the screens. I specifically disconnected 4K monitor and did this on 1080p one so there was no DXVA scaling issue.

These are from videogame, captured with Shadowplay (4k, 60p, BT.601, limited), VC++ build.
DXVA , OpenGL

The rest I tested with MinGW build but they look the same (I keep both but mainly use VC++ lately because it starts much faster)
DXVA - phone h264 4k 30p (BT.601 and FULL range) (personally, hard to see difference on that one, maybe because of full range?)
1080p 50p camera (bt.709, limited)
1080p 50p camera (bt.709, limited) 2

[eumagga0x2a]

Thank you, I'll look at all the provided screenshots and samples a bit later.

The rest I tested with MinGW build but they look the same (I keep both but mainly use VC++ lately because it starts much faster)

This is a very interesting observation as it matches the report by the project maintainer while I cannot reproduce it — both start very fast on my Window system, without any perceptible difference in startup time.

Just curious — do you have any network drives as bookmarks or recently accessed from Windows Explorer, but unavailable at the moment when you launch Avidemux?

There was a bug in Qt which caused long delays / lockups under these circumstances. It looked like it either was never fixed or regressed at least once. Maybe this is the reason as MinGW and VC++ builds use very different Qt versions.

[Urik]

Just curious — do you have any network drives as bookmarks or recently accessed from Windows Explorer, but unavailable at the moment when you launch Avidemux?

There was a bug in Qt which caused long delays / lockups under these circumstances. It looked like it either was never fixed or regressed at least once. Maybe this is the reason as MinGW and VC++ builds use very different Qt versions.

I don't have bookmarked / mapped network drives, just regular local network computers (under "Network" in explorer navigation pane). But I don't actually access them each Windows session, if that matters. I certainly didn't access them in last few days.
I do have lots of drives though. 8 drives, including C: , 3 of them are ssd, rest are hdd and one is a 4-disk array.

I just re-checked and VC++ version takes just under a second to launch, MinGW takes about 2.5 seconds. That is regardless of whether I pass input file to open during launch.

My laptop, just checked, which has much more basic setup of just C: ssd and one hdd, on it, MinGw version starts as fast as VC++. Same Win10 os.

[eumagga0x2a]

Well, that can explain why I don't see longer startup time with MinGW.

Regarding color range with DXVA2 renderer, I agree that greyish pictures match limited range not stretched to full. This is quite troubling as it is the opposite to what I see both on my HiDPI laptop and on normal DPI desktop with DXVA2 where I have to shrink color range to avoid losing details in light and dark areas.

I attach a test JPEG image. If color range is handled correctly, the leftmost stripe is fully black and the next one is dark but not black while the rightmost, slim one is completely white with the previous, also slim stripe being light-gray.

The build you run should fail the test with DXVA2, my private one as seen on the attached screenshot passes.

[eumagga0x2a]

I've split the topic, sacrificing your post which was perfectly on topic in https://avidemux.org/smif/index.php/topic,19231.0.html before I hijacked the subject, my apologies.

[Urik]

I've split the topic

Good, I was aware we were getting off topic there.

I tried the file, but the jpeg file displays normal for me even with DXVA. Actually, it displays just as it would in an image viewer. Even hiDPI-related "pixelization" didn't show.

However, once I converted it to h264, I got the washed-out image as expected (in Avidemux with DXVA).
I went an measured the edges, and they were precisely 16/235 instead of 0/255

And then it hit me with deja-vu, I think we already discussed it months before here but I forgot it all by now.
It happens (for me) on PC with Nvidia card.

On laptop, which uses Intel graphics as default output (outside of games), the same file plays fine with DXVA.
And on PC, there is an option in Nvidia Control Panel to override video gamma settings for video players. If I set it to full range (override), it solves the problem.
So it's something specific between Avidemux and Nvidia card/driver which makes Nvidia output limited?

Oh, I found my older post on this,

But I've finally figured the washed blacks (gamma) issue in Avidemux when DXVA is used with Nvidia card - there's an option in Nvidia Control Panel that can force (override) color settings. After setting gamma to Full Range (0-255), it shows it correctly now (with DXVA, but it was never a problem with OpenGL).
<...> So there's maybe some misinterpretation going on between Avidemux and Nvidia?

Wrote that literally a couple months ago and I forgot already.

I attached the mp4 file I used packed in zip

[eumagga0x2a]

I tried the file, but the jpeg file displays normal for me even with DXVA. Actually, it displays just as it would in an image viewer. Even hiDPI-related "pixelization" didn't show.

I never experienced this pixelization with DXVA2 with HiDPI displays, only with the unaccelerated Qt renderer. Must be again some setting in the graphics driver.

However, once I converted it to h264, I got the washed-out image as expected (in Avidemux with DXVA).
I went an measured the edges, and they were precisely 16/235 instead of 0/255

x264 expects by default limited color range as input and outputs by default limited color range, i.e. when creating a video from a JPEG image, the full color range of the image needs to be shrinked else details in dark and bright areas are lost.

It happens (for me) on PC with Nvidia card.

On laptop, which uses Intel graphics as default output (outside of games), the same file plays fine with DXVA.
And on PC, there is an option in Nvidia Control Panel to override video gamma settings for video players. If I set it to full range (override), it solves the problem.

I didn't have a chance to re-test with Nvidia yet, but the question is which setting is the default? I experienced so far only limited range video being stretched to full range on Windows and didn't attribute it to a possibly non-standard configuration. In general, this all is unsettling as it means that no consistent solution for DXVA2 is possible.

So it's something specific between Avidemux and Nvidia card/driver which makes Nvidia output limited?

No, definitely not. I wish I knew a way to request or forbid color range expansion from the graphics driver, this would immediately solve the problem.

Oh, I found my older post on this,

But I've finally figured the washed blacks (gamma) issue in Avidemux when DXVA is used with Nvidia card - there's an option in Nvidia Control Panel that can force (override) color settings. After setting gamma to Full Range (0-255), it shows it correctly now (with DXVA, but it was never a problem with OpenGL).

OpenGL is a different path.

[Urik]

x264 expects by default limited color range as input and outputs by default limited color range, i.e. when creating a video from a JPEG image, the full color range of the image needs to be shrinked else details in dark and bright areas are lost.

The video had correct colors, I made sure. I used Adobe Premiere because it was just faster for me than the time I'd spent figuring the right ffmpeg syntax and potential troubles with all the filters and colorspace conversion.

I didn't have a chance to re-test with Nvidia yet, but the question is which setting is the default? I experienced so far only limited range video being stretched to full range on Windows and didn't attribute it to a possibly non-standard configuration. In general, this all is unsettling as it means that no consistent solution for DXVA2 is possible.

The default setting is to allow program to control color. When the second option ("With the NVIDIA settings") is selected, it allows to set range (in "Advanced" tab) to either limited or full. There's a separate setting for each connected monitor.