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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
