mpegts latency

[Nicolas Dufresne]

Le mercredi 31 juillet 2019 à 08:47 -0600, Michael Gruner a écrit :
> 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.

Right now, one has the option to set the pipeline latency to a lower
value in order to crop the reported latency. There will be a small
warning, but it works.

You can check your current latency cost, as tsdemux will report 700ms,
but will only wait for what's needed to get proper timestamp. So using
the latency tracer will let you know what seems to be appropriate for
you stream. The stream configuration (tsmux configuration) has a large
influence on this.

> 
> 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
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190731/6a12a3ff/attachment.sig>