Handling a stream that changes SSRC

[kevmo314]

I have a uniview camera that changes the SSRC for each gop and as a result we have the same behavior as reported in #480 -- we receive one gop of frames and then playback pauses due to the error here:

gortsplib/internal/rtcpreceiver/rtcpreceiver.go

Line 173 in 07039eb

return fmt.Errorf("received packet with wrong SSRC %d, expected %d", pkt.SSRC, rr.remoteSSRC)

Both FFmpeg and VLC are able to handle this correctly so I did some digging into why gortsplib fails. Because this error can't be handled by the implementer and the packet can't be reprocessed, we don't have an easy way of patching over this. Additionally, a closer reading of the spec suggests that a changing SSRC is not technically invalid, a single source is not explicitly forbidden to have multiple SSRCs as long as they're unique within the session, which is what I think FFmpeg and VLC implement:

   Synchronization source (SSRC): The source of a stream of RTP
      packets, identified by a 32-bit numeric SSRC identifier carried in
      the RTP header so as not to be dependent upon the network address.
      All packets from a synchronization source form part of the same
      timing and sequence number space, so a receiver groups packets by
      synchronization source for playback.  Examples of synchronization
      sources include the sender of a stream of packets derived from a
      signal source such as a microphone or a camera, or an RTP mixer
      (see below).  A synchronization source may change its data format,
      e.g., audio encoding, over time.  The SSRC identifier is a
      randomly chosen value meant to be globally unique within a
      particular RTP session (see Section 8).  A participant need not
      use the same SSRC identifier for all the RTP sessions in a
      multimedia session; the binding of the SSRC identifiers is
      provided through RTCP (see Section 6.5.1).  If a participant
      generates multiple streams in one RTP session, for example from
      separate video cameras, each MUST be identified as a different
      SSRC.

That being said, I do think that it's quite odd behavior. So I wanted to pose this issue to ask if you had any thoughts on how to address this? Some ideas:

• Disable the error all together. This one feels weird to me but would work.
• Add a "packet preprocessing" hook where we can modify a packet before the remainder of the RTSP pipeline receives it, which would allow us to override the SSRC for this camera and normalize it.
• Add a setting that drills into RTCPReceiver to ignore wrong ssrc.

I'm happy to implement and contribute a solution but would like some thoughts on the best approach given the future of the library too.

[aler9]

Hello, SSRC is used to distinguish between different formats streamed inside the same media stream. Said that, we can add an exception to disable SSRC checks when there is only a single format inside a given media stream.

Just provide the manufacturer and model of the camera, and also a SDP sample.