Menu
▾
▴
Re: [Libquicktime-devel] FFmpeg plugin resync DNW for out-of-order B-frames after full sync keyframes
|
From: Derek C. <der...@mi...> - 2014-08-19 15:26:40
|
Just realised I didn't attach those updated patches - sorry! On 29 July 2014 17:19, Derek Chow <der...@mi...> wrote: > Ahh here's a more up to-date version of the latter 2 patches: > > [fix_long_gop_resync_next_display_frame.diff] > - fixing a comment and error clause for > lqt_packet_index_get_next_display_frame(). -- Note that it only > handles keyframes, assuming they will not have negative ctts. > > [fix_resync_bframe_skipping.diff] > - updated patch to avoid hunk offset/fuzz - otherwise nothing changed here. > > On 29 July 2014 16:57, Derek Chow <der...@mi...> wrote: >>> 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. >> >> >> [fix_long_gop_resync_next_display_frame.diff] >> I noticed that quicktime_set_video_position() and >> quicktime_init_maps() was missing a check for next_display_frame >> values when the keyframe it leaves on actually has a 'ctts' offset. >> Hence I added a lqt_packet_index_get_resync_display_frame() method to >> help. >> >> >> And finally... >> [fix_resync_bframe_skipping.diff] >> Possible fix for the issue I've mentioned in this thread for resync - >> lemme know what you think: >> - Rather than skip the entire first group of B-frames (at risk of >> skipping reference B-frames, or those that were part of the output we >> want to keep), skip any B-frame provided that: >> - they aren't reference frames; >> - they are truly 'obsolete' by the definition that their PTS is >> less than the desired timestamp. >> Also includes: >> - Fix for crash when trying to call avcodec_flush_buffers() when >> there isn't a valid structure for it (possible when calling seek >> before any decoding)/ >> - Adjusted signature of lqt_packet_index_get_next_display_frame() and >> hence renamed it to lqt_packet_index_increment_display_frame() for >> more code-reuse. >> - Fix to increment 'next_display_frame' when skipping B-frames so >> that the while() loop terminates accurately. E.g. Seeking to PTS 2 >> when samples starting from the keyframe go 2, 0, 1... will feed the >> first sample, then skip the 2nd and 3rd before terminating the loop. >> >> >> I've come across a horrible file with duplicate PTS, are we supposed >> to feed both samples and expect only one frame for the PTS to come >> out? See snippet of qtdump output below: >> ... >>> composition time to sample (ctts) >>> version 0 >>> flags 0 >>> total_entries 82615 >>> count 1 duration 0 >>> count 1 duration 1000 >>> count 2 duration 0 >>> count 1 duration 1000 >> ... >>> Packet index (generated) >>> num_entries 84530 >>> pos 1799498 pts 0 dts 0 dur 1000 sz 14031 FT I stsd_id 0 key ref >>> pos 1813529 pts 2000 dts 1000 dur 1000 sz 31711 FT P stsd_id 0 ref >>> pos 1845240 pts 2000 dts 2000 dur 1000 sz 42 FT P stsd_id 0 ref >>> pos 1845282 pts 3000 dts 3000 dur 1000 sz 34804 FT P stsd_id 0 ref >> >> >> >> Cheers > > > > -- > > > Derek Chow / C++ Developer > > der...@mi... / +44(0)7825373230 > > Office +44 (0)207 884 2530 > 21 Broadwall, London, SE1 9PL, United Kingdom > http://www.mirriad.com -- Derek Chow / C++ Developer der...@mi... / +44(0)7825373230 Office +44 (0)207 884 2530 21 Broadwall, London, SE1 9PL, United Kingdom http://www.mirriad.com |
