After the beginning of the Node version of EasyDarwin development work, until today, March 27, 2018 online the first version, today millet released MIX2S, salute! Salute!!!

RTSP protocol

For now, this first release only supports RTSP Over TCP, but RTSP Over UDP will be available soon. In general, the RTSP protocol is relatively simple. In the development process, the understanding of RTSP protocol mainly refers to the RTSP protocol description. The analysis of SDP was written by myself at the beginning, and repeated references were made to understand the meaning of each FIELD of SDP. Later, I accidentally found the SDP-Transform library on NPM. It was very convenient to process SDP information, and I decided to star.

Two details of SDP are recorded:

  1. mMedia description has an attribute namedcontrolProperty, its value and subsequentSETUPThe request ofuriIt is clear that the tail ofSETUPIs it audio or video?
  2. SETUPThe request header carriedTransportThere is a parameter calledinterleavedThe common content of this thing isAn even number. - An odd number, these two values represent RTP transmissionChannel identification. An RTP packet is preceded by a 4-byte header: a 1-byte fixed $(0x24) character; 1 byte channel identifier; The RTP packet length is 2 bytes. That corresponds to the second byte in the header. Generally, even numbers represent data channels and odd numbers represent control channels.

Understanding the above two points is helpful to cache GOP for specific video formats in the RTP transmission process and achieve the effect of opening in seconds.

NodeJS efficiency issues

Parsing RTP packets from TCP streaming data is a test of NodeJS processing efficiency. In the initial phase, simply use the socket data event callback, as soon as the received data, go through the protocol parsing. The actual measurement found that all the way under the condition of playing are very stuck. Finally, we refer to the BufferPool implementation in Node-media-server, using Generator and yield. The protocol is parsed only when the length of received data reaches the requirement. In this way, the efficiency is greatly improved, and the playback is not stuck. In the middle, I also tried to use socket pipe to transfer RTP packets to the player, which is indeed very efficient and can also solve the playback delay. However, in this way, if a single RTP packet cannot be solved, GOP cache cannot be done, so it is abandoned.

A second open implementation

Combined with the media description in the SDP and the values of SETUP Transport Interleaved, it is possible to identify whether the content carried by an RTP packet is media data or control data, if media data, audio or video, and if video, what is the encoding format of video data. Based on these, when RTP packets carrying H264 data are received, key frame identification is performed and GOP is cached.

To identify H264 keyframes in RTP packets, it is necessary to understand RTP packet format, H264 NALU type, and fu-A subcontracting. Here I mainly refer to this blog on CSDN. RTP protocol full parsing (H264 bit stream and PS stream)

For more information

Security streaming media Internet live -QQ exchange group: 615081503

LiveGBS-QQ communication group: 947137753

WEB：www.liveqing.com

Tel: 187-0985-4855 (same as wechat)

Copyright © 2016-2019 at LiveQing.com