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

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

Hi,

Am 27.09.2014 um 13:57 schrieb Derek Chow:
> Okay, I'll keep in mind that this should also support MP4.
>
>> 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.
>
> In the beginning of this thread, as with the "quicktime_is_bframe()
> breaking for wobbly GOP pattern" thread, I describe an XDCAM quicktime
> file with initial non-zero ctts value... The qtdump output looks like:
>
> ...
>       composition time to sample (ctts)
>        version 0
>        flags 0
>        total_entries 46437
>         count 1 duration 2
>         count 2 duration -1
>         count 1 duration 2
> ...
>
> Hence the PTS gets negative!

Ahh ok, I think I know what this is:

PTS = DTS + CTS. Assuming your DTS is 0, 1, 2, 3.... you get (with the current code):

PTS1: 0 + 2 - 2 = 0  (First I-Frame)
PTS2: 1 - 1 - 2 = -2 (Obsolete B-Frame, should be skipped)
PTS3: 2 - 1 - 2 = -1 (Obsolete B-Frame, should be skipped)
PTS4: 3 + 2 - 2 = 3  (First P-Frame)

The problem is not, that PTS gets negative, in fact negative PTS are completely correct here.

The problem is that the stream contains some undecodable B-Frames (from before the first I-frame)
at the beginning. Hardware encoders like cameras like to do that. On the decoding side, such frames
should be skipped (i.e. not even passed to the decoder).

Burkhard