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
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:
rtpjitterbufferdoesn't warn any more that the clock-rate is absent from the input caps
rtpjitterbuffer.c:572:calculate_skew: delta - skew: 0:49:59.966666351 too big, reset skewbecause timestamp interpretation is bogus now.
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