(GO) live555-based streaming media proxy forwarding server

For the concurrent volume is not large and the performance requirements are not very high streaming media transmission module, LIVE555 is still a good choice, the following is the implementation of the streaming media proxy server (currently can only achieve H264 single video forwarding) proxy forwarding main

For the concurrent volume is not large and the performance requirements are not very high streaming media transmission module, LIVE555 is still a good choice, the following is the implementation of my streaming media proxy server (currently can only achieve H264 single video forwarding)

Proxy forwarding is mainly divided into the forwarding of RTSP and RTP forwarding (no implementation of the RTCP forwarding), as far as possible to do not destroy the original program framework, so or the entire agent process into the servermediasubsession, Source, Sink cycle, in accordance with the process , the RTSP options are not required to be forwarded and go directly to the describe forwarding process.

Decribe forwarding: After looking at a lot of large streaming server protocols, you will find that there is a common point: the front-end device will be registered to the streaming server after its own both real-time resources and video resources are escalated to the streaming media server centralized management, then here in the same way, in the streaming media server online ( Active registration and KeepAlive) instead of actively requesting resources to the front-end, here is to send the describe request, I implemented a proxy server, specifically defined a class, inherited from Rtspclient, to the front-end device to send describe requests, successfully received the SDP information to carry the feedback, Generate mediasession based on the SDP information, and then execute each of the Mediasubsession initiate () so that the source that is sent by the front end is ready, and after each mediasubsession is established , add servermediasubsession to the servermediasession of the corresponding stream (here servermediasubsession inherits from Ondemandservermediasubsession), This will do a servermediasubsession corresponding to a mediasubsession (here must distinguish between servermediasubsession and Mediasubsession), two-way session connection, The following is the client initiated the DESCRIBE request, go to Rtspserver::rtspclientsession::handlecmd_describe (), and then go to servermediasession:: Generatesdpdescription (), because is forwarding, and can not let the client know is forwarding, so the SDP information in the M field before the parameters are based on the proxy server itself, starting from M is the real media information, the original live555 structure, Get each track of the Sdpline is made by virtual char const* ondemandservermediasubsession::sdplines (); So, we can rewrite this virtual function and return what, Returned is the Savedsdplines () return value of the mediasubsession we just passed in. In this way, the SDP information can be constructed on the basis of not destroying the original live555 cycle, and the implementation is forwarded.

SETUP forwarding: Same as describe, the original framework has been formed, after receiving the SETUP request, find Rtspserver::rtspclientsession::handlecmd_setup (), and then find virtual void Ondemandservermediasubsession::getstreamparameters (), in the original live555 loop, this function is to establish a local receive port, Set up the Createnewsource and Createnewsink, the parts of the data transfer loop are ready, once you receive the play command to start the cycle of work, then also rewrite this virtual function, in the override to implement a setup request to the front end, Wait for the response to succeed, and then execute the local setup, send the setup implementation to the front end can also be passed by the "rtspclient inherit" and mediasubsession to implement the Send command, waiting to return, Continue with ondemandservermediasubsession::getstreamparameters () to implement the local setup, so that both the local and remote setup are complete.

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

The above has been the implementation of RTSP forwarding, and basically on the basis of the original live555, no damage to the original frame structure, the following RTP forwarding.

The focus of RTP forwarding implementation is to build a loop of source to sink, rewrite Ondemandservermediasubsession::createnewstreamsource, With Ondemandservermediasubsession::createnewrtpsink, the ideal forwarding is able to achieve the received RTP packet without any reorganization, directly sent can, But I realized only by mediasubsession in the Readsource get a complete frame, and then to Rtpsink for re-slicing assembly, concrete to implementation, I implemented a class integrated from H264videostreamframer, and pass Mediasubsession->readsource as InputSource, rewrite Dogetnextframe (), get a full frame from InputSource, copy to FTO, again to Createnewrtpsink () returned to the H264videortpsink to re-assemble and send, later taking into account such practices, advantages and disadvantages, and do not reassemble, direct delivery, each has been considered.

So, the implementation of the RTSP and RTP forwarding function, there are improper, follow-up will continue to improve, but also hope to be able to correct in the message!

2012.3.23

A friend asked Rtcp's forwarding question, here to explain my understanding:

Forwarding rtcp The actual meaning is not very large, one aspect is that RTCP control may be two data links, the control of congestion is always on the basis of a small link, the sacrifice is too large; second, as a server consideration, the server through the dual identity of the data to be sent out again, control coordination should be fully autonomous, If later in the server to join the cache mechanism to achieve jitter control and congestion control, can be through to the line and the RTCP control of the outlet to achieve control effect, and the effect is better!

Transferred from: http://www.easydarwin.org/article/Streaming/1.html

(GO) live555-based streaming media proxy forwarding server