How is maximum frame rate and minimum frame rate calculated?
wuyuanou opened this issue · 7 comments
Are they calculated by pkt_dts_time?
I have a mp4 file and it contains B frames, mediaInfo shows it's maximum frame rate is 10000fps and minimum frame rate is 3.7fps, actually its frame rate is 30fps.
I have checked each frames pkt_dts_time, and find that because of B frames exists, the minimum pkt_dts_time interval between two frames can be 0.0001 second, I guess that's the reason mediaInfo shows maximum frame rate is 10000fps. obviously this result is wrong.
Instead of by pkt_dts_time, Isn't it more accurate to calculated maximum frame rate and minimum frame rate by pkt_pts_time?
pkt_dts_time
pkt_dts_time
is not a field name from any format specification.
(it is internal stuff from FFmpeg only)
and find that because of B frames exists, the minimum pkt_dts_time interval between two frames can be 0.0001 second,
There is no link between b-frame and interval, it is very classic to have b-frames and they are displayed as 30 fps if they are 30 fps.
obviously this result is wrong.
Or not, it could be also an issue in the file and MediaInfo would be only the messenger of the issue. To be confirmed.
How is maximum frame rate and minimum frame rate calculated?
It is calculated from the timinf information found in the file. For MP4, it is usually from stts
("Time to Sample") atom.
Please share ever a "trace" of the file (mediainfo --Details=1 YourFileName
with the command line, menu Debug, "details 10" with Windows GUI), only the stts part is useful, or the file itself (if private content you can share it directly to info@mediaarea.net or provide only the first and last MB of the file, it should be enough).
The sample duration indicated is very weird, e.g.:
(timescale is 1/90000)
00037E Time to Sample (1000 bytes)
00037E Header (8 bytes)
00037E Size: 1000 (0x000003E8)
000382 Name: stts
000386 Version: 0 (0x00)
000387 Flags: 0 (0x000000)
00038A Number of entries: 123 (0x0000007B)
00038E Sample Count: 1 (0x00000001)
000392 Sample Duration: 5998 (0x0000176E)
000396 Sample Count: 1 (0x00000001)
00039A Sample Duration: 9 (0x00000009)
So it is true that average of the 2 frames is 3003/90000 = 29.97 fps but well, if it is constant frame rate why not having 3003 for all frames?
Note that even if I remove small values it is still variable e.g.
0004BE Sample Count: 1 (0x00000001)
0004C2 Sample Duration: 3008 (0x00000BC0)
0004C6 Sample Count: 6 (0x00000006)
0004CA Sample Duration: 2999 (0x00000BB7)
Sometimes slightly quicker (<3003), sometimes slightly slower (>3003).
Worse:
00055E Sample Count: 1 (0x00000001)
000562 Sample Duration: 23929 (0x00005D79)
Duration of this frame is 23929/90000= 266 ms!
MediaInfo is a reporter, so shows the truth, and here your file is VFR with weird frame durations even if the average looks like 30 fps. Why it is like that is a good question, but the messenger can not explain that, it just provide a message about the weird file...
Report of MediaInfo shows all:
Frame rate mode : Variable
Frame rate : 29.756 FPS
Minimum frame rate : 3.756 FPS
Maximum frame rate : 10 000.000 FPS
Real frame rate : 30.000 FPS
You have the average, the min, the max, the tip about the real frame rate (Android related metadata).
If the frame durations are wrong from your point of view, you need to fix it so it becomes really CFR and contact the developers of the tools which was used for creating that file and ask them why they did that.
Note: the "deleted a comment from" hints below are for messages used for providing the file and were not useful at long term, that's all.
I have excuted mediaInfo cli and I understand your previous comment.
if you have downloaded ffmpeg, and excute this command:
ffprobe -show_frames -select_streams v -of xml yourVideoFileName >tempFileName.txt
You'll find many info including pkt_dts_time and pts_time, Although pkt_dts_time's interval looks wierd due to the chip platform's VFR method of encoding the video, pts_time's interval is quite stable, so is it more accurate to count the max and min frame rate by pts_time?
pts_time's interval is quite stable
ho, I see, we were too lazy and checked only stts
(so the DTS) atom and not the ctts
(Composition Time To Sample, so PTS) atom, and usually it does not create a problem because intervals are more or less same.
We need to support better the ctts
atom.
Although pkt_dts_time's interval looks wierd due to the chip platform's VFR method of encoding the video
It is definitely weird! What is the purpose of such DTS???
But whatever the reason, it does not reduce the need to support better the ctts
atom.
On our free support todo-list so no ETA, let us know if you need a quicker fix.
(and now I see that you talked about pkt_pts_time in your first message, I stupidly skipped it, my mistake)
So it is true that average of the 2 frames is 3003/90000 = 29.97 fps but well, if it is constant frame rate why not having 3003 for all frames
Because that is the original issue with mkv container. As it has only millisecond precision by default (and other than default was never used in history) and no DTS/PTS, only durations... You can store 25.000, but not 24 and 24/1.001 and etc.
It does not matter though, since the spec says what to do with this jitter: H264 spec (Annex C) and the MPEG-TS spec does cover the case of rounded timestamps. Blu-Ray files are still CFR irrespective of the precision of the timestamps.
Sometimes slightly quicker (<3003), sometimes slightly slower (>3003).
Bugs like this existed and still exist in ffmpeg and fixed in txmuxer. justdan96/tsMuxer#686