Question / Help Quick Sync / NVENC YUV Full Range Color

DarwinTheCat

New Member
Either streaming or recording with OBS Studio using GPU encoding (tested with both Quick Sync and NVENC) does not output full color range video. My videos show up way too dark. I'm using NV12, 709 and Full Range in OBS Settings.

I also tested using the x264 encoder and the encoding works properly using the same settings. So it seems like an issue with Quick Sync and NVENC only.

Is this a bug in OBS Studio? Or a limitation of GPU encoding?

Log file: https://gist.github.com/anonymous/e98094ddc37e37e10254
 

sam686

Member
videos being way too dark is a sign that the players are either not seeing a full-range flag or may be ignoring it. MediaInfo may show more details on if color range full/limited, and color matrix bt709/bt601 is flagged correctly, which OBS-mp don't appear to correctly flag it automatically in h264 streams/recordings.

A custom x264 option fullrange=on may be used to flag the video as a full range, together with OBS full range mode.
There is also a custom x264 option colormatrix=bt709 / bt601, and should match what OBS setting is set to.

I wonder if future version of OBS-mp would tell the encoder what the range and color matrix is set to?
EDIT: bt601 is not a correct x264 setting
 
Last edited:

Suslik V

Active Member
How do you check it? I mean - 'show up way too dark' ? What player or observation conditions?

