Hi all,
I would assume that there is a mechanism existing that tracks either the delay for one pipeline item and / or tells the absolute timestamp when an item is transferred into a pipeline element and when it leaves... How can I enable such a tracking? I have some noticable delays and I was not yet able to find out where it comes from... Thanks. Best regards, Erik _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hello. As far as I know, you can run your code with GST_TRACERS=latency. See: https://gstreamer.freedesktop.org/documentation/additional/design/tracing.html?gi-language=c That will log the latency. AFAIK this latency measurement is not accurate at all or reliable. But maybe someone else can explain more about it. \o On Sat, Apr 11, 2020 at 4:45 PM Erik Rull <[hidden email]> wrote: Hi all, _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le samedi 11 avril 2020 à 16:50 -0500, Fabián Orccón a écrit :
> Hello. > As far as I know, you can run your code with GST_TRACERS=latency. > See: > https://gstreamer.freedesktop.org/documentation/additional/design/tracing.html?gi-language=c > > That will log the latency. AFAIK this latency measurement is not > accurate at all or reliable. But maybe someone else can explain more > about it. For the delays, best is to use GST_DEBUG="GST_SCHEDULING:5" kind of log. It will trace when a pad push starts and ends. That will effectively measure the push back delays. The latency tracer should be accurate at measuring the latency. Though, it has bugs in presence of reordering (like B-Frames). On top of this, it seems that some elements maybe drop or reorder events, which affects a lot this tracer, as it relies on serialized event to measure the latency. It's a complex process to trace this, we hope to find better and more reliable ways, but the values it normally gives are quite accurate. They are meant to be compared against the element reported latency. Unlike the push back delay, the latency represent how much time there is between a buffer being pushed in an element, and the "same" (but transformed) buffer coming out. So if the buffer is placed in a queue for few frames, this will be accounted. Processing time is also included, but for simple filters, the processing time is already visible through the GST_SCHEDULING debug category. > > \o > > On Sat, Apr 11, 2020 at 4:45 PM Erik Rull <[hidden email]> wrote: > > Hi all, > > > > I would assume that there is a mechanism existing that tracks either the delay > > for one pipeline item and / or tells the absolute timestamp when an item is > > transferred into a pipeline element and when it leaves... > > How can I enable such a tracking? > > > > I have some noticable delays and I was not yet able to find out where it comes > > from... > > > > Thanks. > > > > Best regards, > > > > Erik > > _______________________________________________ > > 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 |
Free forum by Nabble | Edit this page |