Does converting to yuv444p by default make sense?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Does converting to yuv444p by default make sense?

Werner Robitza
As a frequent troubleshooter or non-working ffmpeg commands, it has
occurred to me countless times that users ended up with videos that were,
for no obvious reason, "not playable".

The reason for those broken videos was that the original color space of the
input video was RGB (e.g. when piping PNG images or uncompressed video).
Using x264 without any further options would result in the video being
encoded as YUV, but without chroma subsampling, i.e. yuv444p, which most
players cannot handle.

The fix for these problems is to add -pix_fmt yuv420p, but it's hard to
spot this as a new (or unexperienced) user.

Wouldn't it make sense, when converting from RGB, to automatically use
yuv420p?
Or are there any good reasons against doing so? I would assume that users
who know they need non-subsampled video also know how to force the
conversion.

Werner
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Paul B Mahol
On 7/27/13, Werner Robitza <[hidden email]> wrote:

> As a frequent troubleshooter or non-working ffmpeg commands, it has
> occurred to me countless times that users ended up with videos that were,
> for no obvious reason, "not playable".
>
> The reason for those broken videos was that the original color space of the
> input video was RGB (e.g. when piping PNG images or uncompressed video).
> Using x264 without any further options would result in the video being
> encoded as YUV, but without chroma subsampling, i.e. yuv444p, which most
> players cannot handle.
>
> The fix for these problems is to add -pix_fmt yuv420p, but it's hard to
> spot this as a new (or unexperienced) user.
>
> Wouldn't it make sense, when converting from RGB, to automatically use
> yuv420p?

That is bad idea, you are forcing users that want to keep quality
to add -pix_fmt yuv444p

Instead this message was added in code and is displayed:

No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.

Perhaps it should be in BIG _R_E_D_ blinking letters with popup window?

> Or are there any good reasons against doing so? I would assume that users
> who know they need non-subsampled video also know how to force the
> conversion.
>
> Werner
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Werner Robitza
> Instead this message was added in code and is displayed:
>
> No pixel format specified, yuv444p for H.264 encoding chosen.
> Use -pix_fmt yuv420p for compatibility with outdated media players.
>
> Perhaps it should be in BIG _R_E_D_ blinking letters with popup window?
>

Did you really just implement that or is it already there? Because I don't
see it in a recent-ish post-2.0 build.
I don't think it needs to be anything more than a warning, because the
conversion will work regardless.

By the way, I wouldn't go as far to say "outdated media players" – can you
name a few players that support it?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Stefano Sabatini-2
On date Saturday 2013-07-27 17:06:10 +0200, Werner Robitza wrote:

> > Instead this message was added in code and is displayed:
> >
> > No pixel format specified, yuv444p for H.264 encoding chosen.
> > Use -pix_fmt yuv420p for compatibility with outdated media players.
> >
> > Perhaps it should be in BIG _R_E_D_ blinking letters with popup window?
> >
>
> Did you really just implement that or is it already there? Because I don't
> see it in a recent-ish post-2.0 build.

Try for example:
ffmpeg -f lavfi -i testsrc=d=10,format=rgb24 -c:v libx264 -y out.mp4

> I don't think it needs to be anything more than a warning, because the
> conversion will work regardless.

It's INFO level, and thus it's not highlighted in yellow, we could
raise the message to the WARNING level.

> By the way, I wouldn't go as far to say "outdated media players" – can you
> name a few players that support it?

ffplay, VLC, MPlayer, in general all up-to-date FFmpeg-based players
(that is most Linux/FLOSS media players) just to make an example.
--
FFmpeg = Fast and Fantastic Meaningless Portable Everlasting Geek
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Werner Robitza
>
> It's INFO level, and thus it's not highlighted in yellow, we could
> raise the message to the WARNING level.
>

At least to me that would make sense, given the number of times I've helped
users troubleshoot that particular problem.


> > By the way, I wouldn't go as far to say "outdated media players" – can
> you
> > name a few players that support it?
>
> ffplay, VLC, MPlayer, in general all up-to-date FFmpeg-based players
> (that is most Linux/FLOSS media players) just to make an example.
>

