[FFmpeg-user] How to generate IRT conform D10 IMX50 MXFs (and how to set the output color_range, -space, -transfer and primaries flags)

tim nicholson nichot20 at yahoo.com
Thu Apr 30 09:04:45 CEST 2015


On 28/04/15 09:20, Christoph Gerstbauer wrote:
> Hello
> 
> I am making tests with IMX50/MXF encodings with FFMBC and FFMPEG. (with
> 24bit audio)
> The tests compare the final files with the IRT MXF Analyzer Pro tool to
> be shure to be IRT conform.
> (My used syntax is at the bottom of this mail)
> 
> Both files (generated with ffmbc and ffmpeg) are working very well in
> editing tools but there is a little difference:
> 
> The IMX50 generated by ffmbc has no errors/warnings at IRT MXF Analyzer
> (with16bit audio). It is really perfect. In fact I never had a clean
> "green" MXF by testing other probes from other encoding tools. Only the
> IRT probes itself are clean. So this MXF is IRT conform when using the
> ffmbc standard target preset "imx50".
> 
> The Analyzis of the IMX50/MXF generated by FFMPEG (latest build from
> zeganoe) has 1 warning and 1 error:
> 
> WARNING:
> "Fill Item Key with a wrong RP210 (SMPTE Metadata Dictionary) version
> number of 0x01. The correct version number is 0x02"
> 
> ERROR: "The Sound Essence Descriptor signals that the number if
> quantization bits is 24, which is higher than actually required (16) as
> detemined by parsing the essence."
> 
> 
> Due to the fact that I am producing 24bit audio I could prevent the
> WARNING by producing 16bit audio. But is there a problem in the MXF when
> producing 24bit? Sound works in editing tools.
> Furthermore ffmbc produces for standard a IMX with 16bit -> If I force
> ffmbc to do 24bit, I get the same error.
> 
> Due to the warning: I found out that both files are different regarding
> these values (by reading out via ffprobe - show_streams)
> 
> FFMBC IMX FILE stream 0:0:
> color_range=tv
> color_space=smpte170m
> color_transfer=bt709
> color_primaries=bt470bg
> 
> 
> FFMPEG IMX FILE stream 0:0:
> color_range=tv
> color_space=unknown
> color_transfer=unknown
> color_primaries=unknown
> 
> 
> So my questions are :
> 
> 1.) How can I produce (with ffmpeg) the same output like ffmbc with
> these 4 metadata flags:
> color_range=tv
> color_space=smpte170m
> color_transfer=bt709
> color_primaries=bt470bg
> I didnt found a answer to that in the ffmpeg documentation :/

Submit a patch that includes these flags. I'm not sure if ffmbc actually
inspects the source  material to check these figures are correct, or
just hard codes them, I suspect the ffmpeg results are more "honest".

> 
> 2.) Maybe somebody knows: Do these 4 metadata flags have a connection to
> the Warning message of the MXF Analyzer? -> "Fill Item Key with a wrong
> RP210 (SMPTE Metadata Dictionary) version number of 0x01. The correct
> version number is 0x02"

The UL version number is the version number where the UL first appeared
in the defining registry* and is generally ignored in all UL parsing
(certainly in ffmpeg). Its only really there for checking back when a
particular UL appeared in the spec, and has no functional use. So no, I
do not believe there is a connection. As errors go it is basically cosmetic.

There are a number of questionable UL's in the ffmpeg code, and as they
originate from a number of different standards, working out where they
came from and checking them is somewhat tedious, which is why I am
trying to rationalise them. Having said that an RP210 UL should be
straightforward to check and correct, if the actual key is know (you do
not provide it).


> If nobody know this answer I could do the test for myself by be able to
> encode with the upper params in 1.).
> 
> 3.) Is there an syntax option in ffmpeg for 24bit audio encoding to
> prevent this ERROR:
> "The Sound Essence Descriptor signals that the number if quantization
> bits is 24, which is higher than actually required (16) as detemined by
> parsing the essence."

This is more a warning than an error, if you are using 24bit it will be
flagged as such, which is correct. however converting 16 -> 24 is
usually done by padding with 0, so the analysis is simply warning that
that you are wasting bits. You could try adding some noise I suppose ;)

> 
> 
> Best Regards
> Christoph
> 
> 
> [...]

* RP S336m Table 11 says "Version Number...Version of the Defined-Length
Pack Register which first defines the item specified by the
Defined-Length Pack Designator"

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83


More information about the ffmpeg-user mailing list