<div dir="ltr"><div dir="ltr"><div>In case it helps anyone: Solved this by adding a pad probe to the payloader src pad which uses gst_buffer_get_reference_timestamp_meta and gst_rtp_buffer_add_extension_onebyte_header to send the server-side timestamp in the RFC 5285 header extension.</div><div><br></div><div>Regards,</div><div>Pablo</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 15, 2021 at 12:38 PM Pablo Odorico <<a href="mailto:pablo.odorico@gmail.com" target="_blank">pablo.odorico@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have a client+server stream based on rtpbin. The video stream comes from an appsrc which sets the buffers PTS. If I probe on different places on the client pipeline (e.g. the decoder src pad) I see that the buffers PTSs are in a different clock domain.<br><br>Is there any way to recover the server-side timestamps from the client pipeline? This would be useful for instrumentation and to support encoder features like invalidating dropped reference frames.</div><div><br></div><div>Ideally I would like to get it from the timestamp in GstRTPPacketLost, so I don't have to probe downstream and wait for the next GstBuffer flagged as DISCONT.</div><div><br></div><div>Thank you,</div><div>Pablo</div></div>
</blockquote></div>
</div>