Discussion:
[FFmpeg-user] Does converting to yuv444p by default make sense?
Werner Robitza
2013-07-27 12:12:01 UTC
Permalink
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
Paul B Mahol
2013-07-27 12:46:43 UTC
Permalink
Post by 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?
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?
Post by Werner Robitza
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Werner Robitza
2013-07-27 15:06:10 UTC
Permalink
Post by Paul B Mahol
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?
Stefano Sabatini
2013-07-27 15:32:22 UTC
Permalink
Post by Werner Robitza
Post by Paul B Mahol
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
Post by Werner Robitza
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.
Post by Werner Robitza
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
Werner Robitza
2013-07-27 16:05:08 UTC
Permalink
Post by Stefano Sabatini
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.
Post by Stefano Sabatini
Post by Werner Robitza
By the way, I wouldn't go as far to say "outdated media players" – can
you
Post by Werner Robitza
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.
thljcl
2013-07-28 15:46:54 UTC
Permalink
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.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660271.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Paul B Mahol
2013-07-29 08:59:06 UTC
Permalink
On 7/28/13, thljcl <***@live.com> wrote:

[...]
Post by thljcl
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?
Andy Furniss
2013-07-29 10:24:55 UTC
Permalink
Post by thljcl
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
thljcl
2013-07-29 11:14:04 UTC
Permalink
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.





--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660295.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Andy Furniss
2013-07-29 17:17:13 UTC
Permalink
Post by thljcl
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
thljcl
2013-07-30 23:58:19 UTC
Permalink
In doing scientific research, we learn the laws of Physics based on
experimental data and logical understanding and deduction; not because of
someone says so. That said, I would never claim that I’ll never be wrong; in
fact, I make mistakes as frequent as any human being does. I’m also told by
Buddha not to take others’ words for granted for any other reasons other
than my own reasoning and understanding; no matter who they are.
I said that yuv444p can fully represent every single color in 24-bit RGB
color space is based on the algorithms used to encoding RGB color into
yuv444p. We know that lossy compression is irreversible. That is, there is
no way to recover the original information from a file of lossy compression.
The way to determine whether yuv444p can fully represent every single color
in 24-bit RGB color space is to determine whether the algorithm or function
to encode 24-bit RGB color space is reversible or if the function itself has
inverse function. Let me give you an example.
We are taught the existence of inverse trigonometric function. But
trigonometric functions themselves do not have inverse functions. Sounds
strange? Trigonometric functions are inverse functions of inverse
trigonometric function; but vice versa is not true. A function is a
one-to-one or many-to-one relationship. Inverse trigonometric function is
one-to-one relationship but trigonometric function is many-to-one
relationship. That is why inverse trigonometric function, strictly speaking,
is not the inverse function for trigonometric function.
In lossy compression, the algorithm is similar to many-to-one relationship.
That is, for a given encoder’s settings, we have an output file of certain
amount of information. Since some information is discarded during the
encoding process, we cannot recover the discarded information from the
output file. Such a function does not have an inverse. Or, we say that lossy
compression is irreversible.
How does YUV444p relate to RGB24? It depends on the standards being used.
But either way the function does have an inverse. Let’s take a look at ITU-R
BT.601 conversion at

<iframe width="640" height="390"
src="http://www.youtube.com/embed/FyLN46hGZzU" frameborder="0"
allowfullscreen></iframe>

It’s a slideshow I specifically created to show the derivation. While I
derive the inverse transformation matrix myself; the conversion matrix for
RGB24 to YUV444P I got from http://bit.ly/14gWnv0.
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.
The reason for the loss of color information due to chroma subsampling
scheme such as YUV420p or YUV422p is due to the sharing of color information
between pixels, rather than having each individual pixel has its own color
information in all three channels, which are Y’, Cb, and Cr. There is no
denying that the reason for such transformation is for the chroma
subsampling scheme, i.e. reduction of color information; but it’s not due to
the non-invertible transformation matrix.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660346.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Nicolas George
2013-07-31 10:02:54 UTC
Permalink
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
thljcl
2013-07-31 14:47:05 UTC
Permalink
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.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660374.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
thljcl
2013-07-31 09:02:56 UTC
Permalink
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.

<iframe width="640" height="390"
src="http://www.youtube.com/embed/PDVk-fRPzxU" frameborder="0"
allowfullscreen></iframe>


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.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660365.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
thljcl
2013-07-31 19:13:10 UTC
Permalink
Post by Andy Furniss
Post by thljcl
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
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
It’s a good thing to know that
the expert you recommend actually shares the same idea as I do.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660376.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
thljcl
2013-08-01 02:13:36 UTC
Permalink
Post by Andy Furniss
Post by thljcl
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
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.
Andy Furniss
2013-08-01 10:12:10 UTC
Permalink
Post by thljcl
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.
thljcl
2013-08-01 11:00:27 UTC
Permalink
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.




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660382.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Carl Lindqvist
2013-08-01 12:06:56 UTC
Permalink
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.
thljcl
2013-08-01 12:19:50 UTC
Permalink
Post by 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
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 which numbers are valid for such operation, you have to
transform from sRGB  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.



