[vlc-devel] how to make UDP packets as the VLC input stream

[Warren Young]

On 11/15/2012 00:17, leon wrote:
>
> I am wondering how to make UDP packets as the VLC input stream?

VLC can do this, via Media > Stream.  Select the video source, then for 
the destination address select a multicast address.  That is, most 
anything in the 224.0.0.0 - 239.255.255.255 range.  There are rules for 
various addresses in this range, so Google "multicast" for some hints.

You can do unicast instead, but really, multicast is best when you're 
talking about UDP streaming.  Give unicast a miss unless you know for a 
fact you have to do it that way.  (e.g. WAN streaming where the WAN is 
controlled by hostile firewall admins.)

Then within another VLC instance, you can say Media > Open Network 
Stream and put in something like udp://@239.123.45.6:1234 and receive 
the stream.

The reason the UDP option is probably marked as "legacy" here is that 
many people strongly prefer using RTP for multicast instead, because it 
is better suited to A/V over the network.  They're right for the most 
part, though there are exceptions where raw UDP still makes sense. 
Unless you know for a fact you have one of those exceptional cases, you 
should probably be using RTP.  The procedure is the same.  VLC handles 
the differences entirely under the covers.

There are other ways to produce the stream.  VLC's command line 
interface has enough power to do it:

	http://www.videolan.org/doc/streaming-howto/en/ch03.html

So does VLC's VLM mode:

	http://www.videolan.org/doc/streaming-howto/en/ch05.html

You can do it with third-party sources, too, like Live555:

	http://live555.com/

> Or how can I use VLC transcode lib/api inside python after I got video
> stream via socket.recv?

If you have an outside network video source and are just trying to 
redirect it to a local VLC instance via a third machine, you might want 
to look into the Live555 proxy server:

	http://www.live555.com/proxyServer/

It's not Python, but then, for video work, you shouldn't be doing 
anything more complex than offline scripting tasks with Python and video.

I'm no scripting language hater.  It's just that video has a way of 
using up the full capacity of available machines.  Now that average 
desktops can handle 1080p without special help (e.g. expensive GPUs), 
we're starting to hear about 4K video on the desktop.  Next it will be 
120 Hz 3D 4K on the desktop.  Then I dunno...real-time holography? :)