UDP Multicast won't stream remotely until I start locally

[mooncaptain]

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.

[mooncaptain]

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

[mooncaptain]

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.

[mooncaptain]

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:

Code: Select all

224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.6.110 266 224.0.0.0 240.0.0.0 On-link 192.168.2.75 266

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:

Code: Select all

route -p add 224.0.0.0 mask 240.0.0.0 192.168.2.75

Then my list of UDP routes looked like this:

Code: Select all

224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.6.110 266 224.0.0.0 240.0.0.0 On-link 192.168.2.75 266 224.0.0.0 240.0.0.0 192.168.2.1 192.168.2.75 11

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.