HTTP application Streaming Media Analysis
Strictly speaking, HTTP-based VoD is not really a streaming media. It is called "sive ssive downloading" or "pseudo streaming" in English. Why? Because HTTP lacks the basic Stream Control of streaming media, it is difficult to implement fast forward, return, and pause media playback Based on the HTTP protocol. Then, how does a media player use HTTP to implement such a function?
We all know that no matter how large a media file is, HTTP only regards it as an HTTP element. You only need to send an HTTP request, the web server will continuously push the media stream to the client, regardless of whether the client accepts it or not. This is why the HTTP protocol itself has no traffic control. What are the consequences?
If the server's streaming speed is synchronized with the client, there is basically no major problem. If the stream receiving speed is lower than the client's, the playback speed will be one card and one card; what will happen if the receiving speed is greater than or greater than the client's? Unfortunately, in all our istv projects, HTTP-based VoD is the third case. Because our VOD is based on the LAN, we all know that the bandwidth resources of the LAN are rich, and the server's streaming speed must be higher than the player's playback speed, so who is the limit on the server's streaming speed when the speed is extremely uncoordinated?
The answer is: TCP protocol stack.Our VOD is based on the tcp http protocol. TCP is safe and reliable, and the packet will not be lost. If the server detects that the client's receiving buffer is full, the size of the sliding window for sending data will be reduced. So
HTTP traffic control is adjusted through the TCP protocol stack, not HTTP itself. Imagine how much pressure this will put on the server !!!
The following describes how to implement operations such as seek and pause Based on HTTP.
1) Seek (fast forward and fast return)
First, close the previous TCP connection, reconnect, and send an HTTP request with the offset of the media. It can be seen that every fast forward and return is equal to restarting the playback, but the playing position is different each time.
2) pause
This operation is even more interesting. The client suspends playback, that is, it does not read data from the buffer zone. However, the server does not know that the client has stopped playing and still keeps sending data to the client, until the client's receiving buffer is full, the server's data cannot be sent. Theoretically, the size of the sliding window on the server is estimated to be 0, and the protocol stack is still trying to send data, because it is based on TCP, the data cannot be lost. Nnd: in this way, the protocol stack is suspended. Unfortunately, mplayer does this. So after a long pause, problems may occur.
Although HTTP does not support pause, it can be optimized for pause. The optimization method is to split the media file, and the size of the part is slightly smaller than the buffer size of the TCP protocol stack. The HTTP request only requests the size of one slice at a time. After the video is paused, no slice request is sent. This ensures that the server can run for a longer period of time, and the player suspension can theoretically be infinitely long.
HTTP application Streaming Media Analysis
