[FFmpeg-user] Levels and Primaries

Thomas Worth dev at rarevision.com
Wed Feb 12 16:47:48 CET 2014

On Mon, Feb 3, 2014 at 6:35 AM, Rio Kierkels <riokierkels at gmail.com> wrote:
> I hope you're still with me and if you are I hope you have anything to say
> about it. May it be some experience with the same issues or even the answer
> to this debacle. Use the materials in this post as you like to do your own
> tests and you can ask me anything you want be it to run certain tests on
> the equipment I have available or maybe even contacting our broadcasters
> for some specific information.
> We want FFmpeg to be as good as it gets and I really think we can get this
> one right!

*Big breath*

Okay, I haven't read this entire thread so I apologize if ay of what I'm
about to say has already been mentioned. But I'll just give my take on this
issue, since it was a big one for me during the development of 5DtoRGB and
other in-house tools.

First off, I could never trust the swscale library to do its job properly.
Its scaling was just plain not right in every circumstance, and the color
was never right either meaning something is fundamentally wrong with the
combination of scaling/matrices. This is all probably okay for pirating
movies, but for critical color work like we do here in the film industry it
just isn't good enough. In the end I wrote my own scaler from scratch. It
works perfectly, with perfectly repeatable results and with all the options
a post house would want for this sort of thing. But it wasn't easy...

When I say "combination" of scaling/matrices, I mean that even though
you're performing your BT.709 matrix math on an RGB source, this doesn't
mean it's going to come out right on the other end. For example, if the
image is matrix encoded and then scaled, that won't give the same result as
scaling and then matrix encoding. Also, you have to scale luma (Y) and
chroma (CbCr) separately, and using different ranges (0-235 and 0-240
respectively). And then encode them. Or vice-versa. See all the potential
for problems here? Anyone, and I mean anyone trying to write a scaler and
color space converter needs to read the relevant portions of Charles
Poynton's book. Don't even waste your time (and everyone else's), until
you've fully digested those chapters. It's what anyone else who knows what
they're doing has already done, and the only way to ensure your output
looks the same as Apple's, Avid's and Adobe's.

Here's another problem which has nothing to do with
FFmpeg/libavcodec/swscale. It's the host system's handling of codecs. Even
though the data in the file may be broadcast range, the decoder may decide
to scale it to full range without asking or have errors in its matrix
decoder. Programs like After Effects do this because it works in RGB which
is always full range. So, it may appear that the source is full range when
in fact it isn't. The only way to know for sure is to use an app that will
show you the raw values of the YCbCr planes without allowing any meddling
by some scaler code. 5DtoRGB has a setting that does this specifically for
inspecting the source files and determining their native luma range.

Anyway, I'm not surprised FFmpeg has problems with this since dealing with
this issue seems to be a very low priority. Some of these issues have been
addressed by Baptiste Coudurier with his ffmbc fork, although I haven't
verified the color scaling stuff since I have my own code now that does
that. You might try ffmbc and see if you get better results.

And regarding the trolling by certain people: I do understand some of this,
especially with respect to open source software in general. Although the
FFmpeg crowd has been generally helpful and polite (thanks Carl!), this has
NOT been my experience with other open source projects. I mention this
because there seems to be resistance in many cases to new ideas, especially
when the maintainers don't work in the same industry as the folks raising
the issues. I think this makes it difficult, if not impossible for the
maintainers to see the value in such requests and therefore dismiss them as
being frivolous and unnecessary. Language is also a problem since many
projects have contributors from around the world. So, I don't know how much
of this applies to the FFmpeg project but I would keep this in mind when
asking for features that only satisfy a relatively small portion of the
user base.

Or, you can always learn C and fork! :-D


More information about the ffmpeg-user mailing list