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

[thljcl]

Andy Furniss-2 wrote
> thljcl wrote:
> 
>> The short answer: YUV444 can fully represent all color information in
>> RGB.
> 
> Did you even read the pdf I linked to?
> 
> Maybe you know better than him - a fellow of smpte according to
> 
> http://en.wikipedia.org/wiki/Charles_Poynton
> 
> _______________________________________________
> ffmpeg-user mailing list

> ffmpeg-user@

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

Now that I think about it. Many of us are familiar with lossy compression
with both audio and video but not lossless compression. Clearly the best of
the codec implementation is only up to how accurate and fast the decoding
and encoding process goes. In the early days when H.264 codec is
implemented, even though the lossless encoding is available in High 4:4:4
Predictive Profile (Hi444PP) according to the H.264 specification; the
mathematical intensity and demanding computing resources requirement
prevents a lot of people to actually test it or use it. It’s not unusual to
see many streaming videos are encoded in Baseline Profile or other simpler
codecs.
There is no denying that badly designed implementation of particular
encoders would result in the substantial loss of image quality; which is
particularly true when it comes to re-encoding the color information in
different representation, such as in YCbCr. The rounding error, noise, and
other complexities would cause the information to be lost during the
encoding process. A simple way to illustrate this is that 1/3 ≠ 0.33. Also,
there would be issues related to the correct decoding of signals from
encoded information. As we said before, YCbCr itself is not an absolute
color space. Without a well-defined standard for a given codec
implementation, the incorrect decoding process would result in loss of
information.
If a lossy encoding scheme is used, the use of YCbCr 4:4:4 would not change
the fact that some information is lost during the encoding process. I’m not
absolutely certain that the implementation of lossless encoding by x264 is
flawless. But the lossless encoding of H.264 is done with the use of YCbCr
4:4:4; H.264 does not directly support sRGB. Even though in Windows, one can
argue that the color information would be decoded to and encoded from sRGB
anyway; it’s the absolute color space, after all.
The initial version of H.264 version, published on May 30, 2003, contains
only Baseline, Main, and Extended profiles; none of them supports lossless
encoding or chroma format of 4:4:4. H.264 2.0 Specification (version three),
published on March 3, 2005, adds new four profiles, which are High, High 10,
High 4:2:2, and High 4:4:4. 
In particular, I quotes
“With the exception of the transform bypass mode of operation for lossless
coding in the High 4:4:4 profile and the I_PCM mode of operation in all
profiles, the algorithm is typically not lossless.”
H.264 High 4:4:4 profile explicitly supports lossless coding in High 4:4:4
with the chroma format of 4:4:4. H.264 High 4:4:4 profile is later removed
in H.264 2.2 Specification, published on June, 2006. Since H.264 2.3
Specification, published on April, 2007, it adds High 4:4:4 Predictive
Profile. At H.264 8.0 Specification, published on April 2013, I quotes
“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”
In the current specification (Ed 8.0), there are three profiles of H.264
that support lossless coding. Among those three, one of them, which is High
4:4:4 Predictive, is currently implemented by x264, which is used by ffmpeg
as H.264 encoder. 
Poynton’s article you mentioned at
http://www.poynton.com/papers/Discreet_Logic/index.html was published on
July 28, 1997; it was a time not even the first edition of H.264
Specification was published.
It’s fair to say that while some statements stated by him at the time remain
valid today, considering the pace of change in technology, we cannot take
everything he stated at the time for granted today.
Whether or not -pix_fmt “yuv444p” is required to be specified explicitly
when it comes to lossless coding depends on the sources, if sources are PNG
images, “yuv444p” would be chosen automatically. If not, you may need to
specify “yuv444p” for lossless coding.
As usual, you do not have to take my words for granted. Go to
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=6312 read the H.264
specifications yourself. The current edition as well as the past editions
are all available online. You can verify yourself whether I said is true or
not.
Of course, you can claim that the lossless coding in H.264 is not “truly
lossless”. If you can submit proofs to prove your case, many other people
and I will be glad to accept the truth. Until then, let us the accept the
currently known theories.




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