[Bug 764459] New: GstRTPBasedepayload fail to detect new stream after SSRC change

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=764459

            Bug ID: 764459
           Summary: GstRTPBasedepayload fail to detect new stream after
                    SSRC change
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fludkov.me at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 325148
  --> https://bugzilla.gnome.org/attachment.cgi?id=325148&action=edit
the fix + test

There is a rare case when we start receiving the stream with the new SSRC and
sequence numbers of the new stream don't differ much from the last received
sequence number of the previous stream. In this case GstRTPBasepayload fails to
detect that it is a new stream and can, theoretically, drop up to 99 packets.
The proposed patch adds additional logic to handle this.

I think the patch is not complete though and have a suggestion to discuss. We
have rtpjitterbuffer in the pipeline which handle the packet loss, reordering,
duplication, new SSRCs, etc. Why should we have the similar logic in
basedepayclass? It rather do harm than good. Correct me if I'm wrong, but if we
decide to use rtpjitterbuffer, it is the only element which should be
responsible for marking the packets with the DISCONT flag and pushing GAP
events etc. in case of packetloss.

After a quick chat on IRC I found out there are use-cases when there is no
rtpjitterbuffer in the pipeline. For this cases GstRTPBasepayload tries to be
responsible for marking the packets with DISCONT flag and dropping possible
duplicates. Ok, I got it.

So I the suggestion is to introduce the property to disable the logic, which
can be used when there is upstream rtpjitterbuffer.
Can somebody make an example with a real life scenario, when we don't use
rtpjitterbuffer and actually want GstRTPBasepayload to guess was there a
missing packet, or a duplicate, or it as a new stream? I feel like I don't have
a full picture in mind looking at the code.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.