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

Andy Furniss adf.lists at gmail.com
Thu Aug 1 16:50:27 CEST 2013

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.

More information about the ffmpeg-user mailing list