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

[Martin Storsjö]

Hi,

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

> On Mon, Jul 26, 2010 at 12:29 PM, Martin Storsj? <martin at martin.st> wrote:
> > 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.
> 
> I totally agree. Both demuxers and protocols should stay off of this
> stuff. It's the application's job to do this. So we need to expose
> that this is possible to the application. Realmedia/RDT (or
> .rm/.avi/.matroska files that have multiple tracks, or DVDs with
> multiple soundtracks) show what API we use for that. I'd like you to
> use this API also, even if only for consistency.

Ok, I can give it a try. Doing it that way makes some things prettier, but 
some other things get a bit uglier.

In this setup, we'd need to convey info about which streams belong to 
which bandwidth variant, since (especially in low bandwidth setups), you 
wouldn't want to pull video from one stream and audio from another one, 
forcing you to receive both variants.

// Martin