--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660385.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Carl Lindqvist
2013-08-01 13:03:39 UTC
Permalink
For the purpose of this thread my argument stands. It shows that there
can not be a 1:1 mapping between 24 bit RGB and 8 bit (24 bit) YCbCr
color spaces. If you have an RGB image, convert it to YCbCr, you can
not represent all possible RGB values that were originally there. (For
example one huge 16,7 megapixel image that happened to include every
color in RGB)

If we all agree that 24 bit RGB has 16777216 possible colors, and that
8 bit YCbCr also has 16777216 possible colors, then what I said must
be true. Because I have just shown that at least 65536 of the possible
colors in YCbCr all represent the same color in RGB. That means that a
conversion must lose colors.
thljcl
2013-08-01 13:20:43 UTC
Permalink
No, you haven’t.
“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”
This argument is wrong. Plain and simple.
First of all, I do not know what “Y=0” would represent. It is not
necessarily black. Each color in YCbCr is represented by three numbers. I
think you got this idea because of you think of “Y” as luma component, if
there is ‘no’ luma information, it must be black, right? That is the
misunderstanding. As a matter of fact, I explicitly told you that you only
know which three numbers from YCbCr represent from a well-defined mapping
from an absolute color space.
By the way, “Y” is called luma component not for the reason you think it is.
That is, for grayscale image, both Cr and Cr would represented by two unique
but maybe different numbers, only “Y” component is allowed to have different
numbers, which is 256 in total. That would be 256×1×1=256.
No, I do not claim that we can know which color YCbCr represents without
mapping. It’s just that YCbCr affine mapping (of different conversion
standards) is defined specifically to behave in such manner.
To answer your question directly, if Cb and Cr changes but Y remains
unchanged, there would be different colors, not “black” as you claimed; and
I don’t even suggest “Y=0” leads to black.
In short, yes, in 24-bit YCbCr, there would be exactly 16,777,216 number of
colors




--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660389.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
thljcl
2013-08-01 12:36:12 UTC
Permalink
There is also another mistake you made. I said previously, you cannot know
colors from YCbCr alone without mapping from an absolute color space;
because YCbCr does not define colors. Say, if you have three (valid) values
from YCbCr representations, instead of trying to guess what color it might
be, why don’t you simply apply the inverse transformation matrix on it to
see what are their corresponding sRGB representation? As the colors are all
defined in absolute color space, which sRGB is one of the most popular.



--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660386.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
thljcl
2013-08-01 12:09:26 UTC
Permalink
Post by Andy Furniss
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
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?



--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660384.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
Andy Furniss
2013-08-01 14:50:27 UTC
Permalink
Post by thljcl
Post by Andy Furniss
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
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
– 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.
thljcl
2013-08-01 15:01:34 UTC
Permalink
Post by Andy Furniss
Post by thljcl
Post by Andy Furniss
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
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
– 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
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.
Andy Furniss
2013-08-01 20:22:53 UTC
Permalink
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 :-)
thljcl
2013-08-01 20:53:16 UTC
Permalink
Post by Andy Furniss
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
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.
Paul B Mahol
2013-08-01 21:51:11 UTC
Permalink
Post by thljcl
Post by Andy Furniss
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
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.
OK, so what was original thread about?
Andy Furniss
2013-08-01 23:38:29 UTC
Permalink
Post by thljcl
Post by Andy Furniss
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
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.
This is the ffmpeg mailing list not x264 and when you used the term
YUV444p that means a very specific thing which I pointed out is not
lossless when used to convert from rgb24, and it is ffmpeg that does the
conversion.
Post by thljcl
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.
No, you can't say there is "color space conversion" or re-encoding
because x264 doesn't do that - it takes what you give it and for the
purpose of reading the spec what you give it is referred to as YCbCr.
Post by thljcl
This may seem surprising to you. The actual absolute color space currently
supported by H.264 is
Supported meaning that you feed it something, tell it what it is, so
that what it is can be conveyed to the decoder.
Post by thljcl
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.
As above - this is ffmpeg list and when you use the term yuv444p that
means something specific and totally unrelated to how you should read
the h264 spec.


How to know which one is being used? That’s a good question. The
Post by thljcl
short answer is I don’t know.
The one that is being used is the one you (ffmpeg) gave to it and
hopefully told it so it could pass on the info to the decoder.
Post by thljcl
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.
In practice on a computer assuming yuv is the input then the decoder
will send yuv to the graphics card/chip for csc and scaling.
thljcl
2013-08-01 23:46:21 UTC
Permalink
"yuv" itself is a misnomer. It's commonly understood to actually mean "YCbCr"
for the encoder. By the way, ffmpeg does not do the encoding on its own; it
uses x264. x264 calls it YCbCr and follows ITU-T's recommendation (H.264
Specs). See http://mewiki.project357.com/wiki/X264_Settings#colormatrix here
for yourself. By the way, bt709 is different from sRGB, but they do share
the same color primaries.



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

thljcl
2013-08-01 16:49:41 UTC
Permalink
Look at Page 42 of the H.264 Specification Ed 8.0

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

It’s asking you to look at Annex E. So go to Annex E, Look at table E-3.

It specifically mentioned sRGB.

Of course, there are many RGB-based color spaces being mentioned, with sRGB
being one of them. Either way, it just shows that YCbCr is just a "relative
color space".



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