I have been using the Crtmpserver service, in the Crtmpserver service according to their own ideas have also added a lot of features, such as through the HTTP interface to load the configuration, suffering from not support HLS, self-added TS Shard level and limited, reasoning decided to use Simplertmpserver's HLS function. Say dry, immediately find related resources, download, decompression a quick, SRS smooth ride, than imagined is much simpler.
After the SRS service is set up, the direct speculation is successful, in the configuration Crtmpserver retweets stream, the SRS stream does not play out, view the log discovery reported a tcurl can not be empty exception, and thought should be crtmpserver in the retweets did not pass the Tcurl parameters, View the source code of the Crtmpserver, navigate to the position of the retweets, with the comprehensive down to confirm that tcurl is empty, understand the Tcurl format, and TargetUri is consistent, so TargetUri value to Tcurl, the test passed smoothly, It is that simple, but, after a period of time running down to find that SRS seems to be less stable, perhaps it is not very familiar with it. Perhaps see everyone is using Nginx HLS, so there is the idea of replacing SRS with Nginx.
< Span style= "Color:rgb (51,51,51); font-family:arial; font-size:14px; line-height:20.020000457763672px "> When setting up the Nginx rtmp service, we refer to the predecessor's nginx build one of the streaming media servers that support HTTP and rtmp protocol, two or three, because it is the first time nginx Add Nginx-rtmp-module module, feel compared with the SRS relative annoying lock, a lot of dependent packages are either more dependent on the version, or simply link cannot open. Overall, the whole process was built smoothly.
nginx configuration has been using its reverse proxy and front-end cache, configuration is also handy, very quickly can be used independently, but I built nginx to be used to do the edge of rtmp, to provide rtmp and HLS play. In the test, also encountered the Crtmpserver retweets to Nginx unsuccessful, in the nginx log also found nothing unusual, compared with direct push, found push connection, success and then immediately be disconnected, after repeated comparisons, Direct Push is when the connection is successful there is a log to create the stream and publish the stream, 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 retweets, will doubt it is crtmpserver itself problem? in order to verify, and immediately opened the Crtmpserver for local debugging, found a more 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 strange, fast find this piece of code:
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 also do not want to see the nginx frame, so the idea of bold directly will return false comment out run to see.
if (!_pprotocolhandler->inboundmessageavailable (this, header, Channel.inputdata)) {FATAL ("Unable to send rtmp Message to Application ");//return false;}
Re-commissioning, sure enough. I also tested the other types of streaming services, and I laughed ...
Crtmpserver retweets the experience of streaming to Nginx Rtmp and SRS (Simplertmpserver)