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

Olivier Galibert galibert
Mon Jul 26 18:51:09 CEST 2010


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



More information about the ffmpeg-devel mailing list