Skip to content

rtpmp2tdepay: should advertise clock-rate=90000 by default to avoid bogus negotiation to clock-rate=1 if rate is missing in udpsrc caps

gst-launch-1.0 udpsrc caps=application/x-rtp,media=video ! rtpjitterbuffer ! rtpmp2tdepay ! fakesink -v

makes udpsrc negotiate the following caps by default:

application/x-rtp, media=(string)video, clock-rate=(int)1, encoding-name=(string)MP2T

which leads to two problems:

  1. rtpjitterbuffer doesn't warn any more that the clock-rate is absent from the input caps
  2. constant rtpjitterbuffer.c:572:calculate_skew: delta - skew: 0:49:59.966666351 too big, reset skew because timestamp interpretation is bogus now.

I think rtpmp2tdepay should advertise the normal 90000 clock-rate in its caps by default (as per the spec). I will prepare an MR for that.

Secondly, the fact that udpsrc does intersection/fixation here with the downstream caps seems a bit dubious. I can see how it makes things work with depayloaders where there's a standard rate, but in this case it's really quite wrong. I wonder if we should filter out int ranges for the clock-rate field "somewhere" (probably in the depayloader base class or rtpjitterbuffer)?