Recently, due to the need to implement RTSP-based transmission RM rmvb, no existing solutions have been found on the Internet. Only one live555 has implemented the RTSP service, but only supports RTP transmission of mpg, MP3, WAV and other formats. rm seems very unpopular in the Open Source Field, probably because the formats and protocols are private and not open. Then we started to develop rmvb over RTSP with live555 and commview tracking packages.
1 RTSP
First, implement the RTSP protocol. The RTSP protocol is relatively simple. Similar to the HTTP protocol, the main Commands include
Options, describe, setup, play, and teardown. The realplay player generally sends these commands in sequence to interact with the RTSP server.
Client Server
-------- Options ------------ à
<------ Options resp --------
-------- Describe ------------ à
<------ Describe resp -------
-------- Setup ---------------- à
<------ Setup resp -----------
-------- Play ------------------ à
<------ Play resp -------------
-------- Tear down --------- à
<------ Tear down resp -----
2 RDT
RDT is a proprietary protocol used by real to transmit RM format files. When RDT is used in the rtsp setup command, RDT can be used over TCP or UDP, and the format is relatively simple.
Table A. RDT data packet (non-aggregated)
012 78 24 32 64 80
++ ---- ++ --------------- ++ ----- + -------... + ------------- ...... +
| Seqno | rule | timestamp | reliable seqno | data |
++ ---- ++ --------------- ++ ----- + -------... + ------------- ...... +
^
|
| ASM rule
| Slow_data
| Back_to_back_packet
|
| RDT sequence number
| Is_reliable
| Stream_id
| Need_reliable (always true)
Length_included_flag
-------------------------------------------------------------------------------
3 Real challage between client and server
This protocol is a special proprietary protocol between Real Player and helix. When RealPlayer sends the option command, it sends the first clientchallenge, 32 bytes, the server should respond to realchallenge1 (32 bytes) in the resp, and then RealPlayer should send realchallenge2 in the setup command as a response to realchallenge1. The server should include a response to clientchallenge in the setup resp, is realchallenge3. That is:
Client Server
-------- Clientchallenge ---- à
<-------- Realchallenge1 ------
-------- Realchallenge2 ----- à
<-------- Realchallenge3 -----
The above process is limited to speculation. At present, algorithms are generated for realchallenge2, which is in the mplayer project. However, the generation of realchallenge1 and realchallenge3 does not have an algorithm. Currently, this process cannot pass.
4 SDP
Session Description Language Protocol
It is mainly used to describe the audio and video stream information of the file to be transmitted in the describe statement, including the rich information of the encoding format and frame rate, so that the player can prepare for decoding.
5 riff RM format
RM file format analysis: to transfer an RM file, you must first analyze the file format, then extract the data, and then package and send it.
References
The following are the standards referenced in this document:
Real Time Streaming Protocol (RTSP; RFC 2326)
Ftp://ftp.isi.edu/in-notes/rfc2326.txt
This specification references the HTTP spec by using the following notation: [H 3.2.1 ].
This example refers to section 3.2.1 In the http rfc.
Session Description Protocol (SDP; RFC 2327)
Ftp://ftp.isi.edu/in-notes/rfc2327.txt
Real Time Transport Protocol (RTP; RFC 1889)
Ftp://ftp.isi.edu/in-notes/rfc1889.txt
Hypertext Transfer Protocol (HTTP; RFC 2068)
Ftp://ftp.isi.edu/in-notes/rfc2068.txt