Live555-based streaming media proxy forwarding Server

Live555 is a good choice for streaming media servers with low concurrency and low performance requirements, next, let's talk about the Streaming Media Proxy server I implemented (currently only the single h264 video can be forwarded)

Proxy forwarding is mainly divided into RTSP forwarding and RTP/RTCP forwarding. Try not to destroy the original program framework, therefore, we still need to integrate the entire proxy process into the cycle of servermediasubsession, source, and sink. According to the process, RTSP options does not need to be forwarded and is directly transferred to the describe forwarding process.

Decribe forwarding: After reading many large streaming media servers, you will find the same point: after a front-end device registers with a streaming media server, it will report its own real-time resources or video resources to the Streaming Media Server for centralized management. Similarly, after the streaming media server goes online, it is changed to the frontend request resource. Here, the DESCRIBE request is sent. In the proxy server I implement, a class is defined and inherited from rtspclient, send a DESCRIBE request to the front-end device. After receiving the feedback with the SDP information, generate the mediasession Based on the SDP information, and then execute the initiate () of each mediasubsession (), in this way, the source that is sent by the front end is ready. At the same time, after each mediasubsession is created, add servermediasubsession to the servermediasession of the response stream (servermediasubsession inherits from ondemandservermediasubsession ), in this way, a servermediasubsession corresponds to a mediasubsession (servermediasubsession and mediasubsession must be distinguished here). The connection between two sessions is as follows: the client initiates a DESCRIBE request and forwards it to rtspserver: rtspclientsession :: handlepai_describe (), and then go to servermediasession: generatesdpdescription (). Because it is a forward message and cannot be known to the client as a forward message, the parameters in front of the M field of the SDP information are based on the proxy server itself, from m, it is the real media information. In the original live555 structure, the sdpline obtained for each track is
Char const * ondemandservermediasubsession: sdplines ();. Therefore, we can rewrite this virtual function. What will be returned? The returned value is the savedsdplines () value of the mediasubsession we just passed in. In this way, the SDP information can be constructed without damaging the original live555 loop and forwarded.

Setup forwarding: Like describe, the original framework has been formed. After receiving the SETUP Request, find rtspserver: rtspclientsession: handle+_setup (), and then find the virtual void ondemanservermediasubsession: getstreamparameters (), in the original live555 loop, this function is used to establish a local receiving port, create createnewsource and createnewsink, and prepare all the components in the Data Transmission Loop. Once the play command is received, the loop starts to work, similarly, this virtual function is rewritten to send a Setup request to the front-end. Wait until the response is successful and then run the local setup, sending the setup implementation to the front end can also be implemented by the "rtspclient inheritance" and mediasubsession just passed in, waiting for the return, and then continuing to execute ondemandserverme Diasubsession: getstreamparameters () implements local setup, so that local and remote setup is complete.

Play forwarding: Similarly, follow the process to rewrite the ondemandservermediasubsession: startstream () function, send the play request to a remote device, wait for the return, and then execute the local startstream (), both local and remote play are complete.

The above has already implemented the RTSP forwarding, And it is basically carried out on the basis of the original live555, without disrupting the original framework structure. The RTP Forwarding is carried out below.

The focus of RTP's forwarding implementation is to establish a cycle from source to sink, and rewrite ondemandservermediasubsession: createnewstreamsource, and ondemandservermediasubsession: createnewrtpsink, the ideal forwarding method is to directly send the received RTP packet without any restructuring. However, what I implement is that after obtaining the complete frame from readsource in mediasubsession, then it is handed over to rtpsink for re-slicing and assembly. Specifically, I implemented a class integrated from hsf-videostreamframer, passed in mediasubsession-> readsource as inputsource, and overwritten dogetnextframe (), obtain the complete frame from inputsource, copy it to FTO, and submit it to the hsf-videortps returned by createnewrtpsink (). Ink is re-assembled and sent. Later, considering this practice, there are advantages and disadvantages. If it is not re-assembled or directly sent, each has its own considerations.

In this way, the forwarding functions of RTSP and RTP are implemented. If there are many improper functions, we will continue to improve the performance in the future. I hope I can correct them in my message!

From http://blog.csdn.net/xiejiashu