[MPlayer-dev-eng] mp4, vfr and timestamps

[Tomas Carnecky]

Michael Niedermayer wrote:
> for the case of mpeg1, mpeg2 and mpeg4 video there is a very
> simle rule how PTS/CTS must be set (no frame reordering CTS=DTS, frame reordering
> CTS=DTS for B frames, CTS of non B frames = DTS of next non B frame)

Thanks for the explanation..

But what should I do? If I set the framerate to the average framerate
over the whole video it will happen that cts offset is negative (which
isn't allowed), if I set the framerate to whatever the fastest framerate
is (eg. first find the smallest pts difference between two frames and
set num/den appropriately) then, if I have a long enough video, it will
happen that dts/cts will have an offset > 100 frames.

In x264 they use p_mp4->i_init_delay, which gets added to the CTS offset
if the video was coded with B-frames (to make sure the offset is
positive). But I can't guarantee that the DTS-PTS difference won't be
smaller than the initial delay (which is 1*i_fps_den). Without B-frames,
if my video contains a lot consequent frames that are faster than the
average FPS it will make the offset negative, with B-frames, it will
happen if there are too many consequent B-frames. This is an example of
such an situation (coded with --bframes 9):

dts   <=> pts   => offset
0     <=> 0     =>  1598
799   <=> 6548  =>  7347
1598  <=> 2399  =>  2399
2397  <=> 308   => -491
3196  <=> 689   => -909

You can see, frames 4 and 5 should be displayed much earlier than DTS,
but the initial delay isn't big enough to make sure the offset stays
positive.

I can increase the initial delay, but I'd like to stay inside the spec.

tom