MPC-BE colors wrong ?

[gregalan]

I was testing media players to see which ones gave the most pleasing output when i noticed the colors look very different in MPC-BE than in the other players I tested.
The reds looked very bad.

The players I tested:
MPC-BE
MPC-HC
MPDN
SMplayer

So I created an avs with ColorBarsHD(), MPC-HC, MPDN, and SMplayer all showed pretty much the same (although I did have to use FFmpeg to convert the ColorBars script to a lossles x264 file for Smplayer, I confirmed it still looked the same in the other players).
MPC-BE showed the red and the green to be pretty far off from the other players.

All settings were as close as possible in all the players.

Anyone know why MPC-BE is outputting the colors differently ?

Here are two pics to compare:


[Attachment 32870 - Click to enlarge]

[Attachment 32871 - Click to enlarge]

I found something odd, Virtualdubs display panes shows almost exactly the same colors as MPC-BE ?

[jagabo]

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830
See a few posts earlier in that thread for more info. VirtualDub always uses rec.601 to convert YUV to RGB for display. And so apparently is MPC-BE.

[gregalan]

Thank you for the explanation.

[newpball]

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830
See a few posts earlier in that thread for more info. VirtualDub always uses rec.601 to convert YUV to RGB for display. And so apparently is MPC-BE.

A clear case of sloppy engineering!

[hello_hello]

MPC-HC and MPC-BE display YV12 video with exactly the same colours for me.

What neither of them seem to do, is display video frameserved from Avisynth correctly. They always use rec.601. (Edit: I discovered I can fix that. See the added edit below the screenshots). I've never understood why, probably because I've never really known where the colour choice while converting to RGB is made. For players such as MPC-HC and MPC-BE, I suspect it's either the Windows renderer or the video card drivers, which means they shouldn't be any different (unless they use a third party renderer). Wherever the colorimetry decision is made, for some reason it's apparently not applied to uncompressed video. At least that's the way it works on my PC. I'm running XP and using the WMR9 (renderless) renderer with an Nvidia card.

