EMS seems to have an issue when RTMP streams are closed.
I have 2 RTMP streams being published as /live/1 and /live/2. I open 2 instances of VLC and point them to /live/1 and /live/2. I get video. Great. So far.
I then stop publishing /live/1 which then causes the VLC instance that is viewing that video to stop. This is also great.
What is NOT great, is that the second VLC stream (the one showing /live/2) ALSO stops.
The publishing side is fine. No errors there. If I merely hit play again on VLC it will re-connect. This has to be some kind of bug.
I even made a nice video (complete with exposed passwords etc. but you can look those up online, so you’re none the wiser 🙂 )
Can you send to us the log files involved in your scenario?
We need to know what specific EMS version is being used in this scenario, and other factors which may be involved.
EvoStream Media Server (www.evostream.com) version 1.7.1 build 4491 with hash: 64b305253110afc4acd5aeaf87f0a0b0f9b53526 on branch: origin/release/220.127.116.11 – PacMan|m| – (built for Windows-8.1-x86_64 on 2016-06-17T09:33:23.000)
Relevant parts of the log here:
Full log here:
I wanted to try the latest version, but the license does not work. I’ve reached out to Bryan Meissner to get new one for 2.0.1.
To reproduce; use FFmpeg, Evostream and VLC
ffmpeg.exe -f gdigrab -framerate ntsc -video_size 640×480 -show_region 1 -i desktop -vf “format=yuv420p” -profile:v baseline -level 3.0 -vcodec libx264 -preset ultrafast -b 120k -f flv rtmp://localhost/live/1
(do the same for “2”)
Open 2 VLC instances, one pointing to the /live/1 and the other to /live/2
Then stop the first FFmpeg session (press “q” in the console window)
The VLC instance showing stream 2 gets disconnected.
We’ve fixed a similar bug before some time during that release.
Release 2.0.1 should be able to handle this scenario.
2.0.1 does not have the issue (and the nginx-rtmp test was not really valid as it does not support RTSP output). Thanks for the help guys.