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

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

Hi,

Am 24.04.2014 18:21, schrieb Derek Chow:
> Apologies, the problem still happens with my latest
> resync_bframes_after_full_sync_frames3.patch - I want to change the
> line:
>
> int skip_initial_bframes = sync_disp_frame <= target_display_frame;
>
> to
>
> int skip_initial_bframes = sync_disp_frame < target_display_frame;
>
> but will need to investigate a suspicious side-effect I'm having with
> my test file...

By the way I've also checked in a new possible variant of the resync() function
in the ffmpeg decoder.

There are 2 new variables in the core:

- vtrack->track->idx_pos:     Index position of the next packet to be read
- vtrack->next_display_frame: Index position of the next frame to be displayed

next_display_frame is updated by lqt_packet_index_get_next_display_frame() in the core,
which simply looks +/- 32 packets relative to the last frame and takes the one with the closest
PTS. It's the most brain-dead variant but it should work for all kinds of weird reordering
schemes as long as there are less than 32 consecutive B-Frames.
In the ffmpeg plugin, this makes the decoding_delay variable unnecessary.

Seeking now works like:

quicktime_set_video_position() seeks to a frame in *decoding* order, it sets both
vtrack->next_display_frame and vtrack->trak->idx_pos to the keyframe before the target
frame, and vtrack->timestamp to the target PTS.

The resync() function in the ffmpeg plugin reads packets until we reach the target PTS.
Obsolete B-frames and non-reference B-Frames are simply skipped, i.e. they aren't even sent
to libavcodec. I started testing this a bit with H.264 streams and found no obvious problems
so far.

For seeking to a frame in *display* order, use lqt_seek_video(), which takes a PTS as argument
and thus also works for variable framerate streams. It looks in the index for the target frame
and calls quicktime_set_video_position().

Burkhard