The VideoLAN Forums

I have an application that runs the following command line on Windows 7

vlc "http://localhost:8251/Cam5/Lgn?UID=vayt ... PWD=admin1" --sout "#transcode{vcodec=h264, scale=1 , acodec=none}:udp{dst=239.200.0.1:3005} sout-all"

There's a service that can output MJPEG that I want to distribute across our single subnet LAN.

After running the above I attempt to get the stream on another computer on the LAN using udp://@239.200.0.1:3005 I have waited as long as 30 minutes to see if it will show. No luck.
Next I start a VLC instance on the server as in udp://@239.200.0.1:3005. Within about 20 seconds I get a stream and the remote system (idle now for 30 minutes or more) also starts streaming.

For my own sanity I would like to know why. Barring that I would like to be able to get the other systems to receive the stream without having to start a receiver on the server.

Any ideas - I have looked at the logs and VLC kicks out some errors reading the MJPEG stream, quit a few actually but I can stream directly into VLC with the HTTP URI and it works fine.

Should I move this post to VLC stream-output (sout)?

A reboot of the computer seemed to eliminate the problem for now. I will continue to monitor this. I can ingest several http mjpeg streams and transcode them to H264 and stream them to UDP multicast which is good and useful.

First off this was a network routing problem due to fact that the server is multihomed. Secondly I also implemented the same software on a Windows 2012 R2 server and did not have any problems. But in the case of the windows 7 box here's what I did. I messed around with the route table on the server quite a bit before stumbling across the following steps to resolve the issue.

the route table for UDP IP addresses looks like this: The 192.168.6.110 address has an interface but no gateway the 192.168.2.75 interface does have a gateway and this is the interface I wanted to shoot the UDP packets out but for some reason it did not happen. The last number in each row is called the Metric where lower numbers mean a higher priority in choosing which interface to use. As you can see the two networks are tied at 266. To force the issue I added a route using the route command as follows:
Then my list of UDP routes looked like this:
See metric on the new line it is much lower than the other two so it gets chosen.

On more thing that's important. I rebooted the system and then it started work to work every time. I was configuring the system using remote desktop so it might have been possible to just disable and enable the nic but I was connected remotely over the 2.75 interface so I rebooted.