mpegts latency
Locked
mpegts latency
 
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
In reply to this post by TheGiamig
Le mercredi 31 juillet 2019 à 09:45 -0500, TheGiamig a écrit :
> Nicolas Dufresne-5 wrote > > Le mer. 31 juill. 2019 08 h 25, TheGiamig < > > thegiamig@ > > > a écrit : > > > > 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. > > > > _______________________________________________ > > gstreamer-devel mailing list > > gstreamer-devel@.freedesktop > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > If I do about the same with ffmpeg the latency go away. > I think 700ms is the maximum latency between PTS or someting, not the > minimum latency. > > Anyway, what is the best approach for a very low-latency h264 video > streaming? RTP? gst_pipeline_set_latency(), or disable the sync as Micheal suggest in the following email. But or out-of-the-box low latency, an RTP base pipeline will work better for now. > > Thanks > > > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (201 bytes)
Re: mpegts latency
|
|
In reply to this post by Michael Gruner
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 <[hidden email]> wrote: > > > > > Le mer. 31 juill. 2019 08 h 25, TheGiamig <[hidden email]> 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 > > > [hidden email] > > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
Re: mpegts latency
|
|
| Free forum by Nabble | Edit this page |