[Live-devel] Broadcasting to UDP?

Sat Aug 29 21:37:18 PDT 2015

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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150829/894597c9/attachment.html>