Latest stable VLC 2.0.7 on OS X simply crashes with a seg fault for all
yuv444p videos I generated with x264 and recent ffmpeg, but that's probably
for the VLC people to investigate.
Thanks for the info though! That clears up a few points.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
In reply to this post by Werner Robitza
When it comes to quality preservation, video editing, or lossless encoding; yes, I would agree that “yuv444p” makes plenty of sense. “yuv444p” is a way of re-encoding the entire 24-bit RGB information, which all color information is preserved without any loss due to chroma subsampling. Lossy encoding would cause the “generational loss” of quality. Chroma subsampling or any other lossy encoding algorithms does not make sense for repeating video editing process.
For video/film producers, it makes sense to keep the master copy of the videos, for future editing or remastering process. That said, videos often undergo lossy compression before commercial or non-commercial public distribution. Lossy compression is done to achieve smaller file size, at the expense of image quality. Lossy compression that is done over high-quality source can preserve fairly reasonably high quality.
Ffmpeg is not the only tool I ever use. Most tools would have presets for lossy compression, without giving us an option to choose our own settings. Since most videos being distributed have undergone lossy compression of certain levels, it makes sense for the many media players support those popular formats.
If the sources have already underwent lossy compression, ffmpeg will choose the “same color space” by default. For example, it would choose YUV420p by default for JPEG image as sources. If the sources are PNG image, it would choose YUV444p. Of course, the user can choose his own pixel format by -pix_fmt.
There are free tools widely available to play H.264 encoded in YUV444p, such as Media Player Classic Home Cinema included in K-Lite Codec Pack Mega. Windows Media Player can play H.264 encoded in YUV444p with K-Lite Codec Pack Mega. I’m not familiar with Mac OS X.
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. My personal preference is that I would like to play highest-quality video possible.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Paul B Mahol
On 7/28/13, thljcl <[hidden email]> wrote:

[...]

> To me personally, I kind of like the way ffmpeg handle color space
> conversion. Ffmpeg does have issues within its algorithm.

What are you talking about?
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Andy Furniss-2
In reply to this post by thljcl
thljcl wrote:
> When it comes to quality preservation, video editing, or lossless encoding;
> yes, I would agree that “yuv444p” makes plenty of sense. “yuv444p” is a way
> of re-encoding the entire 24-bit RGB information, which all color
> information is preserved without any loss due to chroma subsampling.

Well the subsampling is self evident, but I don't think 8 bit yuv can
represent all of rgb (though not all of rgb is perceptible anyway).

