> Thank you very much for your response. I was able to get this to work > with UDP multicast by changing the video sink to BasicUDPSink in the > transport stream test. VLC has no problem decoding the transport stream now. > This actually is what we are interested in anyway since our customers use > almost exclusively UDP multicast.
Sending Transport Stream data over raw-UDP is OK; however, by not using RTP/UDP, your receivers will not be able to properly handle out-of-order packets on the network. (Admittedly, this is unlikely to happen for a multicast stream over a single LAN, but it’s more likely to happen if you stream beyond a single LAN.) Also, streaming over raw-UDP is less likely to work should you ever decide to stream something other than Transport Stream data. > 1. I have not been able to find the place in the code where the delay between > packets is determined. This is done in the “MPEG2TransportStreamFramer” class - which parses the incoming Transport Stream data, to estimate (using PCR timestamps) the duration between successive chunks of Transport Stream data. Should you ever decide to stream from a live input (Transport Stream) source, rather than from a pre-recorded file, you could omit the “MPEG2TransportStreamFramer” object. > 2. Just curious why vlc could not tell if it is a transport stream since the > rtp header "payload type" should indicate this. What am I mssing? I don’t know - but you’d need to ask a VLC mailing list about that. VLC is not our software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
