search

iizukanao / node-rtsp-rtmp-server

RTSP/RTMP/HTTP hybrid server
MIT License
1.09k stars 282 forks source link

Single stream / Multiple connections - Last connection is terminated prematurely? #4

Closed gregoryking closed 9 years ago

gregoryking commented 10 years ago

Hi,

I've been using your excellent picam in combination with node-rtsp-rtmp-server. It seems to work pretty nicely, except I've noticed that when there are multiple connections, the last one left connected gets prematurely disconnected when the second remaining disconnects.

Eg Clients A, B and C all connect. C disconnects, then A and B remain connected (fine). B disconnects, A also gets disconnected (prematurely). Similarly - A and B connect, B disconnects, then A also gets disconnected (prematurely).

The count of clients connected appears to be correct in the STDOUT log output when monitoring the above scenarios. I'm using RTSP and connecting via a mixture of OS X and iOS vlc clients.

G

iizukanao commented 10 years ago

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.

gregoryking commented 10 years ago

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:

iizukanao commented 10 years ago

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).