Calculation precharge-frames of XDCAM files

[donkon]

Hi Philipp,

we have an issue with the result of mxf2raw and XDCAM files: the presented precharge-frames (e.g. <precharge>-2</precharge>) are different than other tools we use (such as mediainfo).

It's about the analysis of XDCAM material that has been precisely clipped frame by frame. Due to the GOP (Group of Pictures) length of 12 frames, precharge frames are created - usually fewer than 12 frames. However, the ARD's software regularly generates files with precharge frames more than 12 frames, up to 14 (12 - 14).

In this case, we obtain incorrect results. For example Legalizer delivers accurate precharge-frame results, mediainfo shows accurate material- and source-timecode. The examples in the Folders make the problem clear: The mxf2raw-Analysis delivers too few Precharge-Frames, in both cases "-2" instead of 12 and 14 Frames (obviously the first 12 Frames are neglected).

We have a example here (the URL pointing to the file is valid for 7 days):

mxf2raw --info-format xml -i "https://storage.googleapis.com/video-content-stp-sz-mfs/media/wdr/analyse/BMX_Examples/14_Precharge-Frames/586364_0739477_CS_278517_-_11-00-00-14_bis_11-00-59-16.mxf?x-goog-signature=03afb363ced146d0865611e743e9e5d8babdecd944cf3233bbb9a5709c3b98111c73d51262fe66de0a9e5d97197684c89209520b80e4e52ef9c80ffa906e14f133dff20ac994415019314854024f6bbba59a79071dbc49e65677624cf4dba5b8ad9c1bb8fded69b89b98fbc2df237e5fb88af4e1855625ae2ce0847184638dd840a57d891db4ec9e669176ccaa2dcada7e5462d14eb2106f6a136e982118a4c879b77ff604f32d1a54797b809c4ae9f6094ff3b8472705ca9d113457466f862e966e157e77b7e7f166aaa2ed43a01a69dc7c41b0a318c9facebd3a88bc312008f8ac023cfd09aa3feb3e82fb6ae203a220dc37c704a55ea79394b607b809b18b&x-goog-algorithm=GOOG4-RSA-SHA256&x-goog-credential=storage-access%40project-ard-stp-sz-mfs-int-gcp.iam.gserviceaccount.com%2F20230803%2Feurope-west3%2Fstorage%2Fgoog4_request&x-goog-date=20230803T072146Z&x-goog-expires=604800&x-goog-signedheaders=host"

Here are the results from other tools:

• mediainfo
• mxflegalizer

[philipnbbc]

I've taken a look and I think mxf2raw is reporting correct information for the amount of pre-charge required. mxf2raw reports the (minimum) amount of frames needed to produce the output time range. In this file the output starts at frame 14. The coded frame required to produce output position 14 is frame 12, which is an I-frame. That means there are 2 frames (the pre-charge) needed to decode output frame 14 and subsequent frames.

The legalizer references 0054W - Origin Values in the EBU QC and the legalizer names the property "Precharge Frames". The Origin value in the file source package is indeed 14.

(The timecodes reported by mxf2raw look fine as well. Note that mxf2raw reports the timecode of the first output frame which is 11:00:00:14 for the file source package)

[dysty13]

Hi Philip,
Our Problem is, that we need the 14 Frames from somewhere. mxf2raw doesn`t report the source-timecode 11:00:00:00, (like mediainfo does).
In mxf2raw StartTimecode "material" is always the same like "file_source":
material : 11:00:00:14
file_source : 11:00:00:14

And mxf2raw doesnt report the Origin value "14 Frames". So all we have is 2 Precharge-Frames, that doesnt match with our file.
Is it possible to add the value "origin" in mxf2raw (14 in our case)? Or report the source`s StartTimecode (11:00:00:00 in our case)?

Thanks!

[philipnbbc]

I think adding something like "origin" would generally be useful and I'll look at adding it or something equivalent to tell you how many additional frames there are. Not yet sure whether it should be as explicit about the property name "origin" or whether something like "precharge_available" is better to deal with complexities of different track "Origin" property values (e.g. in OPAtom). A similar thing applies to the file source package timecodes.

This also points to the fact the bmx is more focused on wrapping and trans-wrapping files than on validation or file analysis. mediainfo and other validation / analysis tools could provide more direct information with less interpretation than bmx does.

[philipnbbc]

I've created #26 to add properties that you can use, namely max_available_precharge. Could you take a look and let me know if it is ok?

It's maybe not quite as elegant as the output of mxfflegalizer for example but works for how bmx has been implemented. There are invariably some corner cases it doesn't handle but it should work fine for OP1a.

[dysty13]

That's great, thank you for your effort. This is exactly what we need. We will integrate it into our Workflow as soon as possible and will let you know if it works,

[dysty13]

Hi Philip,
We have tested the new field and as expected, it works very well . It would be great, if you merge it into the mainbranch.

[philipnbbc]

Merged - thanks for testing.