http://www.poynton.com/PDFs/Merging_RGB_and_422.pdf

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
YCbCr is not an absolute color space. It’s just a way to represent all color information in RGB in different set of “coordinates”. Mathematically speaking, YCbCr 4:4:4: is related to RGB color space by a single linear transformation matrix, just like Lorentz Transformation or Rotation in Euclidean Space. Now I know that there are different standards with regards of the transformation matrix being used; but all of them are non-singular, or reversible. That said, when it comes to calculation by computer, there will always be rounding involved. However, no rounding error would be introduced in this case because number of colors in RGB color space is limited. For 24-bit sRGB color space, there are only 16,777,216 colors; whereas the usual coordinate transformation involves vector space which can be seen as a set of infinite elements of coordinates.
That said, by encoding RGB color space in Y, Cb, and Cr channels, we can later reduce the number of bits being used for encoding color information in Cb and Cr channels; that’s the basic idea behind chroma subsampling. In case you wonder how a chroma subsampling scheme affects the number of bits to be used for a single pixel on average:
LAGS NAME            NB_COMPONENTS BITS_PER_PIXEL
-----
IO... yuv420p                3            12
IO... yuyv422                3            16
IO... rgb24                  3            24
IO... bgr24                  3            24
IO... yuv422p                3            16
IO... yuv444p                3            24
IO... yuv410p                3             9
IO... yuv411p                3            12
IO... gray                   1             8
IO..B monow                  1             1
IO..B monob                  1             1
I..P. pal8                   1             8
IO... yuvj420p               3            12
IO... yuvj422p               3            16
IO... yuvj444p               3            24
..H.. xvmcmc                 0             0
..H.. xvmcidct               0             0
IO... uyvy422                3            16
..... uyyvyy411              3            12
IO... bgr8                   3             8
.O..B bgr4                   3             4
IO... bgr4_byte              3             4
IO... rgb8                   3             8
.O..B rgb4                   3             4
IO... rgb4_byte              3             4
IO... nv12                   3            12
IO... nv21                   3            12
IO... argb                   4            32
IO... rgba                   4            32
IO... abgr                   4            32
IO... bgra                   4            32
IO... gray16be               1            16
IO... gray16le               1            16
IO... yuv440p                3            16
IO... yuvj440p               3            16
IO... yuva420p               4            20
..H.. vdpau_h264             0             0
..H.. vdpau_mpeg1            0             0
..H.. vdpau_mpeg2            0             0
..H.. vdpau_wmv3             0             0
..H.. vdpau_vc1              0             0
IO... rgb48be                3            48
IO... rgb48le                3            48
IO... rgb565be               3            16
IO... rgb565le               3            16
IO... rgb555be               3            15
IO... rgb555le               3            15
IO... bgr565be               3            16
IO... bgr565le               3            16
IO... bgr555be               3            15
IO... bgr555le               3            15
..H.. vaapi_moco             0             0
..H.. vaapi_idct             0             0
..H.. vaapi_vld              0             0
IO... yuv420p16le            3            24
IO... yuv420p16be            3            24
IO... yuv422p16le            3            32
IO... yuv422p16be            3            32
IO... yuv444p16le            3            48
IO... yuv444p16be            3            48
..H.. vdpau_mpeg4            0             0
..H.. dxva2_vld              0             0
IO... rgb444le               3            12
IO... rgb444be               3            12
IO... bgr444le               3            12
IO... bgr444be               3            12
I.... gray8a                 2            16
IO... bgr48be                3            48
IO... bgr48le                3            48
IO... yuv420p9be             3            13
IO... yuv420p9le             3            13
IO... yuv420p10be            3            15
IO... yuv420p10le            3            15
IO... yuv422p10be            3            20
IO... yuv422p10le            3            20
IO... yuv444p9be             3            27
IO... yuv444p9le             3            27
IO... yuv444p10be            3            30
IO... yuv444p10le            3            30
IO... yuv422p9be             3            18
IO... yuv422p9le             3            18
..H.. vda_vld                0             0
IO... gbrp                   3            24
IO... gbrp9be                3            27
IO... gbrp9le                3            27
IO... gbrp10be               3            30
IO... gbrp10le               3            30
I.... gbrp16be               3            48
I.... gbrp16le               3            48
IO... yuva420p9be            4            22
IO... yuva420p9le            4            22
IO... yuva422p9be            4            27
IO... yuva422p9le            4            27
IO... yuva444p9be            4            36
IO... yuva444p9le            4            36
IO... yuva420p10be           4            25
IO... yuva420p10le           4            25
IO... yuva422p10be           4            30
IO... yuva422p10le           4            30
IO... yuva444p10be           4            40
IO... yuva444p10le           4            40
IO... yuva420p16be           4            40
IO... yuva420p16le           4            40
IO... yuva422p16be           4            48
IO... yuva422p16le           4            48
IO... yuva444p16be           4            64
IO... yuva444p16le           4            64
..H.. vdpau                  0             0
IO... xyz12le                3            36
IO... xyz12be                3            36
IO... rgba64be               4            64
IO... rgba64le               4            64
..... bgra64be               4            64
..... bgra64le               4            64
IO... 0rgb                   3            24
IO... rgb0                   3            24
IO... 0bgr                   3            24
IO... bgr0                   3            24
IO... yuva444p               4            32
IO... yuva422p               4            24
IO... yuv420p12be            3            18
IO... yuv420p12le            3            18
IO... yuv420p14be            3            21
IO... yuv420p14le            3            21
IO... yuv422p12be            3            24
IO... yuv422p12le            3            24
IO... yuv422p14be            3            28
IO... yuv422p14le            3            28
IO... yuv444p12be            3            36
IO... yuv444p12le            3            36
IO... yuv444p14be            3            42
IO... yuv444p14le            3            42
IO... gbrp12be               3            36
IO... gbrp12le               3            36
IO... gbrp14be               3            42
IO... gbrp14le               3            42
IO... gbrap                  4            32
I.... gbrap16be              4            64
I.... gbrap16le              4            64
IO... yuvj411p               3            12
The short answer: YUV444 can fully represent all color information in RGB.
 
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Andy Furniss-2
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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
Earlier, I uploaded a slideshow I created to YouTube to demonstrate the way to derive the inverse transformation matrix for YCbCr to RGB conversion from RGB to YCbCr transformation matrix. While it’s fair to say that the method I used is largely unchanged; apparently, I did make some mistakes during the calculation process, resulting the wrong values for the transformation matrix for YCbCr to RGB conversion. I’ve removed the earlier post and the earlier version of slideshow video I uploaded to YouTube. Upon finishing the revision to make the corrected version, I re-upload the slideshow video again to YouTube.



