Debugging `rtspsrc` and missing `GstReferenceTimestampMeta`

Hi, I have an IP camera I’m connecting to with

rtspsrc add-reference-timestamp-meta=true location=... ! rtph264depay !  [ rest of pipeline ]

It’s a new brand/model I’ve not used before, and I’m not getting GstReferenceTimestampMeta object on the downstream buffers.

In wireshark I can see that the camera is sending RTCP Sender Reports with NTP time.

Here’s what I’ve got from debugging so far:

GST_INFO_OBJECT (jitterbuffer, "TIME %" GST_TIME_FORMAT, GST_TIME_ARGS (ntp_time));

or

GST_INFO_OBJECT (jitterbuffer, "TIME %" GST_TIME_FORMAT, GST_TIME_ARGS (inband_ntp_time));

at any point outputs 99:99:99.999999999.

More logging shows that _get_inband_ntp_time is doing an early return of GST_CLOCK_TIME_NONE since priv->ntp64_ext_id == 0 is true.

After that I’m a bit lost trying to work out what ntp64_ext_id is and how it should be set.

Any pointers from here? Am I looking in the right place at all?

Just to add, I can find these messages in the log, e.g.:

rtpsource rtpsource.c:1489:rtp_source_process_sr:<RTPSource@0x7c6cbc0de990> got SR packet: SSRC 75d202e4, NTP eb4d0a83:f0a3d70a, RTP 3455230858, PC 10053, OC 14292516

Update for anyone else reading, I’ve narrowed it down to what I think is a bug in the camera and not with Gstreamer, so submitting a bug report to the camera maker.

It seems the SSRC on the RTCP Sender Report does not match the SSRC on the the RTP packets. I end up with the two rtpjitterbuffer s in the bin, with with the RTCP Sender Reports going to rtpjitterbuffer0 and the video content going to rtpjitterbuffer1.

Thank you for sharing your debug steps. Very interesting read