Seek to timecode / duration and set parse duration

[plondino]

Is it possible (or could it be) for MediaInfo to take a parameter as to where to start a seek for metadata and the duration?

We have a lot of trouble detecting captions in our files since the amount of content (slates, preroll, etc) can vary and arbitrarily increasing the parsing duration results in increased loading time with diminishing returns. However, we often have metadata denoting the start time of the actual content, and I think if we were able to somehow tell MediaInfo where to seek to, we'd have a greater chance of correctly identifying the correct metadata.

[JeromeMartinez]

Not yet possible but doable, just not so easy as it needs to be implemented per container format, and currently seek was implemented years ago for a specific project but not maintained, and it is not so easy with e.g. TS as there is no index so we need to skim the file for finding the indicated start PTS, we need to review the related code and implement the option you want.

An exception to "not yet possible", hidden options for TS only and only duration (no seek) --MpegTs_MaximumOffset=xxxx and --MpegTs_MaximumScanDuration=xxxx.

[plondino]

Primary interest on our end would be for MXF and MOV, which are (usually) thoroughly indexed (in well formed files).

[JeromeMartinez]

MXF and MOV are not complex for that. We actually already do that for MXF but without option (it is hard coded to the middle of the stream, by byte offset).
I suggest classic parsing from beginning in order to avoid any collateral issues by seeking immediately, + seek to the expected timestamp (or timecode) during the expected duration after the initial parsing.

[JeromeMartinez]

@plondino @joe-sciame-wm we added an option for letting you set the probe place, for MXF (there was already a default probe of 64 MB at 50% of the file) and MP4 (new probe).
The default for both MXF and MP4 is now after 30s seek to 50% of the file and check during 30s.

Option is --File_ProbeCaption=(Seek)[+(Duration)][+(format)]
Seek and duration can be a timestamp, a timecode, a byte size, a count of seconds, a percentage (of the file duration).
"(format)" can be empty (=for all), mp4, mxf.

Example: --File_ProbeCaption=00:01:00:00+30s+mp4,50%+64M means seek at 00:01:00:00 then scan during 30s for mp4, seek at 50% then scan during 64 MiB for others.
If you set for MP4 and not for others, the default is used for others.

During development I remarked that scanning caption in MP4 is often (it depends on how captions are muxed in the file, it is fast if it is by block of e.g. 1 second, slow if it is 1 CDP packet after each video frames) fast for MP4 on SSD (it may be worse on S3 due to the latency of seeks), you may want to try to increase the scan duration without suffering too much of analysis duration, maybe up to the full file --File_ProbeCaption=0%+100%+mp4.

I suggest something like --File_ProbeCaption=45%+10%+mp4,45%+120s, it should work for all files without too much performance impact and without having to set a specific timecode per content.

[plondino]

@JeromeMartinez thanks for the update - just to confirm, MP4 includes MOV as well?

[JeromeMartinez]

MP4 includes MOV as well?

Yes.

[plondino]

I just tested this out on an MXF file I had that previously was not detecting any captions in the default parse. The file starts at 00:00:00;00 and has a long slate, and the first caption displays at 00:01:09;10. I tested with:

mediainfo file.mxf --File_ProbeCaption=00:01:00:00

Sure enough 4 streams were detected. However I experimented with the starting timecode and found that even just setting it to 00:00:00:01 is enough to detect all streams which is odd to me, since I would expected that the captions are too far out to detect under normal usage and I would have to get closer to find actual caption data. I will provide the link to the file, can you shed some light on this?

[JeromeMartinez]

However I experimented with the starting timecode and found that even just setting it to 00:00:00:01 is enough to detect all streams which is odd to me, since I would expected that the captions are too far out to detect under normal usage and I would have to get closer to find actual caption data. I will provide the link to the file, can you shed some light on this?

There was a rounding issue that lead to a seek with a precision of 1% of the MXF file, so the 00:00:00:01 seek was not really to this exact timecode. Seek improved in #2024 and now in dev snapshots and now precision is few seconds (we don't parse the indexes for faster check and we don't really need precision here, let me know if it is not the case for you) and the behavior is the expected one (00:00:00:01 seek, as well as e.g. 00:00:30:00 seek, with your file does not catch the captions because the default scan duration of 30 seconds is used and the first caption is later).