The reason that I made the derivation is to show that based on our understanding of linear algebra, we know that how YCbCr can be used to fully encode RGB color information. To be specific, the transformation being used is actually affine transformation. Please watch the slideshow video and make your own judgment. I don’t claim to be a know-it-all expert. I even admitted that I made mistakes during my earlier derivation process. Still, it’s a careless mistakes, rather than a misunderstanding of the algorithms behind RGB to YCbCr conversion. There are different industry standards for defining YCbCr color space model. I only used one to prove a basic concept.
If you spotted any mistakes, please inform me. Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Nicolas George-2
In reply to this post by Andy Furniss-2
Le duodi 12 thermidor, an CCXXI, thljcl a écrit :
> Basically, if you've learned linear algebra before, you may understand right
> away why YUV444p can represent all colors from R'G'B'. Before you denounce
> my answer, please watch the video first to see if there is anything wrong
> with my math.

There is something wrong with your math: you forget that the pixel formats
do not correspond to vector spaces, but to only discrete parallelepipeds.

There are only a few affine bijections from a parallelepipeds to another,
and the RGB <-> YUV conversion is not one of them: at least one of the
parallelepipeds overflows the other.

As it happens, the YUV parallelepiped is wider than the RGB cube, so your
claim that RGB -> YUV is lossless stands on that regard; only you did not
provide the full proof, so you do not get the full mark. But the opposite
direction does not work: for example, full chroma with no luma maps to pixel
values of 278, which is not possible.

And there is the discrete issue. Since the YUV parallelepiped is larger than
the RGB cube, if they hold the same number of discrete points, the YUV
discrete points are further apart, and several RGB points will fall on the
same YUV point. The matrix has a determinant of about 6.4, that is 2.7 extra
bits, so if you want perfect RGB -> YUV conversion from 8-bits depth, you
need at least 9-bits depth on the YUV side. It may become apparent in
gradients.

Regards,

