Hi Santos,
EMS will always close stale streams. As Bryan said, there is a small problem with the A/V codecs as well, but that is on a different stream (the next streaming attempt from the encoder).
A stream is considered stale if it doesn’t have any kind of audio/video traffic for a period of time. That period of time is the streamsExpireTimer configuration setting. It is expressed in seconds. Perhaps, at some point, the encoder takes a long-ish break from the encoding process!? A network glitch!? How much time of continuous encoding is it take to replicate this issue?
I have seen this things in the past with some other encoders.
This messages:
/thelib/src/protocols/rtmp/streaming/innetrtmpstream.cpp:566 stream: elemental_3564_0; this is not an AAC codec setup request. Ignore it: af01
/thelib/src/protocols/rtmp/streaming/innetrtmpstream.cpp:670 stream: elemental_3564_0; this is not a key frame or not a H264 codec setup request. Ignore it: 2701
Are 99.999% caused by the encoder. EMS is just issuing a warning about them. In plain english, EMS is saying that both audio and video streams were stimulated with A/V data BEFORE any kind of A/V codecs setup bytes. That is illegal but is tolerated by EMS.
As a quick suggestion, please try to increase streamsExpireTimer to 30 seconds. This timer is critically important for EMS. Without it, you can DoS the server by opening and not using thousands of streams. It can’t be deactivated, but it can be made to run at a longer periods of time
Best regards,
Andrei
Hi Andrei,
I already increase the streamsExpireTimer to 60 seconds and still the same issue.
I found some reports that these behavior is due some troubles in the rtmp library, but nothing much conclusive.
I’m still researching.
Tks.
admin
This information box about the author only appears if the author has biographical information. Otherwise there is not author box shown. Follow YOOtheme on Twitter or read the blog.
