Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the principle of http push". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the principle of http push"?

Mature media applications are often faced with such needs:

Custom encapsulated video

Encrypted audio and video

Docking third-party non-standard media sources

Players of different architectures are supported

……

One of the more flexible solutions is to push custom media data to http, and most players can well support http (vlc/ffmepg/mediaplayer/ijkplayer/kodi, etc.).

The data flow indicates:

This article mainly explains the http protocol part of the above figure.

Http protocol foundation

Http protocol is an application layer protocol that uses tcp for transmission.

The request message is the content sent by the player (http client) to the http server. It consists of the request method, request URI, protocol version, optional request header field and content entity, such as:

POST / media HTTP/1.1Host: 127.0.0.1:8000Content-Type: application/x-www-form-urlencodedContent-Length: 10path=/tmp/1.mp4

Line 1 contains the request method, request URI, and protocol version, lines 2-4 are the request header fields, and the last line is the content entity.

The response message consists of the protocol version, the status code, the status code reason phrase, the optional response header field and the entity body, such as:

HTTP/1.1 200 OKContent-Length: 53Content-Type: text/html...

The first line contains the protocol version, status code, status code reason phrase, lines 2-3 are the response header field, and the last few lines are the body, which is what the browser usually renders.

Streaming media-http chunk

Streaming media is like a stream to transmit video data through the network to the terminal to play.

When streaming media is pushed through http, it corresponds to the chunk transmission of http.

A typical (response) message transmitted by chunk is as follows:

HTTP/1.1 200 OKTransfer-Encoding: chunkedContent-Type: video/mpeg400...ad....fxa.400xai.0

That is, the client is told through Transfer-Encoding: chunked that the data is being transmitted in chunks, so that the client maintains the connection until the data is received.

In the process of data transmission, each chunk is transmitted in the format of size\ r\ ndata\ r\ n, and finally notifies the client that the data is completed with a size of 0.

Streaming is often used for live streaming in multimedia applications, because the length of live data is generally variable, so media data can be continuously transmitted with the help of this long connection between the client and the server.

File Media-http range

The disadvantage of streaming media is that it can't jump in.

Not being able to jump in not only means that the user cannot watch the program on seek, but also means that the information of some programs cannot be obtained (such as duration).

To support jump-in, you can use http's range request.

Range requests are often known as breakpoint continuation, which allows clients to request data of any length from any location from the server.

For example:

POST / media HTTP/1.1Host: 127.0.0.1:8000Content-Type: application/x-www-form-urlencodedContent-Length: 10Range: bytes=500-1000path=/tmp/1.mp4

This request message requests 500-1000 bytes of data from the server through Range (501 bytes in total, the first byte is index 0).

If the server can return this part of the data correctly, it replies:

HTTP/1.1 206OKContent-Length: 53Content-Type: video/mpegAccept-Ranges: bytesContent-Range: bytes 500-1000/1024Content-Length: 501.

Accept-Ranges:bytes means to receive range requests in bytes; Content-Range tells the client which range of the returned data corresponds to, where 1024 is the length of the entire media; Content-Length indicates the length of the returned data (1000-5001.501)

Therefore, when the player plays the http source, the seek is to read the data from the target location of the seek by initiating a new http request and adding the Range field to the request.

However, the actual situation will be more complicated.

First, the player may jump to the tail to read the video data at the beginning of the playback to determine the program duration (for example, ts encapsulation needs to read the tail data to estimate the video duration)

Second, seek may need multiple range requests to jump to the target location (for example, ffmpeg will use binary lookup to find the target point in time)

Third, http is stateless, so the processing thread of each request from the client may not be the same, and there is no correlation between multiple http requests on the same VOD. This is irrelevant for static file resources, but for dynamic memory resources (such as dynamically decrypted video), multithreading and session management need to be handled carefully.

VOD Management-http session

As we learned in the previous section, the implementation mechanism of seek based on multiple range request will result in multiple communications between the server and the client during a single VOD. Due to the stateless nature of http, these communications are unrelated, and the server has no way to know that these communications correspond to the same VOD.

The general solution is to use the cookie mechanism of http to carry the id field for session association in multiple communications. The schematic diagram is as follows:

Corresponding to the http message is:

"first correspondence":

POST / media HTTP/1.1Host: 127.0.0.1:8000Content-Type: application/x-www-form-urlencodedContent-Length: 10Range: bytes=0-path=/tmp/1.mp4

"your id is 123":

HTTP/1.1 206OKContent-Length: 53Content-Type: video/mpegAccept-Ranges: bytesContent-Range: bytes 0-1023/1024Content-Length: 1024Set-Cookie: id=123....

"my id is 123 range 500-1000":

POST / media HTTP/1.1Host: 127.0.0.1:8000Content-Type: application/x-www-form-urlencodedContent-Length: 10Range: bytes=500-1000Cookie: id=123path=/tmp/1.mp4

"your id is 123 and your request has been accepted":

HTTP/1.1 206OKContent-Length: 53Content-Type: video/mpegAccept-Ranges: bytesContent-Range: bytes 500-1000/1024Content-Length: 501Set-Cookie: id=123....

The above communication process mainly depends on the guarantee of Set-Cookie and Cookie fields. The protocol is also very simple. The server sends id=123 to the client through Set-Cookie, and the client recognizes that if there is a Set-Cookie, it will notify the server of the contents of the Set-Cookie in the Cookie in the next request.

The above is basically the core protocol needed to complete http push. To sum up:

Http transmission is based on tcp and is a reliable connection.

Transport streaming media can be transmitted using chunk

To support seek, you need to support range requests

In the seek implementation, if the server resources are dynamic, the session mechanism needs to be introduced through cookie.

At this point, I believe you have a deeper understanding of "what is the principle of http push". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.