--
  Nicolas George

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
I only attempt to calculate the original value for R (0-255), G (0-255), and B (0-255). As far as I understand, RGB color space is NOT vector space and I did not see it as such.
I realized that RGB color space is not a vector space from the very beginning. The reason is quite simple. For a 3-channels 24-bit RGB color space, it is a set with only limited number of elements, which is 16,777,216 number of colors. In a vector space, without regards to the actual inner product space structure, we generally do not have a boundary for a given field of number. But each color is represented by three unique numbers; in this case, it is similar to a coordinate system used for describing Euclidean Space. But as you pointed out, only non-negative integer value is allowed for R, G, and B; the number is between 0-255, at least in the case for sRGB color space.
But if I understood correctly, YCbCr is NOT an absolute color space. What is an absolute color space? It is a color space in which colors are unambiguous, that is, where the interpretation of colors in the space are colorimetrically defined without reference to external factors. There are different ways to define absolute color space. Two examples are CIEXZY and sRGB. In other words, colors cannot be defined unambiguously without absolute color space. If YCbCr is not an absolute color space, without knowing how the absolute color space that it is mapped to being defined, we cannot have unambiguously defined colors either.
As I said before there are many linear map standards being used, I only use one example to clarify how they re-encode color information in YCbCr. We DO NOT and ARE NOT able to define colors without absolute color space, thus cannot define colors with YCbCr alone. Say we are able to define all 16,777,216 number of colors in sRGB color space; the representation of color in YCbCr is a merely an affine map from the absolute color space; not the other way around.
Put it in another way, I merely treated R’, G’, and B’ as three unknowns in a system of three independent linear equations, which are being used to define color in an absolute color space; but in the example of the video I showed, is it possible to find unique solution with a known given affine map and three known values for Y, Cb, and Cr? The answer is yes. If only 0-255 is allowed for the definition of color in each channel of R’, G’, and B’, there is no way the inverse affine map will yield a negative value or any other values. In fact, if the affine map is used, there will be exactly 16,777,216 number of possible values of Y, Cb, and Cr since they are defined from an affine transformation from a RGB color space.
That said, as you can see from the video, due to rounding, it’s still need to make appropriate rounding or quantization to fulfill the complete one-to-one relationship. Granted, if YCbCr is treated as an absolute color space, and other values other than the 16,777,216 number of values are allowed, solving the equations may lead us to negative values or non-integers as you suggested.
The fact to the matter is, different device or software or operating system may use different absolute color space. But YCbCr is not one of them.
So, why we specifically define an affine map to yield YCbCr representations, a simple way to say is that we separate the color information to three different channels, instead of Red, Green, Blue, we choose Luma, Chroma Red Difference, and Chroma Blue difference. That’s not strictly true however. One would point out that if there is no chroma information, it would be grayscale or black and white. But the truth is since YCbCr is defined as affine map to the RGB color space, different levels of “gray” or “black” and “white” can actually still be represented by three numbers, R, G, and B. In particular, Black is represented by “0,0,0” in sRGB. Every single color requires three numbers in sRGB. Even if there is only 256 colors in gray scale, the colors are still represented by three numbers.
256 × 1 × 1= 256
In other words, in gray scale, in YCbCr representations, we only needs a single unique but maybe different number for both Cb and Cr channels; whereas in Y channels, 256 numbers are allowed. Unlike sRGB, these 256 numbers in Y channels are not necessarily integers. In the original sRGB color space, there are also 256 numbers required, but each time the number for each channel, namely, R, G, and B would change accordingly. That’s why re-encoding to the relative color space YCbCr makes sense as human eyes are less sensitive to the change in chroma information compared with luma information. This re-encoding provides the foundation for chroma subsampling, which is to reduce the number of pixels to store chroma information for a given sample. But makes no mistake. The colors are still defined by sRGB representation in Windows PC or other RGB color space in other systems. YCbCr is merely a representation given by affine map. That’s all.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
In reply to this post by Andy Furniss-2
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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
While Charles Poynton may not show me how he derives the inverse of transformation matrix, he apparently arrives at the same conclusion as I do with regards to the inverse of transformation matrix. Note that our equations may seem different to each other as I specifically rewritten it in different forms in the final slides. But if you pay close attention, they are basically the same.
Take a look at http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC29 and http://www.youtube.com/watch?v=PDVk-fRPzxU. It’s a good thing to know that the expert you recommend actually shares the same idea as I do.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
In reply to this post by Andy Furniss-2
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Andy Furniss-2
thljcl wrote:

> 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.

Well you maths is better than mine, and the effort you put into
presenting your case is hugely more than me, but -

You don't seem to have listened to what Nicolas said and now above you
seem to to be comparing something totally un-related to what was stated
in the Poynton paper.

