mpegts latency

[Michael Gruner]

Additionally, if I recall correctly, Transport Stream has a theoretical 700ms latency as per the spec and, hence, its hard coded in the element. Said in other words, this latency is induced artificially by GStreamer to comply with TS spec.

You can do a quick test by hacking the element to remove that latency, or using sync=false, or using gst_pipeline_set_latency.

The later will override the overall latency reported by the elements. Just recall that this latency is there for a reason and it’s not always a good idea to remove it entirely.

Michael
www.ridgerun.com

> On Jul 31, 2019, at 7:13 AM, Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
> 
> 
> 
> Le mer. 31 juill. 2019 08 h 25, TheGiamig <thegiamig at gmail.com> a écrit :
>> Hi all,
>> I'm facing a latency problem using mpegtsmux and tsdemux elements (windows7,
>> gstreamer 1.15.1).
> 
> 
> Unrelated, but quick reminder that 1.15 is a development branch and should be considered unstable. You should use 1.16 stable releases.
> 
>> 
>> I have to stream some h264 video content but my problem occurs also without
>> actually stream through UDP.
>> 
>> If I launch the following pipeline I can see the captured video without
>> latency problems (few ms):
>> 
>> gst-launch-1.0.exe dx9screencapsrc x=0 y=0 width=100 height=100 !
>> videoconvert ! queue ! x264enc tune=zerolatency speed-preset=ultrafast
>> byte-stream=true ! queue ! h264parse ! avdec_h264 ! videoconvert !
>> autovideosink
>> 
>> But if I add mpegtsmux and tsdemux elements the video latency will be around
>> 1sec:
>> 
>> gst-launch-1.0.exe dx9screencapsrc x=0 y=0 width=100 height=100 !
>> videoconvert ! queue ! x264enc tune=zerolatency speed-preset=ultrafast
>> byte-stream=true ! mpegtsmux ! queue ! tsdemux ! h264parse ! avdec_h264 !
>> videoconvert ! autovideosink
>> 
>> Any idea about this latency increment?
> 
> 
> 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.
> 
> 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.
> 
>> 
>> Thank you
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190731/e35fb100/attachment.html>