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

[thljcl]

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.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660407.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.