[FFmpeg-user] Another odd colourspace issue

[Robert Krüger]

On Tue, Jul 10, 2012 at 7:44 PM, Phil Rhodes <phil_rhodes at rocketmail.com> wrote:
>
>> I believe that the colour space is generally decided solely on the frame
>> size.
>
>
> I'm pretty sure you're right; at least, I've never been able to exactly
> figure it out. Coders?
I guess his assumption was concerning how FCP and Kdenlive do it. I
could not find a line of code in ffmpeg that sets a stream's color
space based on frame size but I might have missed something.

In general, there are only three options:
1) the information is in the container for containers that support
this type of information (e.g. Mov or MXF)
2) the information is in the stream for bitstream formats that support
this kind of information (e.g. MPEG-2 or H.264)
3) the information is not in the file so AFAIK the application has no
choice but to guess

in case 3) frame size is probably the best heuristic you have if you
don't make the user specify it, which some applications like 5D2RGB
offer.

>
> It is of course cack. This problem has been under discussion for quite some
> time and it is easy to define how the solution should work, although
> actually implementing it requires a proper transform-based colour management
> system to be grafted on to ffmpeg, which might have some fairly far-reaching
> implications (although it could also be fairly simple, depending on how
> ffmpeg is actually laid out internally, which is not information to which we
> have easy access).
>
> I suspect the reasons it has not been fixed are as follows:
>
> - Fixing it might be a pain
> - It's an extremely common problem in software (particularly if you include
> studio/full swing issues) and therefore having this problem is not as
> stigmatised as it should be.
> - Most of the software people who work on ffmpeg are not video engineers and
> don't have a very complete knowledge of this area, and don't really
> understand why it's a problem or how to solve it and certainly won't take
> advice from the likes of us, and finally:
> - Well, you sort of get a kind-of picture that has, broadly speaking, red
> green and blue in it, give or take, so that's pretty much, more or less,
> roughly, okayish, isn't it?
>
> Remember this stuff is used mainly to feed Youtube, where people just assume
> that oranges and reds going super-neon-bright is cool.

Man, I know one should not feed trolls like you but this is sickening
to read from someone constantly bickering about the priorities of
people who make free software in their spare time while you are
actually offering so little profound knowledge. Instead you keep
making fun of people who have created one of the most remarkable
pieces of open source software. If you had ever cared to spend one
tenth of the time you spend trolling on this or other lists trying to
understand what people do here, you would certainly not make these
outrageous statements. What you could do is make good bug reports with
samples and some research to help developers improve something, maybe
read specs and finally maybe offer a bounty for a given feature or
even use a commercial software package and shut the **** up. Instead
what's going to happen is that you will, for the xth time, not get it
and keep on babbling about how them damn hackers/linux/oss people
don't understand what's really important about making video
engineering software. I know it's a waste of time but I just could not
help it this time.

But back to the issue. AFAICS most things are basically in place as
far as API is concerned but may not be implemented for all
formats/codecs for which color information might be available, e.g.
for MPEG-2 and H.264 color information is read from the bitstream if
it is there. It is however not used when setting up libswscale for
scaling and pixel format conversions AFAICS, which might require some
API changes because I cannot see how the scale filter (where the
actual pixel format conversions happen) can currently access the color
information to set up swscale correctly but that should probably go to
the dev list after some more research.