[FFmpeg-user] Another odd colourspace issue

Tim Nicholson nichot20 at yahoo.com
Wed Jul 11 10:37:03 CEST 2012

On 11/07/12 05:27, Robert Krüger wrote:
> 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.

Right on both counts, I couldn't find anything either but wondered if
there was something in the container (mov) I had also missed. The real
problem is lack of a readily accessible "waveform monitor" for files
that can be relied upon. Both FCP and Kdenlive have them, but clearly
have limitations.

Since Kdenlive is built on libav* I was somewhat surprised that it
didn't stick with ffmpegs defaults.

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

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

This pretty much what I had reckoned.

Swscale seems to have the basic capability, but there seems to be no
way, either from stream/container interrogation, or option setting, to
invoke it. However clearly third party apps that use the libs (like
Kdenlive) are making use of that capability.

As a first stab it would be good to be able to specify it the way Mark
suggests. I am not sufficiently familiar with ffmpeg internals to see
what that would take, but am having a poke around, in between other


More information about the ffmpeg-user mailing list