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

wm4 nfxjfg at googlemail.com
Wed Mar 26 21:37:41 CET 2014

On Wed, 26 Mar 2014 21:28:13 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Wed, Mar 26, 2014 at 08:51:23PM +0100, wm4 wrote:
> > On Wed, 26 Mar 2014 20:42:37 +0100
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > > Well, it will still break those applications if they were previously
> > > used with a fast network link for example.
> > > Maybe this patch is indeed the pragmatic solution, it just doesn't
> > > feel great.
> > 
> > Making demuxing dependent on network speed seems to be a horrible
> > "solution". The only good thing about this is that it's not actually
> > network speed, but just a flag.
> That the other other patch will set by default based on whether the
> source is a network protocol.

Still gives different demuxing behavior on network vs. local playback.
So it's somehow fine to demux "less correctly" when playing over
network? I don't get it.

> > On the other hand, I'm not quite sure
> > what this code does, so maybe I'm not qualified to comment. (Though I
> > still wonder whether as a user I should set this flag or not. And what
> > does it have to do with networking? Fast, local connections do exist.)
> In all fairness, we are talking about one seek per packet.
> Many network protocols are crappy enough that 100 MBit Ethernet direct
> connection probably wouldn't count as "fast" or even "fast enough" in this
> context.

One seek per packet is going to be slow with local playback too. At
least it might confuse kernel readahead heuristics.

More information about the ffmpeg-devel mailing list