[FFmpeg-devel] [PATCH] Add Apple HTTP Live Streaming protocol handler

[Martin Storsjö]

On Mon, 26 Jul 2010, Ronald S. Bultje wrote:

> It goes further than backing up. As we know, TCP is stateless. We can
> download from a URI, transfer to a different WIFI network and the
> download will in fact resume (this can be at TCP-level or at HTTP
> level using the offset attribute - in this case I mean at the
> TCP-level). Imagine that I'm using "ffmpeg" (...) on a cellphone and I
> switch my iPhone from WiFi to 3G because I'm driving my car into
> no-man's-land, I'd like my streaming to continue, just dynamically
> switch to a different bitrate.
> 
> For RDT/Realmedia streams (and any local file), this works (press 'a',
> 'v' or 's' to switch audio/video/subtitle stream in ffplay). An
> intelligent application on my iPhone could do this dynamically
> depending on my current network settings (3G? edge? WiFi?) and/or
> bandwidth (as determined by whatever mechanism). This only works if
> such info is presented to the application.

Yes, and that can be implemented just as well on the URLProtocol level, 
automatically sensing the available bandwidth and switching to another 
variant playlist. The data fed to the demuxer simply suddenly is from 
another stream with lower bitrate, but the specs for this protocol 
mandates that the variant streams are similar enough so that this works.

Only if you want to manually control which bitrate variant is chosen on 
the fly would you need some more control over the receiving than what you 
can have with URLProtocols at the moment. But I don't think a demuxer is 
any better suited for it either - the bandwidth info is much better known 
at the URLProtocol level than forcing the application itself try to guess 
it and switch variants by adjusting discard flags for different demuxer 
streams.

// Martin