Re: [Libquicktime-devel] FFmpeg plugin resync DNW for out-of-order B-frames after full sync keyframes

[Burkhard P. <pl...@ig...>]

Hi,

Am 29.07.2014 um 17:57 schrieb Derek Chow:
>> By the way I've also checked in a new possible variant of the resync() function
>> in the ffmpeg decoder.
>
> Okay, sorry for the delay, but here some fixes I've got for the new
> resync code (apply in order as listed).
>
> [no_negative_pts.diff]
> I decided to remove the logic that ensures the first decode sample
> also PTS 0 (so it could be greater than 0 due to ctts offset), for the
> following reasons:
>   - it's more intuitive to pass 0 instead of some negative value to
> lqt_seek_video(), to seek to the beginning of the video;
>   - according to lqt_seek_video()'s doxygen comments, it doesn't expect
> negative time parameters (though the logic seems okay otherwise);
>   - lqt_packet_index_get_next_display_frame doesn't expect there to be
> negative PTS.

-      e.pts += ctts->table[ctts_index].sample_duration -
-        ctts->table[0].sample_duration;
+      e.pts += ctts->table[ctts_index].sample_duration;

This is necessary because the ctts values are defined differently by quicktime and mp4.

In quicktime, the first PTS is equal to the first DTS, which implies that for some frames
the ctts values are negative, resulting in DTS > PTS (violating causality). Not a big deal if
you assume that PTS and DTS are on different scales, which are shifted by the maximum decoding
delay.

In mp4, DTS is always < PTS.

The code for calculating the pts does this right for both cases because the first ctts value is
alaways zero for quicktime and max_decoding_delay for mp4. I don't see how the PTS can get
negative here.

Didn't look at the other patches yet.

Burkhard