Ronald S. Bultje <rsbul...@gmail.com> added the comment: I think the relevant section is 8.2:
"Although the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one. (As explained below, this step is taken only once in case of a loop.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last." I think it is proper to somehow put the source IP (as per recvfrom()) in the private data, and add some internal API so we can look this up in rtsp.c/rtpdec.c. This should then handle the ssrc collision here. Once that's fixed, there no longer is an issue - the two streams have different ssrcs and are thus distinguishable. No callback or application code is required. _____________________________________________________ FFmpeg issue tracker <iss...@roundup.ffmpeg.org> <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688> _____________________________________________________
