HTTP Application Streaming Media analysis

Strictly speaking, the VOD based on HTTP is not really streaming media, English is called "progressive downloading" or "pseudo streaming", why so? Because HTTP lacks streaming media basic flow control, it is very difficult to realize the fast forward of the media playback, fast rewind and pause based on HTTP protocol. So how does a typical Media player use HTTP to do this?

As we all know, regardless of the size of the media file, HTTP is only to see it as an element of HTTP, you can only send an HTTP request, the WEB server will continue to push the media streaming to the client, regardless of whether the client accepts, this is the HTTP protocol itself is not flow control reasons, So what's the consequence?

If the server's push speed and client synchronization, then basically do not have any big problem, if less than the client's receiving stream speed, then play will be a card one card, if greater than or larger than the client's reception speed, then what will be the result? Unfortunately, in all of our ISTV projects, as long as the VOD is based on HTTP, there is no exception is the third case. Because we VOD is based on the LAN, we all know that the bandwidth of the LAN resources are very rich, the server's speed of the push is definitely greater than the player's playback speed, then in such an extremely uncoordinated situation, the speed of the server's push flow by WHO to limit it?

The answer is: TCP protocol stack. Our VOD is based on the TCP HTTP protocol. TCP is safe, reliable, the package will not be lost, the server detects the client's receive buffer full, will reduce the size of the Send data sliding window. So the flow control of HTTP is regulated by TCP protocol stack, not HTTP itself. Just imagine how much pressure this has on the server!!!

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/web/Skills/

The following is an analysis of how to implement Seek,pause based on HTTP protocol.

1 Seek (Fast forward and rewind)

Close the previous TCP connection, reconnect, and send the HTTP request with the offset of the media. This shows that every time the fast forward and rewind, is equal to start playing again, but each start playing a different position.

2) PAUSE

The operation is more interesting, the client paused playback, that is, does not read data from the buffer, but the server did not know that the client stopped playing, still keep sending data to the client until the client's receive buffer is full, and then the server's data can not send out, Theoretically, the size of the server-side sliding window is estimated to be 0, and the protocol stack is still trying to send data because it is based on TCP, and the data cannot be lost. Nnd, this way to achieve a pause, the protocol stack is crying. Unfortunately, that's what MPlayer did. So the pause time is long, it is easy to have problems.

Although HTTP does not have pause support, but for pause can be optimized, the optimization method is that the media file fragmentation, fragmentation of the size of slightly less than the TCP stack buffer size is appropriate. The HTTP request only requests a fragment size at a time, and after the playback is paused, the fragmentation request is not sent. This ensures that the server is running for a long time, and the player pause can theoretically be infinitely long.