As an example, the 1st pic is MPC-HC displaying a standard 720p video (1280x696), the second is MPC-BE displaying it, while the third pic is MPC-HC displaying it opened via Avisynth and either DirectShowSource or LWLibavVideoSource (I won't bother repeating the last screenshot for MPC-BE as the result is the same).



That's the way I've become accustomed to things working. It'd be interesting to know why they don't work the same way for you, or why MPC-HC and MPC-BE appear to be different, and also to learn why newpball so often seems to post just so he can be wrong.

Edit: So it turns out MPC-HC and MPC-BE don't always have to display Avisynth frameserved video incorrectly. Just after I posted, a thought occurred to me, as I kind of remembered at some stage, some time ago, they possibly did......
Anyway it turns out if I enable ffdshow's raw video decoder (in the list of codecs) suddenly the 720p video I was opening via Avisynth displayed with the correct colours. According to the tooltip the input is uncompressed YV12 and the output is NV12 (or I can force YV12), but when it's via ffdshow it displays correctly. Another mystery....

For the record..... here's a resizing colorimetry experiment I tried a while ago to see how colorimetry is chosen based on resolution. If anyone else would care to try it to see if the result is the same, I'd be interested.

Open a YV12 video with MPC-HC and ffdshow decoding. Something with lots of red to make the difference in colorimetry obvious. Maximise the player. Open the ffdshow configuration and enable the resizing filter. You should be able to resize the video using ffdshow without the display size changing. It makes changes in colour easy to see. Adjust the resolution and watch for when the colours change. Here's the rule by which it seems to work for me.

The width must be 1154 or greater and the height must be 578 or greater for the video to display using rec.709.

For software such as ffdshow, if you tell it to convert to RGB (rather than output the original colour space) it uses the following rule according to the tooltip:
The width must be greater than 1024 or the height must be greater than 598.

The ffdshow method seems better to me because it means pretty much anything with a resolution higher than PAL will display using rec.709. The Windows method (or whoever decides the colorimetry) means some "720p" video won't display correctly. For instance a 1280x544 resolution, which isn't particularly uncommon, will incorrectly display using rec.601.

Anyway, if anyone else cares to try the colorimetry experiment, I'd be interested to know if the result is the same.

I'd really like to learn once and for all where the colorimetry decision is made and hopefully as a result learn why using ffdshow's raw video decoder causes it to change. Anyone know??

[hello_hello]

jagabo,
I discovered a little while ago VirtualDub always uses rec.601 except when it's not using rec.601.

I can't remember which setting fixes it, but in preferences there's a couple of settings for DirectX or Direct3D under Display, and one of them will get it displaying rec.709 correctly (or maybe enabling the effect file does), only something odd happens on my PC.....
If I have a video open in another player such as MPC-HC and open a video in VD, if I then click ONLY on the MPC-HC button in the taskbar to switch between them, there's a pause while switching to VD and it displays using the correct colours. If I switch between them using ONLY the VD button on the taskbar there's no pause and it switches to rec.601. MPC-HC keeps displaying using the correct colours either way. Go figure.....

VirtualDubMod seems to always use rec.601.

I've run out of time to experiment with VirtualDub at the moment. I might try some resolution, colorimetry tests later on, but I guess there's lots of stuff about how video is rendered using a PC I don't understand.

[jagabo]

Yes, when VirtualDub is using DirectX (Options -> Preferences -> Display -> Use DirectX...) to display the video you can trick it into displaying with rec.709 (in this case VirtualDub is sending YUV to the graphics card and the graphics card is doing the YUV to RGB conversion). You can also use Video -> Color Depth -> Other to force VirtualDub itself to use other matrices for YUV to RGB conversion.

[gregalan]

I found out MPC_BE can show the correct colors, if you go into the video decoder configuration and change the standard manually, auto apparently doesn't work correctly,
or it doesn't work the way I assumed it does.

I could be wrong but I think FFdshow resizer uses swscale from ffmpeg so it would correct the output format internally I believe.

[jagabo]

The best way to approach this is to include the color matrix in your encodings so that the player doesn't have to guess. (Not all players will obey the flagged matrix but at least those that do won't have to guess.) When the matrix isn't specified players often assume rec.601 for SD material (up to 720x576), rec.709 for HD material (1280x720 and above). But different players will use different threshold between those two sizes. So if you upscale a rec.601 PAL DVD source from 720x576 up to 1024x576 and don't specify the color matrix some players may display with rec.601, others with rec.709.

And yes, which renderer the player is using can effect which matrix is used.

[hello_hello]

After reading the above posts it occurred to me to try something, so I configured the LAV decoder to output RGB. Unlike the RGB output options in MPC-BE or ffdshow, it doesn't have a colorimetry setting, but I opened a video with a 1280x536 resolution and it obviously displayed with a different colorimetry to when LAV was outputting YV12. So in that case LAV was getting it right when MPC-HC would normally display the colours incorrectly. I don't know yet if LAV can read the colorimetry info from the video stream, as the video I happened to pick doesn't contain any (according to MediaInfo), so in this case it's simply making a better guess. I'll play around some more later to see if I can work it out, but I'd assume it does.

Now I'm wondering why it'd never occurred to me before to let either LAV or ffdshow do the conversion to RGB if it means the colorimetry is more likely to be right and I don't have to manually correct it with a pixel shader. Although maybe I did but I thought I'd probably forget to stop ffdshow converting to RGB when using DirectShow for re-encoding video. Now MPC-HC uses LAV internally though, I can configure it instead.

I found out MPC_BE can show the correct colors, if you go into the video decoder configuration and change the standard manually, auto apparently doesn't work correctly,
or it doesn't work the way I assumed it does.

