MediaArea
BUG: MediaInfo incorrectly extracts frame duration and framerate from an FFMPEG-generated video file
Description
When extracting metadata from a file generated by segmenting a larger file using FFMPEG, MediaInfo calculates the framerate incorrectly. The extracted frame count is retained from the original video, and the framerate is determined as frame count / duration (seconds), which leads to incorrect values. Instead, the framerate should be extracted directly, and the frame count should be calculated accordingly.
Steps to Reproduce
- Use a video file with a known duration.
- Segment the video using FFMPEG with the following command:
ffmpeg -ss 00:01:00 -to 00:02:00 -i input.mp4 -c copy output.mp4 - Use the MediaInfo API to extract the framerate and frame count from
output.mp4.
Expected Behavior
- MediaInfo should correctly extract the actual framerate from the segmented file.
- The frame count should be recalculated based on the extracted framerate.
Actual Behavior
- The frame count from the original file is retained.
- The framerate is incorrectly derived as
frame count / duration, leading to inaccurate values.
Environment
- Operating System: Windows
- MediaInfo Version: Not sure how to obtain the version of the dll.
- MediaInfo API Type: DLL
Additional Context
- Screenshot of extracted framerate and frame count
I can not reproduce the frame rate issue. The only thing I can reproduce with your FFmpeg command is the weird duration.
MediaInfo behavior is not good (not ignoring incoherent values), but it seems that the main issue is FFmpeg behavior (not checking input file duration less than -ss value):
$ ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 input.mp4
$ ffmpeg -ss 00:01:00 -to 00:02:00 -i input.mp4 -c copy output.mp4
$ ffmpeg -i output.mp4 output2.mkv
[vf#0:0 @ 000002175756edc0] No filtered frames for output stream, trying to initialize anyway.
[out#0/matroska @ 0000021756c19fc0] Output file is empty, nothing was encoded(check -ss / -t / -frames parameters if used)
FFmpeg itself can not read its created output.mp4.
MediaTrace of the files shows this non normal stuff:
[...]
5EF2 File header (1428 bytes)
5EF2 Header (8 bytes)
5EF2 Size: 1428 (0x00000594)
5EF6 Name: moov
5EFA Movie header (108 bytes)
5EFA Header (8 bytes)
5EFA Size: 108 (0x0000006C)
5EFE Name: mvhd
5F02 Version: 0 (0x00)
5F03 Flags: 0 (0x000000)
5F06 Creation time: 0 (0x00000000) -
5F0A Modification time: 0 (0x00000000) -
5F0E Time scale: 1000 (0x000003E8) - 1000 Hz
5F12 Duration: 0 (0x00000000) - 0 ms <-- Movie duration is not filled!
[...]
5F66 Track (1214 bytes)
5F66 Header (8 bytes)
5F66 Size: 1214 (0x000004BE)
5F6A Name: trak
5F6E Track Header - 1 (0x1) - 4294917296 (0xFFFF3CB0) ms (92 bytes)
5F6E Header (8 bytes)
5F6E Size: 92 (0x0000005C)
5F72 Name: tkhd
5F76 Version: 0 (0x00)
5F77 Flags: 3 (0x000003)
5F7A Track Enabled: Yes
5F7A Track in Movie: Yes
5F7A Track in Preview: No
5F7A Track in Poster: No
5F7A Creation time: 0 (0x00000000) -
5F7E Modification time: 0 (0x00000000) -
5F82 Track ID: 1 (0x00000001)
5F86 Reserved: 0 (0x00000000)
5F8A Duration: 4294917296 (0xFFFF3CB0) - 4294917296 (0xFFFF3CB0) ms <-- Track duration is huge! Like if is negative value (0xFFFF3CB0 = -50000 if decimal signed int, so -50 s with 1000 time scale, instead of expected 1 s)
[...]
5FCA Edit (36 bytes)
5FCA Header (8 bytes)
5FCA Size: 36 (0x00000024)
5FCE Name: edts
5FD2 Edit List (28 bytes)
5FD2 Header (8 bytes)
5FD2 Size: 28 (0x0000001C)
5FD6 Name: elst
5FDA Version: 0 (0x00)
5FDB Flags: 0 (0x000000)
5FDE Number of entries: 1 (0x00000001)
5FE2 Entry (12 bytes)
5FE2 Track duration: 4294917296 (0xFFFF3CB0) - 4294917296 (0xFFFF3CB0) ms <-- Track duration is huge! Like if is negative value (0xFFFF3CB0 = -50000 if decimal signed int, so -50 s with 1000 time scale, instead of expected 1 s)
5FE6 Media time: 794624 (0x000C2000) - 794624 (0xC2000) ms <--- MediaInfo buggy there, should use media time scale, so 51 s, still no sense)
5FEA Media rate: 65536 (0x00010000) - 1.000
[...]
If I use
ffmpeg -f lavfi -i testsrc=duration=180:size=1280x720:rate=30 input.mp4
MediaInfo display is fine:
Duration : 1 min 0 s
Source duration : 1 min 1 s
Frame rate : 30.000 <-- input frame rate, as expected
Frame count : 1803 <-- 1 minute, as expected
(the display/source difference is because of the copy, the source contains the previous frames in the same GOP as the first frame)
Please provide a input.mp4 file demonstrating your issue (and having a playable output.mp4 file).
Ok, I can't share the original input video file (since it was a whole 13GB film) but I'll give you an equivalent. In the following link there are 2 video files.
https://we.tl/t-ixBkj0Xms3
The input video Community_Advanced_DnD.mkv where by executing the following command:
ffmpeg -ss 00:12:40 -to 00:13:39 -i .\Community_Advanced_DnD.mkv .\Community_Annie_DnD.mkv
Generates the output video file Community_Annie_DnD.mkv that when both are viewed via MediaInfo this is the result:
You provided an example with MP4 but the issue is only on MKV, anyway...
FFmpeg is buggy because it does not remove the previous duration in the metadata but it also does not remove the tagging date and MediaInfo is buggy because it does not ignore the statistic data when the tagging date is not the muxing date (and it should).
I notice that now FFmpeg adds statistic data but not all (no tagging date), I'll see what I can do with that... Because withtout tagging date the issue will come back again after another FFmpeg edit :(; I'll see what I can do with that with FFmpeg.
Yeah, my bad on the MP4 on the command. Was actually just a command placeholder, didn't occur me that could be a specific format problem.
@JeromeMartinez, sorry for the mention. But is there any update regarding this issue?
But is there any update regarding this issue?
No ETA on free support, and currently we (the main developers, but anyone else may send a patch if they are motivated) have a couple of urgent tasks to finish. If you wish to prioritize a ticket, contact us for a quote.
So I see that for mkv to mkv, FFmpeg does copy over the _STATISTICS_WRITING_APP and _STATISTICS_WRITING_DATE_UTC so MediaInfo should use the method at https://codeberg.org/mbunkus/mkvtoolnix/wiki/Track-statistics-tags#determining-if-the-tags-are-up-to-date to detect that it is likely wrong and ignore/indicate. However, it looks like FFmpeg does not write the encoded date so can only rely on writing app name.
For mp4 to mkv, FFmpeg writes lots of useless tags including mp4 major_brand for some reason.
I think FFmpeg should fix their mkv tags writing too. It has been years that it is like this. At least they fixed their mp4 eac3 complexity index writing recently.
The workaround I often use when muxing mkv with FFmpeg is to add -map_metadata:s -1 which will prevent it from copying the stream statistics tags.
FFmpeg and MKVToolNix are among the most common apps for making MKVs but...
- FFmpeg -> Writes CRC but does not handle statistics tags
- MKVToolNix -> Calculates and writes correct statistics tags but does not do CRC So I have to choose one depending on whether I want to see bitrates or want CRC protection. Unless I want to spend more time doing another parse with another app.
To have both CRC and statistics tags, use FFmpeg to do the muxing then:
mkvpropedit.exe --add-track-statistics-tags <filename>
But the problem now will be, if MediaInfo implements checking that statistics writing app and encoding app matches, if statistics is written by mkvpropedit, it will be correct but statistics writing app will not match encoding app.
Therefore, the only good solution I think is for FFmpeg to fix their statistics tags writing or at least write an encode date or both. Whereas for MediaInfo side, can only implement checking for dates when both dates are present.
to detect that it is likely wrong and ignore/indicate.
Right, we don't check yet the date and it needs to be fixed.
FFmpeg -> Writes CRC but does not handle statistics tags
On my todo-list too...
Another way to have both statistics and CRC is to mux with MKVToolNix the run through mkclean. But while trying to see which elements it adds CRC for since MediaInfo indicates ErrorDetectionType : Custom, I run into a MediaTrace bug:
000AD85B Unknown: (441420043 bytes)
That's it. Only one line appeared for files that passed through mkclean.