He is talking about full range RGB to 601 studio levels Y'CbCr, but the
stuff about lossless H264 above has  absolutely nothing to do with that.

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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
At first, reading at the PDF file written by Poynton seems to lead us to conclude that color space conversion alone, before chroma subsampling is done, would reduce the number of possible colors, thus reducing color information. If that is true, that’s what we called “lossy encoding”, i.e. the encoding process where the original information is irrecoverable.
Hm… Seems like I’ve given out a lot of information without arranging them systematically.
Let me try to make it simpler.
I first tried to define what YCbCr really means and tell what “absolute color space” and “relative color space” really means.
As I said before, YCbCr alone cannot define colors, that is without a well-defined mapping to an absolute color space.
Then the question naturally leads to how does such mapping work? Does it one-to-one or many to one?
That’s why I specifically choose a conversion matrix and try to derive its inverse to show that its relationship is truly one-to-one, at least mathematically.
However, mathematically one-to-one function does not guarantee the actual encoding process is lossless.
As I said before, it’s very common for studios or producers to use lossy encoding scheme; then the point of use YCbCr 4:4:4 would not have any effect on preserving the color information. To put it simply, the bits for color information have been reduced, of course there would be less color information.
For computer or software to read YCbCr signal correctly, it has to be decoded to an absolute color space, where sRGB is the most common one, co-developed by Microsoft and HP.
Due to the widespread popularity of sRGB, the color profiles or the color space assumed to be used by lossless image files is always sRGB; if but software is able to do conversion between absolute color space. But YCbCr is not absolute color space, it’s just the question of rearranging the information and doing the right mapping.
In practice, the encoding process is very complex, often with noise, rounding errors, and other issues. That’s why codec design is important.
Speaking of lossless compression of video creation using H.264 High 4:4:4 Predictive Profile, how do you think a video is being created?
It’s created from individual (presumably lossless) images encoded in an absolute color space (presumably sRGB). In fact, you can do that with ffmpeg alone.
The simple command is something like this:
ffmpeg -r "24" -i "frames\f_%%1d.png" -vcodec "libx264" -crf "0" "output.mkv"
Here the lossless h.264 video is created from individual frames, which are PNG files with the filenames of “f_1.png, f_2.png…”
Of course, for this operation to work, the image files have to share the same resolution and bit depth.
If color space conversion would somehow cause the loss of color information, such an encoding process should not be called “lossless”.
Besides, mathematically, the affine map which I used to derive the inverse affine map does not show any loss of information. Mathematically, when a rounding occurs; or the function itself is not one-to-one; it’s generally not possible find the inverse function; that’s what we call irreversible conversion. That’s why trigonometric function or exponential function, strictly speaking, does not have inverse functions. When they are defined in terms of complex numbers, there are simply no ways to know what the original input number is. One way for such “inverse” to work is to simply “choose” the one of the many possibilities; again that option does not necessarily equal what input is; that’s why we specify a range of possible values for such “inverse” function, instead of the whole field of complex numbers.
Based on well-defined mapping, the color information in your videos, despite being encoded in YCbCr, is defined by sRGB color space in your Windows PC. Keep that in mind. Although re-encoding to YCbCr from sRGB is commonly called “color space conversion” or “pixel format conversion”, it’s entirely different from “absolute color space conversion”; where the colors themselves are being defined differently. For example, in Adobe RGB, the set of possible colors is different from what is being defined by sRGB; if a “color space conversion” occurs between them, of course there would be noticeably difference of what we would see in terms of “perceptual colors” after the encoding is done. But YCbCr does not define “colors”. It’s up to the codec implementation to see if their design and mapping works flawlessly. It’s also very common to call sRGB “4:4:4”; that is for a reason. If the mathematical operation being used is buggy and the codec design is not good, there is no denying that re-encoding the information itself would lead to information loss.
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

Carl Lindqvist
It's quite easy to see that no YCbCr 444 can't be one to one with RGB,
even when the full values of Y (0-255 instead of 16-235) are used.

Think of a Y value of 0. Cb and Cr can have 256x256=65536 different
combination of values, but they all represent the same black color in
RGB: 0,0,0

So there MUST be some loss of color information when converting between the two.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
This post was updated on .
In reply to this post by Andy Furniss-2
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
[hidden email]
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 you want say to response?
Reply | Threaded
Open this post in threaded view
|

Re: Does converting to yuv444p by default make sense?

thljcl
This post was updated on .
In reply to this post by Carl Lindqvist
Carl Lindqvist wrote
It's quite easy to see that no YCbCr 444 can't be one to one with RGB,
even when the full values of Y (0-255 instead of 16-235) are used.

Think of a Y value of 0. Cb and Cr can have 256x256=65536 different
combination of values, but they all represent the same black color in
RGB: 0,0,0

So there MUST be some loss of color information when converting between the two.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
What you said sounds reasonable, except that you forgot about one thing: you cannot simply assign a real number and tried to use the inverse transformation matrix on YCbCr. The operation is only well-defined for a set of 16,777,216 input values. As I said before, the YCbCr itself is defined as an affine map from an absolute color space, not necessarily sRGB, but I always cite sRGB as an example.
If you want to know which numbers are valid for such operation, you have to transform from sRGB to YCbCr first, after getting the output value; you can then use the output value as input value and apply the inverse transformation on it, of course what you got is the original input value from the first operation, assuming that your calculation is accurate enough to avoid rounding-off error problem.
The set of valid input values is not define as equal to the set of positive integers, for your information. I’m using 24-bit color space as an example in this case. But you can easily see that the argument is still valid for other bit depths, such as 30 bits. Only if the bit depth is larger, the number of valid input values also increases accordingly.
12