[Libav-user] Improving HTTP demux throughput

[wm4]

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

> It's delightful that libav can directly open remote files for demuxing via
> HTTP, and I've been impressed with its usability and performance in that
> regard for most cases. It handles HLS like a champ.
> 
> But certain videos are demuxed extremely slowly, with calls to
> av_read_frame() averaging out to 100 ms or more even on a local network. The
> examples I see this happen on are usually Quicktime videos, some created by
> iOS devices and some not. And this is on Windows systems, if that matters (I
> haven't been in a position to try it on anything else).

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.

> The only thread I could find that seemed relevant was this one:
> http://libav-users.943685.n4.nabble.com/Libav-user-Why-is-HTTP-streaming-so-slow-td4653420.html#a4653560
> Which never really got resolved other than postulating that the socket
> buffer size was to blame. I tried increasing the socket receive buffer in
> ff_listen_connect(), but all that did was make it considerably worse.
> 
> The culprit videos seem to require frequent seeking in the muxed content, in
> order to demux it. It's no surprise, then, that libav demuxes them much more
> slowly, if it only maintains one socket connection at a time and has to keep
> creating new sockets each time it dances back and forth instead of
> downloading contiguous data.
> 
> I suspect the problem is the way the separate streams within the file are
> arranged, since it seems as though the audio is all demuxed from a few MB at
> the beginning, while the video comes from the entire length of the file. So
> is there any way to get libav to demux only one stream when av_read_frame()
> is called, rather than dancing about creating new sockets each time it moves
> back and forth between the streams?

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.

> Or, barring that, is it possible to get it to maintain more than one socket
> while demuxing content streamed via HTTP over a network, so that separate
> streams of contiguous data can be efficiently read? Or any other suggestions
> for speeding up demuxing in this sort of case would of course be
> appreciated!
> 
> Thanks!
> 
>