We need to get video/audio across our multicast enabled network.
We moved our setup into the lab to resolve this this issue.
In the LAB environment, it looks like the source is sending too fast (using more than the required minimum bandwidth). The “source” interface is set to 10Mbps/full duplex to match the switch interface at 10Mbps/full duplex. If our server / application used to stream video/audio onto the multicast enabled network is streaming to fast (I.E uses too much bandwidth), it doesn’t seem QoS features will fix this issue; as we discovered policing the traffic -on the source ingress interface- to less bandwidth (less than 2Mbps) just drops a lot of video/audio packets. We don’t have ANY congestion anywhere on the net so QoS never comes into play – It’s a LAB. Dropping random packets (to meet the less than 2Mbps requirements - we really desire Kbit throughput) causes the end multicast enabled receivers to miss random packets and thus causes the video to be choppy etc. It seems in our case the “source” is really the issue. Meaning moving up to a better streaming method (denser video compression with better quality source video and etc) thus utilize less bandwidth is really the only solution other than upgrading all the low bandwidth/high latency links.
Looking for guidance!!!!
Btw, we are currently using VLC to stream (multicast) our video and VLC to receive the stream.
End-to-End Multicast works VERY well at 2.8Mbps throughput.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...