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

[Ronald S. Bultje]

Hi,

On Mon, Jul 26, 2010 at 12:07 PM, Martin Storsj? <martin at martin.st> wrote:
> On Mon, 26 Jul 2010, Ronald S. Bultje wrote:
>> For example, so I can restream it with bitrate selection from my own
>> server later on. With RTSP (e.g. RDT/Realmedia), this is possible in
>> FFmpeg (though not in Xine, Mplayer or any of the others). It's tested
>> and works. That wouldn't work in your setup, unless you implement it as
>> a demuxer-with-chains...
>
> Umm, you can have multiple bitrates in RTSP? Do you receive them all at
> the same time if you want to backup them, as you say?

Yes.

> And how would that work for this setup? Do you mean that all the parallel
> streams should be available in the demuxer, so that I'd have high bitrate
> video in stream 0, high bitrate audio in stream 1, low bitrate video in
> stream 2 and low bitrate audio in stream 3? While it could be useful in
> some cases, I don't see that as a necessity. If you really want to get all
> of them, grab one bitrate per session, with many invocations in parallel.

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.

Ronald