How is maximum frame rate and minimum frame rate calculated?

[wuyuanou]

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?

[JeromeMartinez]

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).

[JeromeMartinez]

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.

[wuyuanou]

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?

[JeromeMartinez]

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.

[JeromeMartinez]

(and now I see that you talked about pkt_pts_time in your first message, I stupidly skipped it, my mistake)

[ValeZAA]

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.

[ValeZAA]

Sometimes slightly quicker (<3003), sometimes slightly slower (>3003).

Bugs like this existed and still exist in ffmpeg and fixed in txmuxer. https://github.com/justdan96/tsMuxer/pull/686