<div dir="ltr"><div>Thanks Tim. You're right: we are taking the documentation literally because we're new to GSteamer and need to write our own elements. Without a tutorial, there's nothing else to on.</div><div>
</div><div> </div><div>A few more questions:</div><div> </div><div>Is the decoding timestamp the time the buffer actually was decoded (after the decoding has finished) or the time it should be decoded (as in "this needs to be decoded at <some point in the future>)</div>
<div> </div><div> </div><div>Same question as above about presentation timestamp. </div><div> </div><div> </div><div> </div><div>On latency the documentation says:<b><font size="5" face="NimbusSanL-Bold"><font size="5" face="NimbusSanL-Bold"><p align="LEFT">
"14.6.1. Latency compensation</p>
</font></font></b><font size="5" face="NimbusSanL-Bold"><font size="5" face="NimbusSanL-Bold"></font></font><font face="NimbusRomNo9L-Regu"><font face="NimbusRomNo9L-Regu"><p align="LEFT">Before the pipeline goes to the PLAYING state, it will, in addition to selecting a clock and calculating a</p>
<p align="LEFT">base-time, calculate the latency in the pipeline. It does this by doing a LATENCY query on all the sinks</p>
<p align="LEFT">in the pipeline. The pipeline then selects the maximum latency in the pipeline and configures this with a</p>
<p align="LEFT">LATENCY event.</p>
<p align="LEFT">All sink elements will delay playback by the value in the LATENCY event. Since all sinks delay with the</p>
<p>same amount of time, they will be relative in sync."</p><p> </p><p>When does each element calculate its latency and when does the pipeline issue the latency query? Doign it in the playing state seems too late. Does it happen in the preroll state? Some buffers have to be processed by every element to determine where the longest latency is.</p>
</font></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 5, 2013 at 2:42 AM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2013-10-04 at 12:41 -0700, Bob Barker wrote:<br>
<br>
Hi,<br>
<div class="im"><br>
> We’re new to GStreamer and are writing our own elements. We’re trying<br>
> to understand which clocks are used for jitter calculation. From the<br>
> GStreamer documentation:<br>
><br>
> <a href="http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-qos.txt" target="_blank">http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-qos.txt</a><br>
><br>
> “A buffer with timestamp B1 arrives in the sink at time T1. The buffer<br>
> timestamp is then synchronized against the clock which yields a jitter<br>
</div>> J1 return value from the clock. (snip)"<br>
<div class="im">><br>
><br>
> We assume the clock is the monotonically increasing wall clock, not<br>
> the running time nor the stream time shown ins section 14.4 of the<br>
> GStreamer application development manual. From the documentation the<br>
> running time always starts at zero so the running time and stream time<br>
> are always less than the clock time.<br>
><br>
> In the GStreamer clocks diagram (and the real-world) the clock time is<br>
> always greater than stream time and the running time. Given that and<br>
> the equation above ( J1 = CT – B1) , jitter will always be positive.<br>
> According to GStreamer documentation “If the jitter is positive<br>
> however, the entry arrived too late in the sink and should therefore<br>
> be dropped. “<br>
><br>
> Questions:<br>
><br>
> 1. So all buffers will always be late and should be dropped?!<br>
> What are we missing?<br>
<br>
</div>It sounds like maybe you're taking these docs a little too literal. The<br>
clock time is not necessarily the actual value gst_clock_get_time()<br>
returns, and the buffer time stamp will likely be adjusted for things<br>
like the configured latency, and converted into running time for<br>
synchronization purposes.<br>
<br>
Things also depend a bit on the exact pipeline, and what elements are<br>
involved. If you have filesrc ! parse ! dec ! audiosink and the pipeline<br>
selects the audio clock from the sink, then that clock will be based on<br>
audio samples rendered (and some of your assumptions about the real<br>
world are not necessarily true any more).<br>
<div class="im"><br>
<br>
> 2. Which timestamp is the documentation referring to?<br>
> GStreamer calls out one in the Linux version of gstbuffer.h:“<br>
> GstClockTime timestamp;” and two in the windows version:<br>
> pts and gts.<br>
<br>
</div>It depends on the circumstances. Usually you will sync on pts, but there<br>
may be cases where one would sync on dts if it is available, e.g. for<br>
encoded content.<br>
<br>
There is no difference between "the Linux version" and "the Windows<br>
version". What you're seeing is the old 0.10 version vs. the new 1.0<br>
version, which have different APIs.<br>
<div class="im"><br>
<br>
> 3. Which of the three clocks (clocktime, running time, stream<br>
> time) are the pts and dts referring to?<br>
<br>
</div>Those are not "three clocks", there is only one clock. pts/dts are<br>
"stream time", their actual values need to be used in connection with<br>
the SEGMENT to transform those into running time for synchronization<br>
purposes.<br>
<div class="im"><br>
<br>
> 4. It seems the correct jitter formula is:<br>
> Jitter = buffer_arrival_time - base_time – buffer_time_stamp<br>
> Where buffer_arrival_time is read from the system clock.<br>
<br>
</div>I believe the clock time as mentioned in the document is supposed to be<br>
already adjusted like that (i.e. time pipeline spent in playing state<br>
according to the selected clock) and not an actual clock time value.<br>
<br>
Cheers<br>
-Tim<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>