MediaInfo
MediaInfo copied to clipboard
MediaArea
Captions not detected in QuickTime even with full parsing
I have a 37 second Quicktime file with a c708 track wtih 608 and 708 streams where the first caption byte at 00:00:30:00. MediaInfo (22.09) doesn't display any text streams in the file even with the --full flag.
I created a 128k dump to send for testing and weirdly, in that case a text stream is detected (but only the 708 stream).
full_mediainfo.txt SBON2202100H.mov.head.txt
I can send the full file for troubleshooting if necessary.
I created a 128k dump to send for testing and weirdly, in that case a text stream is detected (but only the 708 stream).
It creates a MediaInfo track if no data, hum... It is a bug :).
I can send the full file for troubleshooting if necessary.
Yes, please.
first caption byte at 00:00:30:00 [...] even with the
--fullflag
--full flag is for a full report, not a full parsing.
Test with --ParseSpeed=1
Thanks, adding --ParseSpeed=1 does in fact display both caption streams.
I sent you a link to the file via email.
Aside from the potential bug from the partial file, is there any way to determine if a text track exists, even if there's no caption data within the parsing interval? Right now our validation is flagging an error if upstream asserts that there are captions when there are not, but this is a valid use case. For this 30 second file adding full parsing doesn't add much processing time, but I am reluctant to universally enable it for larger content. The way I see it, we'd want to use MediaInfo/MediaConch to see if there is a text track at all, and reject if not - if there is, then pass it on to a tool with full essence decoding that would flag the lack of any caption content.
Any thoughts on how we could accomplish that?
is there any way to determine if a text track exists, even if there's no caption data within the parsing interval?
--File_Eia608_DisplayEmptyStream=1 --File_Eia708_DisplayEmptyStream=1.
It is disabled by default because people were complaining that empty content was displayed as existing, not easy to find a good balance between speed, accuracy, and relevance of default result.
Thanks, that's very helpful. Is this exposed anywhere in MediaConch? Right now it's actually MediaConch that is failing for lack of a text track in our workflow.
MediaInfo CLI options are usable with MediaConch CLI (and also the lib part, I think). For GUI (both MediaInfo and MediaConch), we need to add them, but IIUC you need only CLI so not urgent.
@plondino while working on the GUI I remarked that there is an incompatibility between this request and https://github.com/MediaArea/MediaInfoLib/issues/1882, so I added an option without incompatibilities at https://github.com/MediaArea/MediaInfoLib/pull/2085. "Old" options are still there but the last one replaces the previous one, please use the new option instead when you can.
I also added extra/InternalDetectionKind field when no content is detected, with values Command (indicating that no 608/708 content was found, only commands) or Stream (indicating that no 608/708 content or command was found, only an empty 680/708 stream), in case it helps e.g. if you use self.mediainfo.Option('File_File_DisplayCaptions ', 'Stream') and then want to know if a content was actually detected . More relevant with a full parsing.