[FFmpeg-user] Unable to produce a yuv444p video that vlc will play back correctly

[Andy Furniss]

Peter Rabbitson wrote:
> I am replying in-line further down, but wanted to to ask a generic
> question, just to make sure I fully understand what is actually going
> on:
>
> In 1997 Intel came up with the MMX instruction set which among other
>  things allows in-hardware rgb->422/420 conversion. Since then all
> players default to this on a virtually hardcoded level, and the GUI
> subsystem is expected to convert everything back to rgb (using the
> very same instruction set).

Though it was advertised for multimedia and SIMD is handy I don't
believe it's why yuv is used.

That's from broadcast for bandwidth reasons and given that practically
all "real" video is yuv then it needs converting to rgb if that's what
the display takes.

Using CPU with or without SIMD to do yuv -> rgb is typically last resort
of players as for a long time graphics cards/chips have been able to do it.

> As a result of the MMX success, everything in the digital video world
>  *17 years* later is inescapably doing this rgb->yuv->rgb dance, even
> in the case of 100% correct and complete metadata. This is true for
> all cases including the situation when both the source and the
> destination are operating in the RGB24 colorspace: CGI produced under
> an RGB renderer, to be displayed in a web-browser player, which by
> definition operates on an RGB device.
>
> Did I get the state of the art about right?

I think the MMX bit is a distraction. It's not impossible for players to
do RGB direct, but you are using mpeg codecs which were really made for
real video/broadcast which is still yuv.

The example of CGI straight to browser is probably not typical, but may
become more so - it's possible that solutions already exist.

Normal CGI as used by broadcast whether overlays or films would be made
so as not to expose subsampling artifacts - eg not using 100% colours
which suffer most AIUI (something to do with working with gamma
corrected vs linear light in addition to the actual res loss).


> You are actually correct - the conversion that took place is 422, not
>  420 as I originally thought.

+1 to vlc some players could go straight for 420 as the lowest common
denominator.

You can't say that everyone would see the same result though, as it
depends on the hardware/set up of the users machine.