View Issue Details

IDProjectCategoryView StatusLast Update
0000456madVRbugpublic2018-01-14 13:13
Reporternomakewan Assigned Tomadshi  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0000456: Videos with RGB Color Space render with a distinct magenta hue
DescriptionIf a video is encoded with RGB color space, madVR renders the colors incorrectly with a heavy magenta hue over the whole image. Playing the troublesome videos in VLC, WMP or MPC-HC (EVR Custom) does not cause the color shift, so it does appear to be a madVR-specific issue.

Sample mediainfo: http://pastebin.com/21bp4Bct
Sample clip: https://mega.nz/#!DwNklAQT!S8ic2EdhHG2NE324PD4r-OSJTP12hV1xeOjqKdCPkbw
Steps To ReproducePlay a video with RGB color space.
TagsNo tags attached.
madVR Version0.91.4
Media Player (with version info)MPC-HC x86 1.7.10
Splitter (with version info)LAV Splitter 0.68.1
Decoder (with version info)LAVFilters 0.68.1
DecodingCUDA
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerNVidia
GPU ModelGeForce 760 GTX
GPU Driver Version376.19

Activities

madshi

2016-12-15 10:00

administrator   ~0001535

This looks like a bug in madVR, but also in LAV. The bug in LAV is that it sends YCbCr 4:2:0 (NV12) although the content really seems to be RGB. The bug in madVR is that it treats the content as if it were RGB, while LAV sends NV12.

You can workaround the issue for now by pressing Ctrl+Alt+Shift+M twice to switch the decoding matrix from GBR to BT.709. Or by adding the file name tag "matrix=709" to the file name.

madshi

2016-12-15 11:28

administrator   ~0001536

After discussing this with nevcairiel, our opinion is that the video file is broken. It claims to be "GBR", but actually it has to be treated as NV12 YCbCr, otherwise it won't display correctly. So the file appears to be incorrectly flagged as "GBR".

The magenta coloring comes from the fact that madVR is cleverer than the other renderers. madVR actually sees that the file claims to be "GBR" and thus treats it that way. The other renderers are not trying that hard, they simply treat it as NV12 and thus display it "correctly".

The fix will be that madVR will check if LAV sends NV12 and in that case madVR will ignore the "GBR" flag.

nomakewan

2016-12-15 11:33

reporter   ~0001537

Excellent to hear! After going over the files on my end, the files that first exhibited this behavior do indeed behave correctly if "matrix=709" is appended to their filenames. In addition, the test file I created to mimic these found files was created using the "--colorspace GBR" flag in x264 set which, according to its documentation, is just metadata and not actually instructing the encoder to enforce an actual color space while encoding. Thus it appears that yes, the files in question are all broken due to improper encoder settings, which is probably why in all my years of watching videos I've never come across one until now.

Thanks for the speedy fix! Nothing like a little robustness for unexpected situations!

Issue History

Date Modified Username Field Change
2016-12-15 02:53 nomakewan New Issue
2016-12-15 10:00 madshi Note Added: 0001535
2016-12-15 10:00 madshi Assigned To => madshi
2016-12-15 10:00 madshi Status new => assigned
2016-12-15 11:28 madshi Note Added: 0001536
2016-12-15 11:33 nomakewan Note Added: 0001537
2018-01-14 13:13 madshi Status assigned => closed
2018-01-14 13:13 madshi Resolution open => fixed