Thank you so much for your prompt answer Ross, I exposed my problems with VLC to explain why I am looking for an alternative; I was not looking here for help with VLC... sorry if I didn't explain myself clearly.
The main reason I originally chose to use UDP broadcast instead of multicast was that I have a network recorder that can be setup to record all the activity in an specific UDP port, and then replay it at will. I was not sure that it could record multicast transmissions so I decided to go the safe way (as always delivery time was too short) and after I had something working and the client happy, I would have time to test better technologies and optimizations. Yes, the cameras use H.264. I started dealing with digital cameras and digital video barely two months ago so please excuse my utter lack of knowledge in video technologies. Some questions that may seem obvious but I don't know the answers: - My idea is to reduce as much as possible the bandwidth usage in the network, so probably the ideal scenario would be to program the camera to multicast its stream and have the clients connect directly to that one... am I right? - If the camera or video server is not programmable for multicasting, is it at all possible to open a single connection to the camera from one client and then direct my clients to "tap" on the RTP video stream to that single client without creating a duplicate UDP video stream for each? - I had modified the proxyServer application to rebroadcast the camera streams but that was not very useful since still each client had to open an RTSP connection to the specific IP address of my server, so I guess that also created duplicated streams in the network. I will follow your advise to try and multicast with the "testH264VideoStreamer" app and see how it goes. I think I can use the "input" part of proxyServer and combine it with textH264VideoStreamer to be able to re-stream a live stream via multicast, am I right? Thanks again, Marco. *Ing. Marco A. Pérez López* Software Development Xanatos Marine Ltd. #370 18 Gostick Place North Vancouver, B.C., V7M 3G3 Phone: +1 604 904 2200 www.xanatosmarine.com <http://www.xanatosmarine.com/> This electronic transmission (including any and all attachments) is intended solely for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential. If you are not the intended recipient of this electronic transmission, you are hereby notified that any disclosure, copying, or distribution, or the taking of any action in reliance upon the contents of this electronic transmission, is strictly prohibited, and you are further requested to purge this electronic transmission and all copies thereof from your computer system. On 2015-08-28 7:21 PM, Ross Finlayson wrote: >> I am building an application where several clients should be able to >> watch a video stream from a CCTV IP camera. >> I think that the best solution bandwidth-wise is to have a single >> computer in the network connect to the rtsp stream from the camera, >> and then broadcast this stream via UDP (to some address like >> 255.255.255.255) so all other computers in the network only need to >> "tap" that UDP port to get the video stream. > > First, you shouldn’t be sending to the ‘broadcast’ address > 255.255.255.255, because that will cause the packets to get received > (and then discarded, if inappropriate) by all computers on your LAN. > Instead, you should be using an IP multicast address - which will > cause the packets to get delivered only to the computer(s) that have > subscribed to that address, and also (with appropriate routing) allows > for the possibility of the packets being forwarded beyond a single LAN. > > And, of course, you should be using the standard RTP protocol (over > UDP), rather than raw UDP. > > We have several demo applications - in the “testProgs” directory - > that will stream (from a video file) via IP multicast. You didn’t say > what video codec you are using, but if you’re using H.264 (the most > commonly-used video codec these days), then you can use our > “testH264VideoStreamer” application. > > Then, once you have demonstrated multicast streaming from a file > (using an appropriate “test*Streamer” demo application), then see here > http://live555.com/liveMedia/faq.html#liveInput > for tips on how to adapt this to stream from a live video source. > > >> I implemented this with VLC and it works, but... as the network gets >> more load from several devices, the VLC instances start falling >> behind the real time stream from the camera. With one Full HD camera >> and four standard cameras in the network, VLC (the "source" or >> re-streaming instance mainly) falls behind at an astonishing rate and >> after some 10 minutes the output stream is like 5 minutes behind real >> time! > > We can’t help you with VLC problems (because VLC is not our problem), > but I wonder if perhaps you’re running into network capacity problems. > Note that if any of your cameras are streaming over WiFi, then > broadcast (or multicast) over WiFi is notoriously slow. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
