[FFmpeg-devel] [PATCH 3/3] avformat/mov: be more tolerant with interleaving when seeking is slow

[Michael Niedermayer]

On Wed, Mar 26, 2014 at 07:34:28PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 26, 2014 at 05:59:02PM +0100, Michael Niedermayer wrote:
> > ---
> >  libavformat/mov.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 469da94..2a045d5 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3519,12 +3519,13 @@ static AVIndexEntry *mov_find_next_sample(AVFormatContext *s, AVStream **st)
> >          if (msc->pb && msc->current_sample < avst->nb_index_entries) {
> >              AVIndexEntry *current_sample = &avst->index_entries[msc->current_sample];
> >              int64_t dts = av_rescale(current_sample->timestamp, AV_TIME_BASE, msc->time_scale);
> > +            int max_distance = (s->pb->seekable & AVIO_SEEKABLE_SLOW) ? 3 : 1;
> >              av_dlog(s, "stream %d, sample %d, dts %"PRId64"\n", i, msc->current_sample, dts);
> >              if (!sample || (!s->pb->seekable && current_sample->pos < sample->pos) ||
> >                  (s->pb->seekable &&
> >                   ((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb &&
> > -                 ((FFABS(best_dts - dts) <= AV_TIME_BASE && current_sample->pos < sample->pos) ||
> > -                  (FFABS(best_dts - dts) > AV_TIME_BASE && dts < best_dts)))))) {
> > +                 ((FFABS(best_dts - dts) <= AV_TIME_BASE*max_distance && current_sample->pos < sample->pos) ||
> > +                  (FFABS(best_dts - dts) >  AV_TIME_BASE*max_distance && dts < best_dts)))))) {
> 
> Is it really a good thing to have two cases here?
> I'm tempted to say it only makes testing harder, since after this change
> any application needs to handle the larger desync to work with networked
> streams anyway, so what is the advantage of keeping the old limit?

currently if with networked files you are above the threshold
chances are the latency of seeking over the network will make
playback impossible
That patch is trying to fix that without breaking other things
changing the threshold unconditionally could break applications that
cant handle larger sync differences.

If someone has a better suggestion ?

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140326/a7ed3837/attachment.asc>