<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 31 juill. 2019 08 h 25, TheGiamig <<a href="mailto:thegiamig@gmail.com">thegiamig@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
I'm facing a latency problem using mpegtsmux and tsdemux elements (windows7,<br>
gstreamer 1.15.1).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Unrelated, but quick reminder that 1.15 is a development branch and should be considered unstable. You should use 1.16 stable releases.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have to stream some h264 video content but my problem occurs also without<br>
actually stream through UDP.<br>
<br>
If I launch the following pipeline I can see the captured video without<br>
latency problems (few ms):<br>
<br>
gst-launch-1.0.exe dx9screencapsrc x=0 y=0 width=100 height=100 !<br>
videoconvert ! queue ! x264enc tune=zerolatency speed-preset=ultrafast<br>
byte-stream=true ! queue ! h264parse ! avdec_h264 ! videoconvert !<br>
autovideosink<br>
<br>
But if I add mpegtsmux and tsdemux elements the video latency will be around<br>
1sec:<br>
<br>
gst-launch-1.0.exe dx9screencapsrc x=0 y=0 width=100 height=100 !<br>
videoconvert ! queue ! x264enc tune=zerolatency speed-preset=ultrafast<br>
byte-stream=true ! mpegtsmux ! queue ! tsdemux ! h264parse ! avdec_h264 !<br>
videoconvert ! autovideosink<br>
<br>
Any idea about this latency increment?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">tsdemux has 700ms latency, as required by the MPEG TS specification. I am considering adding a property to lower that, for those who know what they are doing. Lowering it too much would lead to erroneous timestamp to be produced.</div><div dir="auto"><br></div><div dir="auto">On top of that, h264parse adds 1 frame latency, your display element likely add another one, and the capture element very often have up to one frame latency, there is finally a 20ms processing delay allowed iirc. So that's pretty close by 1s.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thank you<br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div>