There is image: http://referencehometheater.com/wp-content/uploads/2014/06/Contrast-Featured.png
I pick it from this thread: Colors (YUV full/partial and 601/709 (thanks to Jack0r and denilsonsa)

Use it for the fast check. Import in OBS Studio as image source. Make test recordings and make sure that you are running right player and codec (or right target environment - TV set, phone, tablet etc.) when checking.

Also, you may check this image: http://cdn.avsforum.com/3/35/35bd60ee_vbattach32137.jpeg it describes how look the color errors in conversion between 601/709 to RGB (display), if any. Because 'too dark' - it is not clear description (as for me) when you are talking about spaces, ranges and so on. The top two images has right conversions. The original link is from this forum: http://www.avsforum.com/forum/139-display-calibration/637711-rec-601-vs-rec-709-when-do-i-use.html

Few steps aside under the spoiler.
When complete the tests, read the link:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd206750(v=vs.85).aspx said:
...Studio video RGB [Partial color range] is the preferred RGB definition for video in Windows, while computer RGB [Full color range] is the preferred RGB definition for non-video applications...
As mentioned in the link above, nominal ranges for Y,U,V is 'Partial' (in OBS Studio terms)

In most cases, what you see as 'true' color, without any clipping - result of the right scaling to (from) the partial color range video on your TV set (monitor).

The main goal of the casual OBS Studio user is to match the output to the target display environment.

Common value for YUV color range in OBS Studio is 'Partial'.

Current implementations of hardware based codecs in OBS Studio completed via MS Media Foundation (no direct api use). Wait for the future updates of the Studio and Media Foundation, if you experience 'limitations'.
 

DarwinTheCat

New Member
How do you check it? I mean - 'show up way too dark' ? What player or observation conditions?

There is image: http://referencehometheater.com/wp-content/uploads/2014/06/Contrast-Featured.png
I pick it from this thread: Colors (YUV full/partial and 601/709 (thanks to Jack0r and denilsonsa)

Use it for the fast check. Import in OBS Studio as image source. Make test recordings and make sure that you are running right player and codec (or right target environment - TV set, phone, tablet etc.) when checking.

Also, you may check this image: http://cdn.avsforum.com/3/35/35bd60ee_vbattach32137.jpeg it describes how look the color errors in conversion between 601/709 to RGB (display), if any. Because 'too dark' - it is not clear description (as for me) when you are talking about spaces, ranges and so on. The top two images has right conversions. The original link is from this forum: http://www.avsforum.com/forum/139-display-calibration/637711-rec-601-vs-rec-709-when-do-i-use.html

Few steps aside under the spoiler.
When complete the tests, read the link:

As mentioned in the link above, nominal ranges for Y,U,V is 'Partial' (in OBS Studio terms)

In most cases, what you see as 'true' color, without any clipping - result of the right scaling to (from) the partial color range video on your TV set (monitor).

The main goal of the casual OBS Studio user is to match the output to the target display environment.

Common value for YUV color range in OBS Studio is 'Partial'.

Current implementations of hardware based codecs in OBS Studio completed via MS Media Foundation (no direct api use). Wait for the future updates of the Studio and Media Foundation, if you experience 'limitations'.

I found the culprit - it's the Media Source plugin. I have a dedicated PC used for streaming. My gaming PC sends (via OBS) game capture only to the OBS instance on the streaming PC via RTMP. It is of course captured using the Media Source plugin which seems the be causing the limited range issue.

When recording directly on my gaming PC using Quick Sync the colors look perfect - full range. But once streamed to the second PC (at 200,000 bitrate via RTMP), what shows up on the OBS preview (via Media Source plugin) is indeed at limited range (blacks getting crushed).

Is there any way to tell the Media Source plugin to explicitly decode using 709/Full range?
 

DarwinTheCat

New Member
Did some additional tests to confirm that the issue is caused by the Media Source Plugin.

I'm using the following image to test black color depth: https://i.imgur.com/aRGp76Gr.jpg

- (Screenshot) From my Gaming PC: Using VLAN to play the RTMP stream of the test image: http://i.imgur.com/yEApsgJ.png (Result: Accurate black levels relative to the test image)

- (Screenshot) From my Streaming PC: Using VLAN to play the RTMP stream of the test image: http://i.imgur.com/KSyhM8x.png (Result: Accurate black levels relative to the test image)

- (Screenshot) From my Streaming PC: OBS Media Source playing the RTMP stream of the test image: http://i.imgur.com/AFwBSM5.png (Result: Wrong black levels)

- (Video) Local recording of the test image using Image Source: https://www.dropbox.com/s/xrbrwoln1dmvz95/Streaming PC Image Source.mp4?dl=1 (Result: Accurate black levels relative to the test image)

- (Video) Local recording of the test image using MediaSource (Streamed from Gaming PC): https://www.dropbox.com/s/5dg88d20508y5pz/Streaming PC Media Source Source.mp4?dl=1 (Result: Wrong black levels)

As you can see, the issue is entirely caused by the Media Source plugin. Any ideas or workaround?
 
Last edited:

Suslik V

Active Member
Think your player output at RGB directly to the monitor?

My screenshots from 709 Full and 709 Partial: http://screenshotcomparison.com/comparison/166388
original image as Image source: https://sunmaiblog.files.wordpress.com/2010/10/1178968055464.jpg (actually, it's jpeg, and I have no time for good comparison, clear image etc.)
As for me, difference almost unnoticeable.
But when I play my 'Full range record' with this vlc 2.2.1, I see on my monitor horrible loss of grey from #1 to #241 (whole column) and from #1 to #16 (whole row). On the same monitor, original image view via XnView 2.32 and 'Partial range record' via vlc 2.2.1, hasn't such horrible issue.

So,
...Any ideas or workaround?
forget about Full range.

Log from test recordings completed at friend's work environment attached.
 

Attachments

  • 2016-03-22 23-58-37.txt
    21.6 KB · Views: 30

DarwinTheCat

New Member
Think your player output at RGB directly to the monitor?

My screenshots from 709 Full and 709 Partial: http://screenshotcomparison.com/comparison/166388
original image as Image source: https://sunmaiblog.files.wordpress.com/2010/10/1178968055464.jpg (actually, it's jpeg, and I have no time for good comparison, clear image etc.)
As for me, difference almost unnoticeable.
But when I play my 'Full range record' with this vlc 2.2.1, I see on my monitor horrible loss of grey from #1 to #241 (whole column) and from #1 to #16 (whole row). On the same monitor, original image view via XnView 2.32 and 'Partial range record' via vlc 2.2.1, hasn't such horrible issue.

So,

forget about Full range.

Log from test recordings completed at friend's work environment attached.

Forget about Full range? Nope. Already fixed it from the source code and recompiled the plugin. Works perfectly now. Let me know if you want the fixed DLLs.
 

DarwinTheCat

New Member
Change repository, and we all will use it :)

P.S. forgot to add: screenshots for comparison were made by vlc itself. It is important.

Already notified Jim directly of the issue at #obs-dev. He pointed out where the bug was located and I did the rest. Not sure what priority this will be given - hopefully not the same as the Lanczos downscale filter (still broken).
 

Videophile

Elgato
Already notified Jim directly of the issue at #obs-dev. He pointed out where the bug was located and I did the rest. Not sure what priority this will be given - hopefully not the same as the Lanczos downscale filter (still broken).
Are you saying the lanczos filter in OBS Studio is also broken?
 

UselessMouth

New Member
Forget about Full range? Nope. Already fixed it from the source code and recompiled the plugin. Works perfectly now. Let me know if you want the fixed DLLs.
Can you please share with us with your fixed dlls for Media Source Plugin? Getting sick with those crashed blacks in my local recordings.
Thanks!
 

dodgepong

Administrator
Forum Admin
@DarwinTheCat, please submit your changes via pull request if it is something you think everyone who uses OBS could benefit from. That way, it can be integrated into the whole project. If you email someone a code snippet, it's much less likely to get into the code base because that is harder to deal with.
 

sam686

Member
OBS + x264 full range does appear to be correct without needing custom options. Color space 709 is flagged ok without the need for any custom option, but not 601.
OBS-mp + quicksync never flags colorspace or full range option, which causes crushed blacks/whites and wrong colors.

VLC 2.2.2 with hardware YUV conversion disabled appears to correctly display 601 / 709, full / limited range.
ffdshow tryouts rev4534 or newer with RGB output also appears to correctly display colors that is flagged, and range.

When the colorspace 601/709 not flagged, this makes VLC always use 601 , but ffdshow use 709 for 720p and higher. ffdshow does output at 601 at any resolution when h264 is flagged to use it. (x264 colormatrix=bt470bg works)

I later found that colormatrix=bt470bg appears to be a correct setting when OBS is set to "601" (x264 bt601 don't work).

Hardware encoders could use some h264 colorspace/range flagging fix...
 
Top