[Bug 739419] rtspsrc: not-linked after a while

[GStreamer (GNOME Bugzilla)]

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

--- Comment #68 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Nicola from comment #65)
> As principle I agree but looking at the logs seems not so simple, please
> take a look here, this is what happen when a new payload type arrive on the
> same SSRC, the right payload is 112 the good one is 96
> 
> [...]
> 
> so in rtspsrc getting pt map return NULL caps (unknown_stream) but this rtp
> packet is pushed anyway, do you agree that this packet should be dropped?
> rtspsrc seems to do the right thing, it says "hey I don't know this rtp
> packet" but the buffer should be dropped elsewhere, probably in rtpsource,
> do you agree?

Why is rtpptdemux not creating a new pad for it? The behaviour in
rtpbin/rtpsource/etc seems not wrong, the packet comes through with a new pt
and it just tries it best to handle that. It should've been demuxed into a
different stream though.
If there are caps or not seems secondary here.

(In reply to dashesy from comment #66)
> If buffer should drop the wrong pt, the jitterbuffer can easily drop it (the
> patch I sent). It is the only patch I apply and it drops the PT that is not
> in the caps, which fixes the problem for me.

As mentioned a few times above, the different pt should be split off before the
rtpjitterbuffer already. And then just be ignored at the rtspsrc level.

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