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

[thljcl]

Andy Furniss-2 wrote
> thljcl wrote:
>> Andy Furniss-2 wrote
>>> H264 is talking about lossless where input is and output are the same
>>> 444 - Y'CbCr - there is no conversion by H264 from RGB as your PNG
>>> example would need - that would be done prior to H264 by ffmpeg.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>
>>> ffmpeg-user@
>>
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>>
>> Speaking of “YCbCr →YCbCr” for H.264 lossless encoding, you obviously did
>> not read the H.264
>>
>> specifications Ed 8.0, did you?
>> Let me quote directly from H.264 Specifications,
>> “The source and decoded pictures (frames or fields) are each comprised of
>> one or more sample arrays:
>> – Luma (Y) only (monochrome), with or without an auxiliary array.
>> – Luma and two Chroma (YCbCr or YCgCo), with or without an auxiliary
>> array.
>> – Green, Blue and Red (GBR, also known as RGB), with or without an
>> auxiliary
>> array.
>> – Arrays representing other unspecified monochrome or tri-stimulus colour
>> samplings (for example, YZX,
>> also known as XYZ), with or without an auxiliary array.”
>> That is at Page 42.
>> On Page 25, I quote
>> “With the exception of the transform bypass mode of operation for
>> lossless
>> coding in the High 4:4:4
>>
>> Intra, CAVLC 4:4:4 Intra, and High 4:4:4 Predictive profiles, and the
>> I_PCM
>> mode of operation in all profiles, the algorithm is typically not
>> lossless,
>> as the exact source sample values are typically not preserved through the
>> encoding and decoding processes.”
>>
>> Also look at Page 408 at Table E-3 - Color Primaries
>>
>> “The same 444”? Yeah, considering that sRGB is also regarded as 444
>> correctly.
>>
>> H.264 specification explicitly says that the source is image encoded in
>> sRGB. Anything to you want say to response?
> 
> Yes, it does not say source is encoded sRGB it says it can be - it can 
> be other things as well.
> 
> If the three planes represent RGB and are encoded losslessly then after 
> decoding you will have your RGB back.
> 
> There is nothing in what you quote to say that CSC to Y'CbCr then back 
> to RGB would be involved.
> 
> A quick search will show you that "transform bypass mode" is nothing to 
> do with CSC.
> 
> 
> 
> _______________________________________________
> ffmpeg-user mailing list

> ffmpeg-user@

> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

You are missing the point. The H.264 specifications do not attempt to
explain some of basic notions such as “absolute color space” and “relative
color space”. I’ve repeatedly told you about it. What H.264 specifications
explicitly said that one of the supported sources is the image encoded in
RGB and it does support lossless coding in three profiles, one of them is
called “High 4:4:4 Predictive” which is used by x264.
The fact that encoded information is required to be decoded is based on the
how “absolute color space” and “relative color space” are related. But H.264
Specification does explicitly say that the video is to be decoded to RGB.
Perhaps you should read what is written at
http://en.wikipedia.org/wiki/Absolute_color_space
Or, if you can afford it, just buy the books which are cited as sources by
Wikipedia, which are Java 2D graphics, written by Jonathan Knudsen, and
Human Vision and Electronic Imaging XII. SPIE. ISBN 0-8194-6605-0.




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