Crtmpserver flow to Nginx rtmp and SRS (Simplertmpserver) Experience

I have been using the Crtmpserver service, in the Crtmpserver service according to their own ideas also added a lot of functions, such as through the HTTP interface to load configuration, such as the lack of support HLS, since the added TS fragmentation level is limited, Reasoning decided to use Simplertmpserver's HLS function. Say dry, immediately find related resources, download, decompression, a smooth, SRS smoothly set, than the imagination is much simpler.

SRS Service set up, straight guess test success, in the configuration Crtmpserver flow, SRS stream play out, see log found a tcurl can not be empty exception, so think should be crtmpserver in the push without passing tcurl parameters, View the source code of the Crtmpserver, positioning to the position of the push, follow the tcurl to confirm the empty, understand the Tcurl format, and TargetUri is consistent, so will TargetUri value to Tcurl, test smoothly passed, is so simple, but, After a period of running down to find the SRS seems to be unstable, perhaps it is not very understanding. Perhaps see everyone is using Nginx HLS, then have the SRS to replace Nginx idea.

In the construction of Nginx rtmp service is referred to the predecessors left behind the Nginx build support for the HTTP and rtmp protocol, one of the streaming media server, two or three, because it is the first time in the Nginx to add Nginx-rtmp-module module, the feeling and SRS compared with the relative annoying lock, A lot of dependency packages are either more dependent on the version or the link is not open. Overall the whole process down to build a smooth.

Nginx configuration has been used before its reverse proxy and front-end cache, configuration is also handy, very soon can be used independently, but I set up nginx purpose is to do rtmp edge, to provide rtmp and HLS playback. In the test, the same also encountered Crtmpserver to Nginx when the unsuccessful, in the Nginx log also did not find anything unusual, and direct push, compared to the discovery of the push of the connection, successful and then immediately disconnected, after repeated comparisons, Direct push is a successful connection after the creation of a stream, publish the flow of the log As follows:

2015/01/09 17:13:12 [INFO] 6587#0: *8 client Connected ' 10.22.22.245 '
2015/01/09 17:13:12 [INFO] 6587#0: *8 createstream, client:10.22.22.245, server:0.0.0.0:1936
2015/01/09 17:13:12 [INFO] 6587#0: *8 publish:name= ' snh48_live_640_360 ' args= ' type=live silent=0, client:10.22.22.245 , server:0.0.0.0:1936

There is no log of createstream and publish in the log of the push, then doubt whether it is the problem of crtmpserver itself. In order to verify, immediately opened the Crtmpserver for local debugging, found that an error log, the content is:

Basertmpprotocol.cpp:799:basertmpprotocol::P rocessbytes:unable to send rtmp message to application.

And that's what this thing is doing, finding this code quickly:

						if (!_pprotocolhandler->inboundmessageavailable (this, header, Channel.inputdata)) {
							FATAL (' Unable to send rtmp Message to Application ");
							return false;
						}

After analysis, it is estimated that crtmpserver to Nginx returned message is not supported, but do not want to go to see the nginx frame, so the idea of the bold directly to return false comment off run.

						if (!_pprotocolhandler->inboundmessageavailable (this, header, Channel.inputdata)) {
							FATAL (' Unable to send rtmp Message to Application ");
							return false;
						}

Debugging again, really brilliant. Then I tested the other types of streaming media services, and I smiled again ...