I believe this is usually done with two (or more) threads, like a
solution for the producer-consumer problem. A producer connects to a server
via HTTP, makes a request, and starts copying the response into a buffer.
When the consumer feels that enough data has been buffered to ensure smooth
playback, the consumer starts consuming the buffer, and rendering it on
screen.

   - Oliver

Streaming is best done with UDP so you just discard packets that don't
arrive in time and do the best you can.  So you are not using HTTP.

To do it with HTTP you could just ask for a giant file, and start
sending it. HTTP does not necessarily tell you how big the file is to
start.   The receiver buffers up x seconds before starting the video,
and if it ever outruns the buffer, it just stops and lets the buffer
fill again, so on a slow line in lurches along, put plays full speed
when it can.

Streaming over HTTP is done in may different ways. Often the streaming
in the end is not done via HTTP, but just initiated via HTTP. E.g.:

- The server just sends an "endless" file in its response, with a
corresponding media mime type.

- The server sends back some proprietary data with a MIME type which is
actually associated with some other application. The browser hands the
data over to that other application, e.g. some media player. That other
application interprets the data as some information on how to access a
stream, and does so.

- The server sends back some standardized contend description, e.g.
SMIL. The browser hands the data over to some application which can deal
with it.

- The server sends back some HTML which has an embedded player object
definition. The browser starts the player with the parameters provided
in the HTML (one being the actual streaming source) and the player
accesses that source.

There are probably some more techniques.

/Thomas