Closed beccabender closed 6 years ago
Difference is that default in MediaInfo is an intermediate parsing speed and default in MediaConch is an fast parsing speed (in order to reduce the trace size for the moment), and frame rate is not a metadata, it is computed from timestamps of frames (so I need several frames)
with 10,000 bytes, information is present because I use a fallback in case of small files, using TrackDefaultDuration
Matroska element for guessing the frame rate.
Trying to find a better compromise between parsing speed and frame rate information.
Some tweaks in frame rate detection algo (not perfect, compromise between speed and accuracy) at https://github.com/MediaArea/MediaInfoLib/pull/663 . I keep the issue open as a reminder for tweaking in a better way the algorithm.
Thank you very much for looking into this!
Hi, I'm sure you're aware of it, but I just wanted to add that I'm noticing something similar in the GUI too (latest daily build for macOS: Version 17.08.20171119). It looks like no MKVs are passing frame rate policies (NTSC or PAL), though the quicktime files from they were derived are passing without a problem. Is there something inherently different in the frame rate detection for mkvs and movs? Again, as Becca said, thanks so much for looking into this!
Ben
@bturkus can you test latest version of MediaInfo? If you have still files not having frame rate here, I would like to have sample files. the ones from Becca are OK now.
We plan to release tomorrow a new version of MediaConch with this version of MediaInfo, I hope it would fix most of the cases.
Things look good on 17.10. Thanks again! I'll test the new version of MediaConch tomorrow.
hey @JeromeMartinez I tested MediaConch GUI 17.11, and everything seems good. Thanks for the fix!
Attached is a sample NTSC Matroska file that will display the framerate with mediainfo, but not mediaconch -mi.
With 10,000 bytes of the same file it WILL report framerate, but at 100,000 bytes it won't.
mkv_ffv1_NTSC_100000bytes.mkv.zip