As far as I know that setting only has an effect if MPC-BE is converting to RGB. It should be similar to the way ffdshow's output works. If the video is YV12 and you have YV12 de-selected as an output option, it'll convert to something else. If only RGB is selected, it'll convert to RGB, and that's when the colorimetry setting should have an effect. If it's YV12 video and the YV12 output option is enabled, the colorimetry setting shouldn't do anything. At least that's my understanding of it.

I could be wrong but I think FFdshow resizer uses swscale from ffmpeg so it would correct the output format internally I believe.

I've got to think about that one, but I don't think ffdshow makes any colorimetry choices when it's simply decoding and it's YV12 input and YV12 output, regardless of the resolution. If it does, it's using a different formula for determining the colorimetry (based on resolution) to the one it uses when it's converting to RGB, which doesn't seem logical.

It's at least become clear (call me slow) that for me at least, it's more likely the colorimetry will be correct if I let LAV do the RGB conversion instead of outputting YV12. When LAV is outputting YV12 I'm absolutely certain any colorimetry info in the video stream is ignored (with the probable exception of MPC-HC using MadVR for rendering).

I'd still like to know exactly why enabling ffdshow's raw video decoder causes HD Avisynth scripts to display using rec.709 when they don't without it. I have found differences when opening DirectShow scripts with and without it enabled, but I don't fully understand how it works yet.

Here's the filters list with ffdshow's raw video decoder disabled:

- Video Mixing Renderer 9 (renderless)
- Color Space Converter
- AVI Decompressor (YV12)
- AVI/WAV File Source

With it enabled:

- Video Mixing Renderer 9 (renderless)
- ffdshow Video Decoder
- AVI/WAV File Source


And looking at the pin info, the media type displayed for the "AVI/WAV File Source" filter is the same each time, it's the same for the "ffdshow Video Decoder" and the "AVI Decompressor (YV12)", but after the Color Space Converter, which it seems is converting to RGB, the media info type displayed for the renderer isn't the same.

- Connection media type:

Video: 3 2048x696 23.976fps 683511kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_ARGB32 {773C9AC0-3274-11D0-B724-00AA006C1A01}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 5701632
cbFormat: 1128

- Connection media type:

Video: NV12 2048x696 (160:87) 23.976fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 2138112
cbFormat: 1152

From the above I'd assume when the ffdshow raw video decoder is enabled (second example), the video makes it to the renderer as NV12 and from there it'd be converted to RGB using the correct colorimetry.
When it's not enabled, the Color Space Converter filter gets involved, and I assume it's converting to RGB before the video makes it to the renderer, and I'd assume always using rec.601, which is why ultimately it displays incorrectly.
That seems logical at least, but I've no idea why the Color Space Converter is used. I don't understand enough about how it all works. I'd also be keen to know why the renderer sees the 1280x696 video as being 2048x696 each time when the File/Properties menu shows:

Video: YV12 1280x696 23.976fps [Avisynth video #1]

Anyone know?

I need to find somewhere where I can learn about all this properly instead of trying to put bits and pieces together without being sure I understand it.

[jagabo]

Try Testbild_colour_description_alternating_120sec.ts from this site:

http://home.kleinhappl.at/TS/

It's a high def video that switches back and forth between rec.709 (flagged) and rec.709 unflagged. If a player is following the flags but assuming rec.601 when unflagged the colors will change.

[hello_hello]

It's a pity it's not standard definition as a player would be more likely to assume rec.601 when there's no flags, but it appears the decoders I tried either only use the initial flag and don't follow anything else, or they assume rec.709 (the colours didn't change as the video progressed). I'd have no reason to doubt rec.709 would be used for 1080p in the absence of flags.

When I decoded with ffdshow while outputting RGB32 the colours were always the same even if the resizing filter was enabled, so it appears ffdshow always obeys any colorimetry info and was correctly using rec.709.
LAV converting to RGB resulted in the same colours as ffdshow.
When I decoded with ffdshow while resizing to 640x480 and outputting YV12, the colours obviously changed. I still assume that's because further down the chain the renderer (or video card) simply sees it as standard definition and uses rec.601 for the conversion.