<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Sebastian!<br><br></div>Thank you for the answer.<br><br>> If you set buffer-mode=none on rtpbin, you will get the RTP timestamps (extended) as PTS on the buffers.<br></div><div>Would it work with buffer timestamp in older gstreamer versions? There is no concept of PTS/DTS in 0.10 series.<br><br>> There's also this extension that is not merged yet which would allow you to get things more directly:<br></div><div>This will be really useful in my situation. At some day we will have transition from RHEL 6 (gstreamer 0.10.x) to<br></div><div>RHEL 7 with hope to get most recent version of gstreamer and drop all our slightly customized 0.10 plug-in packages.<br></div><div></div><div><br>> The best way to do it depends on the bigger picture of what you want to do</div><div></div>I want to record RTP streams with correct timing information to the sequence of files (20 min long). So I have receiving pipeline:<br><br>udpsrc -> gstrtpbin -> rtpmp4vdepay -> mpeg4videoparse -> appsink<br><br></div><div>and recording pipeline:<br></div><div><br></div>appsrc -> mp4mux -> filesink<br><br></div>I need to break full pipeline into two separate pipelines because there is no obvious way to split the stream into file sequence. In this article: <br> <a href="https://groakat.wordpress.com/2012/12/05/gstreamer-stream-h264-webcam-data-to-series-of-files/">https://groakat.wordpress.com/2012/12/05/gstreamer-stream-h264-webcam-data-to-series-of-files/</a><br>one is fighting dynamic pipeline manipulation and I decided that it is too complex and unreliable.<br><br>I'm aware of splitmuxsink element, but I'm using version 0.10.x (and cant do anything with that).<br><br></div><div>At the recording site I need to get file sequences with special names (these are ~2 min intervals for testing purposes):<br><br></div><div>2017.05.08-12.00.56.143.mp4<br>2017.05.08-12.02.59.893.mp4<br>2017.05.08-12.05.03.643.mp4<br>2017.05.08-12.07.07.393.mp4<br>2017.05.08-12.09.11.143.mp4<br>2017.05.08-12.11.14.893.mp4<br>2017.05.08-12.13.18.643.mp4<br></div><div><br></div><div>So the name of each file is the NTP timestamp of its first frame. And this timestamp should follow sender's timeline (not the local wallclock).<br>I need this for later playback (synchronous with other air traffic information).<br><br></div><div>When the buffer comes out of appsink (for the first time) I check if it is keyframe (and check if I have received SR) and start new recording pipeline.<br></div><div>Now I've ended with three solutions:<br><br></div><div>1. Capture local time of sender report arrival (LOCAL_SR) and then calculate file start time as:<br></div><div>    FILE_START = NTP_SR + (LOCAL_KEY - LOCAL_SR)<br></div><div>    where NTP_SR - NTP timestamp from sender report, LOCAL_KEY - local time of keyframe arrival.<br></div><div>    Here I get some random error (~150 ms) in file start, because I don't know real RTP timestamp.<br></div><div>    Another error source - RTP/NTP pair in SR is somewhere in the future regarding to surrounding RTP stream timestamps (at least, when the source is another gstreamer pipeline).<br></div><div></div><div><br></div><div>2. Dirty hack with depay element. I've noticed that offset_end field of the appsink buffer is always invalid.<br></div><div>    So I've modified rtpmp4vdepay element and added these lines to gst_rtp_mp4v_depay_process:<br><br>        rtp_ts = gst_rtp_buffer_get_timestamp(buf);<br>        GST_BUFFER_OFFSET_END(outbuf) = rtp_ts;<br><br></div></div></div></div>    Now I have RTP timestamp in GST_BUFFER_OFFSET_END and file names become perfectly spaced.<br></div>    You can see this in file names example above - incoming stream is 4 FPS and file names' milliseconds cycle exactly every fourth file.<br></div><div>    I was unable to find another way to add custom data to GstBuffer in 0.10 series.<br><br></div><div>3. Get timestamps with custom appsrc (or tee) element, not from UDP sink. This is not implemented yet.<br><br></div><div>For now, the best solution is a dirty hack with another fix in our RPMs. Another thing that embarrasses me is that someday GST_BUFFER_OFFSET_END modification could break something further in pipeline.<br></div><div><br></div><div>Best Regards,<br></div><div>Yurii<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-08 16:30 GMT+03:00 Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 2017-05-06 at 15:08 +0300, Yurii Monakov wrote:<br>
> Hi All!<br>
><br>
> Any thoughts on this?<br>
><br>
> I'm developing video recording application for air traffic control<br>
> system. And RTP <-> NTP timestams matching is essential for later<br>
> playback of multiple streams (audio, video, digital records).<br>
> So I need to get perfect time of the first key frame in each video<br>
> sequence (~20 min long).<br>
><br>
> Maybe I can alter the source code or subclass some gstreamer<br>
> elements?<br>
<br>
</span>If you set buffer-mode=none on rtpbin, you will get the RTP timestamps<br>
(extended) as PTS on the buffers.<br>
<br>
There's also this extension that is not merged yet which would allow<br>
you to get things more directly:<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=762628" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/<wbr>show_bug.cgi?id=762628</a><br>
<br>
<br>
And independent of that, rtpbin already has all functionality needed<br>
for synchronizing RTP packets based on their RTP timestamps, the<br>
NTP/RTP timestamp mapping and a NTP clock in various ways. If that is<br>
something you're looking for.<br>
Generally, all you want to do is already possible in various ways. The<br>
best way to do it depends on the bigger picture of what you want to do.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a></font></span><br>______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
<br></blockquote></div><br></div>