Open llamafilm opened 2 years ago
One unusual feature of this particular stream is that the source device sends multiple streams, each on a different UDP port, all using the same multicast destination address.
I don't think that is a problem. That should be handeld correctly.
One thing I noticed looking at the Wireshark screenshot is, that the sequence number of the RTP packets are all the same for the 5 packets visible. They should normally be increasing. If every packet has the same sequence number (which would be a bug in the RTP implementation of the sender), I would guess that the buffering algorithm messes up, as it is based on the squence number. Try disabling RTP buffering in the settings and see if that works.
I think that’s because those 5 packets are actually from 5 different streams. Only one of them is going to port 6518. I should have made the destination port column visible to show that. I’ll try disabling buffering.
Thanks for the tip, but disabling RTP buffering did not make any difference. Here in this new screenshot you can see the sequence numbers are incrementing by 1 each time (port 6518 in this case)
Some streams don't play any audio. I've added a stream from the following SDP. This particular stream works fine as a source in this tool: aes67-linux-daemon. I'm not sure what else I can tell you for troubleshooting, is there a log file? There is no indication of any error within the app. As soon as I click Listen the machine begins receiving RTP packets but I don't hear anything. Other sources of a similar format (L24/48000/8) work fine. Here's a Wireshark screenshot showing the packets being received. One unusual feature of this particular stream is that the source device sends multiple streams, each on a different UDP port, all using the same multicast destination address. Is that a problem here?