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

[Paul B Mahol]

On 8/1/13, thljcl <jiachielee at live.com> 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.
> 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.
> This may seem surprising to you. The actual absolute color space currently
> supported by H.264 is
> 1.	Rec. ITU-R BT.709-5
> 2.	Rec. ITU-R BT.1361
> 3.	IEC 61966-2-1 (sRGB or sYCC)
> 4.	IEC 61966-2-4
> 5.	Society of Motion Picture and Television Engineers RP 177 (1993) Annex B
> 6.	Rec. ITU-R BT.470-6 System M
> 7.	United States National Television System Committee 1953 Recommendation
> for transmission standards for color television
> 8.	United States Federal Communications Commission Title 47 Code of Federal
> Regulations
> 9.	Rec. ITU-R BT.470-6 System B, G
> 10.	Rec. ITU-R BT.601-6 625
> 11.	Rec. ITU-R BT.1358 625
> 12.	Rec. ITU-R BT.1700 625 PAL and 625 SECAM
> 13.	Rec. ITU-R BT.601-6 525
> 14.	Rec. ITU-R BT.1358 525
> 15.	Rec. ITU-R BT.1700 NTSC
> 16.	Society of Motion Picture and Television Engineers 170M (2004)
> (functionally the same as the value 7)
> 17.	Society of Motion Picture and Television Engineers 240M (1999)
> (functionally the same as the value 6)
> 18.	Generic film (color filters using Illuminant C)
> 19.	Rec. ITU-R BT.2020
> 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. How to know which one is being used? That's a good question. The
> short answer is I don't know.
> 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.

OK, so what was original thread about?