Wrong fps information in MP4
A unified display of relevant technical and tag data for A/V files
Brought to you by:
guillaumeroques,
zenitram
I am not sure to understand the issue:
- frame duration is given by the stts (Time To Sample) atom, with a sample count, and a sample duration.
- Whatever is the frame order, theses frames have the duration from the stts atom.
I don't need any PTS or DTS for MP4, because frame duration is given by stts atom, so I use it. The minimum frame rate is given by the maximum frame duration, and the maximum frame rate is given by the minimum frame duration.
Why is this method wrong?
Do you have a sample of weird min/max, and what would be "right" values?
(I can provide a FTP server access if needed)
STTS[i] only represents dts[i]-dts[i-1]. When you calculate PTS or frame duration you should also take CTTS into account.
I will provide samples. Actually a less-than-1M sample will show the problem.
Or you can download my x264 build from www.sourceforge.net/projects/direct264.
Encode any cfr file with cmdline "x264.exe -o output.mp4 --force-cfr input.xxx". The output is cfr but mediainfo shows weird fps.
e,g. The source is 30fps, I encode with b-pyramid. MediaInfo shows minfps=30, maxfps=120.
OK, STTS-base framerate computing works well when DTS difference is not less than PTS difference (a DTS is in synch with a PTS of another frame), but in the case on of direct264, there is intermediate DTS, so CTTS is neeeded to compute the real PTS difference.
Since MPC-HC's MP4 splitter does not handle initial delay correctly (causing A/V desync), I use DTS compression to eliminate initial delay. And ffmpeg also produce such files.
I will be glad to see this problem being fixed.
I forgot to set the "Resolution" field to "Accepted", sorry. Done now.
Accepted.
Warning: non-paid bugs are set to low priority, I don't know when I have time to handle it.
If you desire to accelerate the development, don't hesitate to contact me for a quotation.