[FFmpeg-user] Does converting to yuv444p by default make sense?

[Andy Furniss]

thljcl wrote:
> Andy Furniss-2 wrote
>> thljcl wrote:
>>
>>> You are missing the point..
>>
>> Well I may be missing your points, but you have really gone well away
>> from the point that Poynton makes and I linked to, which was
>> specifically about rgb24 to 8bit Y'CbCr.
>>
>> It doesn't matter what could be, it matters what is and you are not
>> going to be changing the way every decoder/display converts yuv to rgb.
>>
>> You said initially -
>>
>> "“yuv444p” is a way of re-encoding the entire 24-bit RGB information"
>>
>> and went on to say
>>
>> "To me personally, I kind of like the way ffmpeg handle color space
>> conversion. Ffmpeg does have issues within its algorithm. YUV444p is not
>> one of them"
>>
>> So do you think that if you made a 4096x4096 rgb24 image using C with
>> all the possible variations, that you could, using ffmpeg, convert it to
>> yuv444p and back to rgb24 without loss?
>>
>> Try it - it's trivial in C to generate and also trivial to write
>> something that counts the unique pixels.
>>
>> I've just done it but my C is so bad I may make the programmers on here
>> feel ill if I posted it - and it's probably still buggy :-)
>>
>> _______________________________________________
>> ffmpeg-user mailing list
>
>> ffmpeg-user@
>
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> Of course, what I've been saying is the feature of H.264 and what YCbCr
> 4:4:4 means. Whether or not x264 can actually meet H.264 specification;
> whether or not H.264 design is with bugs; that is entirely different issue.
> I never once said that I assumed that the encoder itself is without bugs.
> What I really said was what it was supposed to be. It’s a question of
> theoretical capability and actual implementation.

This is the ffmpeg mailing list not x264 and when you used the term 
YUV444p that means a very specific thing which I pointed out is not 
lossless when used to convert from rgb24, and it is ffmpeg that does the 
conversion.

> By the way, did you not read my previous post? YCbCr, as stated by H.264
> specification Ed 8.0, is not the actual color representation. YCbCr 4:4:4 is
> just another way to say full color information is being encoded. (x264 calls
> it yuv444p; anyway the name is not the point here) You can say that there is
> “color space conversion” if re-encoding the information with affine map is
> what you mean.

No, you can't say there is "color space conversion" or re-encoding 
because x264 doesn't do that - it takes what you give it and for the 
purpose of reading the spec what you give it is referred to as YCbCr.


> This may seem surprising to you. The actual absolute color space currently
> supported by H.264 is

Supported meaning that you feed it something, tell it what it is, so 
that what it is can be conveyed to the decoder.


> This is true as of Ed. 8.0 I’m not sure how much specs of H.264 being
> implemented by x264, it’s not full; that’s for sure. It’s not practical to
> implement every spec anyway. Let me quote once again from page 42
>
> “For convenience of notation and terminology in this Specification, the
> variables and terms associated with these arrays are referred to as luma (or
> L or Y) and chroma, where the two chroma arrays are referred to as Cb and
> Cr; regardless of the actual color representation method in use. The actual
> color representation method in use can be indicated in syntax that is
> specified in Annex E. The (monochrome) auxiliary arrays, which may or may
> not be present as auxiliary pictures in a coded video sequence, are optional
> for decoding and can be used for such purposes as alpha blending.”
> In other words, the reported YUV444p is not the actual absolute color space
> being used.

As above - this is ffmpeg list and when you use the term yuv444p that 
means something specific and totally unrelated to how you should read 
the h264 spec.


  How to know which one is being used? That’s a good question. The
> short answer is I don’t know.

The one that is being used is the one you (ffmpeg) gave to it and 
hopefully told it so it could pass on the info to the decoder.

> According to H.264 specification, the “colour_primaries” syntax element is
> being used to specify which absolute color space is being used. Regardless
> of which absolute color space is being encoded in, the decoder still need to
> decode it to sRGB in Windows anyway.

In practice on a computer assuming yuv is the input then the decoder 
will send yuv to the graphics card/chip for csc and scaling.