[FFmpeg-devel] [PATCH 2/2] avformat/mov: increase current_sample after reading, to avoid discontinuous sample

Zhang Rui bbcallen at gmail.com
Tue Jun 2 05:15:16 CEST 2015


2015-06-02 7:26 GMT+08:00 Michael Niedermayer <michaelni at gmx.at>:
> On Thu, May 21, 2015 at 12:31:21PM +0800, Zhang Rui wrote:
>> Discontinuous sample could cause corrupted image if next video frame
>> is non-key frame.
>>
>> Mostly, avio_seek() fails on I/O error for http/ftp/... stream.
>> In my opinion, retry is better than skip.
>>
>> > -    /* must be done just before reading, to avoid infinite loop on sample */
>> > -    sc->current_sample++;
>>
>> This line was first introduced in 2006 by commit b72708f8f.
>> I'm not sure if it worth an option to enable the new behaviour,
>> and keep the default behaviour as before.
>
> if its specific to avio_seek() should current_sample-- be done in
> its error case instead ?

Also to av_get_packet(). Not sure about avpriv_dv_get_packet().
current_sample-- would be OK to me.

> maybe with a retry count to limit retries in case the next sample
> can be read but the current always fails

Retry count could be used up soon, during a WiFi reconnection.
If we could recover from IO error at next packet, we also could recover
at current packet with sane position and size for most protocol, e.g.
http, ftp.

Skipping is also OK, but we need some flag to indicate that
the following packet is discontinued for decoder to flush data.

> Iam not sure i fully understand the bug this fixes,
> how can it be reproduced ?

Stream a normal H264 sample from http server.
and close the socket connection from server side while streaming.
( Paused player causes idle connection in real world ).
If client fails in the avio_seek() and make sc->current_sample++,
the next call to av_read_frames() could cause a reconnection,
which makes client to read next discontinued packet.


More information about the ffmpeg-devel mailing list