[FFmpeg-devel] Problem with initial dts in h264

[Michael Niedermayer]

On Sun, Dec 06, 2009 at 10:30:29PM -0800, John Stebbins wrote:
> On 12/06/2009 07:15 PM, Michael Niedermayer wrote:
>> On Sun, Dec 06, 2009 at 03:26:30PM -0800, John Stebbins wrote:
>>> A recent change has caused the initial dts in h264 streams returned by
>>> av_read_frame to be incorrect.  The commit was r20599.
>>
>>
>>> This is especially obnoxious when the reader does a seek before
>>> av_read_frame.
>>
>> send a patch that resets pts_buffer in av_read_frame_flush()
>> (assuming its tested&  works of course)
>>
>> There may be further bugfixes needed but this one seems obviously missing
>
> I thought that something should be resetting pts_buffers, but didn't know 
> where that should be done.  So thanks for the pointer.  I think that 
> av_read_frame_flush should also be called from av_find_stream_info since 
> pts_buffer is modified during this function.  My patch does this.
>
> I did some testing, and this patch fixes the problem I saw.  But as you 
> noted, there seems to be more bugs.  I'm now seeing the dts start out ok. 
> But it looks like st->codec->has_b_frames starts out at 2, changes to 0 on 
> the second packet, then changes to 2 again a bit later.  When it changes 
> back to 2, dts once again gets the wrong value for a sequence of several 
> packets.  It appears that the change in delay screws up the ordering in 
> pts_buffers.

>  utils.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> f01ca2d0a99d9a66c38ed549c0e32a09118f4b56  initial_dts.diff
> Index: libavformat/utils.c
> ===================================================================
> --- libavformat/utils.c	(revision 20757)
> +++ libavformat/utils.c	(working copy)
> @@ -1177,7 +1177,7 @@
>  void av_read_frame_flush(AVFormatContext *s)
>  {
>      AVStream *st;
> -    int i;
> +    int i, j;
>  
>      flush_packet_queue(s);
>  
> @@ -1200,6 +1200,9 @@
>          st->cur_len = 0;
>  
>          st->probe_packets = MAX_PROBE_PACKETS;
> +
> +        for(j=0; j<MAX_REORDER_DELAY+1; j++)
> +            st->pts_buffer[j]= AV_NOPTS_VALUE;
>      }
>  }
>  

2 hunks above ok (if tested), (and maybe with FF_ARRAY_ELEMS())

remaining hunk looks wrong


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091208/ce524766/attachment.pgp>