[Libav-user] Improving HTTP demux throughput

[wm4]

On Thu, 30 Oct 2014 17:04:07 -0700 (PDT)
Jabotical <james.nickerson at vistasystems.net> wrote:

> wm4 wrote
> > Generally, huge latencies are to be expected when a av_read_frame()
> > call switches the segment (because it makes a new connection). The only
> > solution I found was buffering data between demuxer and the rest, and
> > running the demuxer in a separate thread.
> 
> Right, that makes sense. Though if you're referring to HLS segments, I
> should make it clear that HLS videos are in fact among the ones that work
> the best.
> 
> I guess what I'm asking could be summed up as "Is there a way to minimize
> the number of times an av_read_frame() call makes a new connection?" It's
> doing this *multiple times per frame* for some videos (again, not HLS, just
> certain Quicktime files).

Then I misunderstood.

From what I understand, mov/mp4 files can be indeed quite terrible at
this, and require heavy seeking. The file format was not designed with
streaming in mind (insert grumpy note about Apple mis-engineering), and
they are often not properly interleaved.

I don't actually know much about mp4 file structure itself, but maybe
you could analyze the seek patterns, and determine yourself whether
some sort of caching could reduce the seeks.

Actually using multiple connections sounds a bit unrealistic, because
it'd probably raise code complexity a lot.

> I'm already buffering data between the demuxer and the rest, and running the
> demuxer in a separate thread. The problem is that for certain videos, the
> throughput is abysmal. Calling av_read_frame() as fast as I can in its own
> thread gets me like 300-500 kB / s (~2.4-4 Mbps) of video demuxed. For
> longish videos with any sort of typical bitrate, that makes for a
> loooooooooong time buffering.
> 
> This is opposed to videos where the demuxer doesn't make a new connection
> every time you read a frame -- which includes every HLS video I've tried --
> where I see many times that throughput.
> 
> 
> > I don't know HLS very well, but if it really switches back and forth
> > between the same segments (i.e. keeping http connections open would
> > help), the libavformat implementation probably can't handle this
> > efficiently. Then it will keep behaving bad until someone goes and
> > fixes it.
> 
> Thanks for the feedback! But as noted above, I probably wasn't clear --
> *this problem isn't due to HLS*, and HLS content always works wonderfully.
> Presumably because it's been muxed in a way that's friendly to streaming.

Yep, sorry.

> Again, I appreciate the reply!
> 
> I have since noted that XBMC seems able to stream some videos via HTTP that
> I'm having trouble with, even though they're using ffmpeg and their code
> looks similar. Zeranoe's ffmpeg libraries have exactly the same results as
> with libav ones I built myself.

XBMC might be using their own mp4 demuxer, or so. Or possibly have
hacks by providing their own HTTP I/O.