Single stream / Multiple connections - Last connection is terminated prematurely? about node-rtsp-rtmp-server HOT 3 CLOSED

Hi, I'm sorry for the delay in response. I've fixed some bugs related to buffer management. Can you try the latest code?

At the same time, I couldn't reproduce your problem. VLC for OS X (version 2.1.5 and 1.1.9) and Windows (2.1.5) worked without problem when I tried the same as you reported.

Network throughput of Raspberry Pi is somewhat limited (you can check the actual throughput using iperf). Also, UDP performance of Node.js is not so good in my experience. If you're streaming high bitrate video, it can affect the other simultaneous connection. You might want to reduce the bitrate of your video. If you still have a problem at low bitrate such as 100 kbps, please let me know.

from node-rtsp-rtmp-server.

Thanks, I'll try to reproduce again and also test with your latest changes. I've noticed RTMP performance is much better than RSTP performance on my LAN.

A couple of unrelated questions you may know the answer to:

• When a client is streaming using RTMP (say over wifi) and it goes out of range and then comes back into range, the stream from the camera is not kept 'live', but instead starts to drift by what looks like the amount of time the device was out of range. Is there a way to keep the client receiving the most recent data?
• I've been comparing the performance of Strobe Media Player (flash) and VLC on OS X. With Strobe there is very little delay from the live stream, maybe half a second. With VLC the delay is more like 3 seconds. My guess is that this may be due to the Flash player using optimised GPU h264 decoding while VLC doesn't. Might this be correct? My objective is to find libraries that have minimal delay that can be used to build OS X and iOS apps (VLCKit unsurprisingly has the same delays as VLC on both OS X and iOS).

from node-rtsp-rtmp-server.

When a client is streaming using RTMP (say over wifi) and it goes out of range and then comes back into range, the stream from the camera is not kept 'live', but instead starts to drift by what looks like the amount of time the device was out of range. Is there a way to keep the client receiving the most recent data?

I've found a solution to that problem. By using Strobe Media Playback's JavaScript API, a client can calculate the drift and reconnect when the drift is too large. You can freely use this example.

I've been comparing the performance of Strobe Media Player (flash) and VLC on OS X. With Strobe there is very little delay from the live stream, maybe half a second. With VLC the delay is more like 3 seconds. My guess is that this may be due to the Flash player using optimised GPU h264 decoding while VLC doesn't. Might this be correct? My objective is to find libraries that have minimal delay that can be used to build OS X and iOS apps (VLCKit unsurprisingly has the same delays as VLC on both OS X and iOS).

The server sends audio/video immediately, but the client has to buffer the data to play smoothly without pausing. The latency largely depends on the buffer size of the client. Strobe Media Playback aggressively optimizes its buffer size to reduce latency. I think GPU decoding doesn't affect latency greatly unless CPU usage is high.

However, if you are going to submit your iOS app that plays live stream over cellular network, generally you have to use HTTP Live Streaming (see Requirements for Apps for details).

from node-rtsp-rtmp-server.