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

[Olivier Galibert]

On Mon, Jul 26, 2010 at 12:22:18PM -0400, 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.

TCP is not stateless.  The 4-uplet (source ip, source port,
destination ip, destination port) has to stay constant for the whole
connection.  When you switch from Wifi to 3G you change of ip address,
and as a result all your TCP connections are lost.  There is also data
associated with a live connection such as current message number,
current ack position, window size, un-acked data, that kind of stuff.
That's why TCP has timeouts and UDP, the stateless one, doesn't.

A number of protocols built upon TCP, including HTTP as you say,
include restarting capabilities on a new connection and they sometimes
even work[1], but TCP definitively doesn't intrinsically.

  OG.

[1] Authentication for a start can fuck things up