<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hello, thanks for the report. Nicolas is correct, there are some values that are<div>being computed manually, that should use the segment instead. Precisely because</div><div>of these scenarios.</div><div><br></div><div>Let us take a look.<div dir="ltr"><br><blockquote type="cite">On 1 Jun 2021, at 09:05, Nicolas Dufresne via gstreamer-devel <gstreamer-devel@lists.freedesktop.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<div>Le mardi 01 juin 2021 à 09:28 +0000, Winand Appelhoff a écrit :</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Hi Nicolas,</div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">could you elaborate on this a little bit more?</div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I thought GstSegment was only relevant when processing seek events , at least that's how I interpreted the documentation</div></blockquote><div><br></div><div>GstSegment contains the required information to interpret the following buffers timestamp. I guess the doc could be improve, interpreting GstBuffer timestamp is not that common, so it wasn't included there.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br><p style="box-sizing:border-box;margin:0px 0px 10px;color:rgb(34, 34, 34);font-family:"Source Sans Pro", "Source Sans", sans-serif;font-size:14px;text-align:left;background-color:rgb(238, 238, 238)">This helper structure holds the relevant values for tracking the region of interest in a media file, called a segment.</p><p style="box-sizing:border-box;margin:0px 0px 10px;color:rgb(34, 34, 34);font-family:"Source Sans Pro", "Source Sans", sans-serif;font-size:14px;text-align:left;background-color:rgb(238, 238, 238)">The structure can be used for two purposes:</p><ul style="box-sizing:border-box;margin-top:0px;margin-bottom:10px;color:rgb(34, 34, 34);font-family:"Source Sans Pro", "Source Sans", sans-serif;font-size:14px;text-align:left;background-color:rgb(238, 238, 238)"><li style="box-sizing:border-box">performing seeks (handling seek events)</li><li style="box-sizing:border-box">tracking playback regions (handling newsegment events)</li></ul><br></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">so, basically I should be using gst_segment_to_stream_time(<GstSegment>, <timestamp of GstBuffer>) to get the "true" stream timestamp instead?</div></blockquote><div><br></div><div>Correct, note I made a typo, most applicaiton will likely want to deal with running-time. The stream-time is like the position within a stream (e.g. if you are playing a file with a container like ISOMP4, it would translate the timestamp into the position inside the current file). The running-time is the time you pipeline have been playing. So starting from 0 as you asked for.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">(sorry for hijacking this thread)</div><div><hr tabindex="-1" style="display:inline-block; width:98%"></div><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Nicolas Dufresne <nicolas@ndufresne.ca><br><b>Gesendet:</b> Montag, 31. Mai 2021 15:55<br><b>An:</b> Discussion of the development of and with GStreamer <gstreamer-devel@lists.freedesktop.org><br><b>Cc:</b> Winand Appelhoff <w.appelhoff@tv1.eu>; Marianna S. Buschle <msb@qtec.com><br><b>Betreff:</b> Re: AW: 1000 hours offset in timestamp of h264 stream</font><div> </div></div><div dir="ltr"><div>Le lundi 31 mai 2021 à 10:27 +0000, Winand Appelhoff via gstreamer-devel a écrit :</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Hi!</div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">You are right</div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">Noticed an timestamp offset using x264enc connected through an appsink/appsrc pair quite a while a ago</div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">The only way I found to "fix" it was by subtracting 3600.000.000.000.000ns from the timestamp prior to pushing it into an appsrc</div></blockquote><div><br></div><div>Same here, you application is likely ignoring the segment event, giving a meaning to timestamp is only possible while using the date in the segment event.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">the only documentation I found was following statement in the 1.18 release notes:<br><br><i><code>avvidenc</code>: shift output buffer timestamps and output segment by 1h just like x264enc does, to allow for negative DTS.</i><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"><br></div><div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"><br></div><div><hr tabindex="-1" style="display:inline-block; width:98%"></div><div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> gstreamer-devel <gstreamer-devel-bounces@lists.freedesktop.org> im Auftrag von Marianna S. Buschle via gstreamer-devel <gstreamer-devel@lists.freedesktop.org><br><b>Gesendet:</b> Montag, 31. Mai 2021 09:01<br><b>An:</b> gstreamer-devel@lists.freedesktop.org <gstreamer-devel@lists.freedesktop.org><br><b>Cc:</b> Marianna S. Buschle <msb@qtec.com><br><b>Betreff:</b> 1000 hours offset in timestamp of h264 stream</font><div> </div></div><div class="x_BodyFragment"><font size="2"><span style="font-size:11pt"><div class="x_PlainText">I have the following pipeline (using interpipesrc/sink from RidgeRun):<br><br>gst-launch-1.0 videotestsrc is-live=true pattern=ball !<br>video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! tee name=t ! queue !<br>videoconvert ! ximagesink sync=0 t. ! queue ! x264enc key-int-max=30<br>speed-preset=1 tune=zerolatency ! video/x-h264,profile=high ! h264parse !<br>queue ! interpipesink name=vtest1 sync=true async=false interpipesrc<br>listen-to=vtest1 name=vselect is-live=true stream-sync=passthrough-ts !<br>queue ! fakesink dump=1 sync=1 --gst-debug=*:3,*interpipe*:5<br><br>When sync=1 in the fakesink it doesn't dump any data, if I change to sync=0<br>it does.<br><br>If I remove the encoder (use RAW data) it dumps data for both cases.<br>The same is true if I remove the interpipesrc/sink and just plug the<br>fakesink directly into the encoder.<br><br>Also if I use recorded h264 data from a multifilesrc, instead of having an<br>encoder, it dumps data for both cases.<br><br>gst-launch-1.0 multifilesrc loop=1 name=replay location=/home/msb/test.ts !<br>identity sync=true ! tsdemux : identity sync=true ! h264parse ! queue !<br>interpipesink name=vreplay sync=false async=false interpipesrc<br>listen-to=vreplay is-live=true stream-sync=passthrough-ts ! fakesink dump=1<br>sync=1 --gst-debug=*:3,*interpipe*:5<br><br>The debug information from the interpipe elements reports timestamps with<br>1000 hours offset which I think it is the cause of the problem:<br><br>0:00:01.714147464 1339403 0x55b0aa657520 INFO interpipesink<br>gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vtest1> Incoming<br>serialized event tag<br>0:00:01.714232382 1339403 0x55b0aa657520 INFO interpipesink<br>gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vtest1> Event<br>timestamp 1000:00:01.633333333<br>0:00:01.714275617 1339403 0x55b0aa657520 DEBUG interpipesrc<br>gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<vselect> Event tag with<br>calculated timestamp 1000:00:01.633333333 enqueued on serial pending events<br>0:00:02.030453992 1339403 0x55b0aa657700 INFO interpipesink<br>gstinterpipesink.c:389:gst_inter_pipe_sink_intersect_listener_caps:<vtest1><br>Listener vselect caps: ANY<br>0:00:02.030554449 1339403 0x55b0aa657700 INFO interpipesink<br>gstinterpipesink.c:443:gst_inter_pipe_sink_get_caps:<vtest1> Caps<br>negotiated: video/x-h264, profile=(string)high, framerate=(fraction)[ 0/1,<br>2147483647/1 ], width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ],<br>parsed=(boolean)true, stream-format=(string){ avc, avc3, byte-stream },<br>alignment=(string){ au, nal }<br>0:00:02.047439856 1339403 0x55b0aa657520 INFO interpipesink<br>gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vtest1> Incoming<br>serialized event tag<br>0:00:02.047497306 1339403 0x55b0aa657520 INFO interpipesink<br>gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vtest1> Event<br>timestamp 1000:00:01.966666666<br>0:00:02.047530207 1339403 0x55b0aa657520 DEBUG interpipesrc<br>gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<vselect> Event tag with<br>calculated timestamp 1000:00:01.966666666 enqueued on serial pending events<br><br>If I use RAW data the offset is not present, and if I use h264 encoded data<br>coming from the multifilesrc the offset is not present either:<br><br>0:00:01.911863974 1339557 0x559c28433d20 DEBUG interpipesrc<br>gstinterpipesrc.c:481:gst_inter_pipe_src_create:<interpipesrc0> Got event<br>with timestamp 0:00:01.258333333<br>0:00:01.911912193 1339557 0x559c28433d20 DEBUG interpipesrc<br>gstinterpipesrc.c:489:gst_inter_pipe_src_create:<interpipesrc0> Sending<br>Serial Event tag<br>0:00:02.111425433 1339557 0x559c28433d80 INFO interpipesink<br>gstinterpipesink.c:542:gst_inter_pipe_sink_forward_event:<vreplay> Incoming<br>serialized event tag<br>0:00:02.111489516 1339557 0x559c28433d80 INFO interpipesink<br>gstinterpipesink.c:547:gst_inter_pipe_sink_forward_event:<vreplay> Event<br>timestamp 0:00:01.458333333<br>0:00:02.111523291 1339557 0x559c28433d80 DEBUG interpipesrc<br>gstinterpipesrc.c:729:gst_inter_pipe_src_push_event:<interpipesrc0> Event<br>tag with calculated timestamp 0:00:01.458333333 enqueued on serial pending<br>events<br><br>I think that the problem is that the interpipe elements are not handling<br>properly the timestamp offset caused by the encoder.<br>My question is, how can they (or maybe I) fix it? How to handle this offset<br>properly?<br>Some existing elements must be doing it, where can I look?<br><br><br><br>--<br>Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/">http://gstreamer-devel.966125.n4.nabble.com/</a><br>_______________________________________________<br>gstreamer-devel mailing list<br>gstreamer-devel@lists.freedesktop.org<br><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br></div></span></font></div><pre>_______________________________________________</pre><pre>gstreamer-devel mailing list</pre><pre><a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a></pre><pre><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></pre></blockquote><div><br></div><div><span></span></div></div></blockquote><div><br></div><div><span></span></div>
<span>_______________________________________________</span><br><span>gstreamer-devel mailing list</span><br><span>gstreamer-devel@lists.freedesktop.org</span><br><span>https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</span><br></div></blockquote></div></body></html>