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).
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?
On 11/16/2014 02:57 PM, Andy Furniss wrote:
Peter Rabbitson wrote:
This results (as expected) in a file identical to the source, proving
that the video contains the full RGB (or equivalent yuv444) set of
color information:
~$ diff miniansi_orig.png miniansi_frame.png; echo $? 0
Players by default will use GPU for CSC/scale and these often won't
avertise 444 as an input option so VLC will likely convert to 420.
There is likely some way you could get VLC to do it, with mplayer I
think specifying opengl would do.
I don't really know what to suggest - 422 would be more likely to work
- but then you would still see some loss.
You are actually correct - the conversion that took place is 422, not
420 as I originally thought. Verified by:
~$ ffmpeg -hide_banner -i miniansi_frame.png -f matroska -pix_fmt yuv422p - |
ffmpeg -hide_banner -i - -pix_fmt rgb24 minansi_yuv.png
and then comparing the way miniansi_yuv.png looks to the actual playback
in a vlc window.
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
