[FFmpeg-user] Levels and Primaries

[Robert Krüger]

On Mon, Feb 3, 2014 at 5:00 PM, Rio Kierkels <riokierkels at gmail.com> wrote:
> On 3 February 2014 16:11, Robert Krüger <krueger at lesspain.de> wrote:
>
> what I would check here, is if there are obvious MXF container
>> metadata differences between the file output by ffmpeg and the one
>> created by Episode.
>
>
> Thank you Robert, nice little tool.
>
> mxf2raw reports some differences:
> First Signal Standard which is set to 0 (None) in the ffmpeg mxf and in the
> Episode mxf it's set to  4 (SMPTE 274M) which is the standard HD SDI signal.

I suspected something like that. I had the same difference when
comparing an ffmpeg-generated file with one generated by mxf4mac.

I just had a quick look at the MXF demuxer source code and I don't see
that the color information is used at all. I think this is generally a
weak spot of ffmpeg. There are a number of places where color
information is either not read from or written into bitstreams and
container formats. Places I can see are mov and mxf muxing/demuxing
and mpeg encoding (decoder seems to read color information from the
bitstream). So in your case, if ffmpeg shows the right color
information on the command line for an MXF file with an mpeg2 video
stream it is most likely because the color information is encoded in
the bitstream.

What ffmpeg should ideally do IMHO is:
- Use color information from the container if available (at least when
the bitstream has none)
- Write color information into container and bitstream if they support
it (that is what I guess Episode is doing in your case)

All of these should be rather trivial patches for someone knowing
their way around in the respective muxers/demuxers and codecs. I can
post a patch for mov muxer and demuxer that a colleague of mine
created recently and just hasn't taken the time to submit to the
mailing list yet but that won't fix it for mxf, i.e. your case.