After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783667 - queue, queue2: make segment position readable so that stalled/starved queues are obvious
queue, queue2: make segment position readable so that stalled/starved queues ...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-11 22:39 UTC by minfrin
Modified: 2018-11-03 12:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Expose the queue->src_segment.position and queue->sink_segment.position containing the PTS/DTS of the last buffer into and out of the queue to clearly show which queues are lagging behind and stalling (4.86 KB, patch)
2017-06-11 22:42 UTC, minfrin
none Details | Review

Description minfrin 2017-06-11 22:39:45 UTC
It is currently difficult to tell which queues are allowing data to flow and which queues are stalled, making stalled complex pipelines very difficult to debug.

Expose the queue->src_segment.position and queue->sink_segment.position containing the PTS/DTS of the last buffer into and out of the queue to clearly show which queues are lagging behind and stalling the pipeline.

This also clearly shows queues that have never delivered data, as opposed to queues that are just empty.
Comment 1 minfrin 2017-06-11 22:42:42 UTC
Created attachment 353583 [details] [review]
Expose the queue->src_segment.position and queue->sink_segment.position containing the PTS/DTS of the last buffer into and out of the queue to clearly show which queues are lagging behind and stalling

Use this along with the patch below to expose PTS/DTS in pipeline dot graphs.

https://bugzilla.gnome.org/show_bug.cgi?id=783661
Comment 2 Thibault Saunier 2017-06-14 01:41:39 UTC
Those property look weird to me in the API, this is basically only for debugging purposes and thus I do not think we want special API on the queues for that.

I am not sure how we should manage to give that information in the dumped pipeline I would guess with some new mechanism?

I think your use case of debugging stalled queues should be handled in gst-validate[0] where we should give the information in a clean report uppon timeout, this is something I have already thought about but that I have not yet implemented.

(Also dumping pipeline on SIGHUP is something gst-validate is already doing, but indeed it is nice to have in gst-launch!)

[0] https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/
Comment 3 minfrin 2017-06-14 09:26:07 UTC
Obviously it is for debugging purposes. When the pipeline is not working as expected, you want to a) see the pipeline, and b) see the exact state of the pipeline.

This patch provides the exact state of the queues, which in turn makes clear exactly why the pipeline is stuck. If I had this earlier I would have saved months and months of debugging time.

I have never heard of gst-validate, and given the problems I have been chasing aren't related to timeouts, none of that would have been of any help.
Comment 4 Thibault Saunier 2017-06-14 12:59:49 UTC
(In reply to minfrin from comment #3)
> Obviously it is for debugging purposes. When the pipeline is not working as
> expected, you want to a) see the pipeline, and b) see the exact state of the
> pipeline.
> 
> This patch provides the exact state of the queues, which in turn makes clear
> exactly why the pipeline is stuck. If I had this earlier I would have saved
> months and months of debugging time.
> 
> I have never heard of gst-validate, and given the problems I have been
> chasing aren't related to timeouts, none of that would have been of any help.

Well, your pipeline is stalled which is something -validate should eventually be able to detect and thus produce a timeout, so yes it should be able to help debugging your issue. Validate can be used directly with the tools it provides or as a GstTracer (GST_TRACERS=validate).
Comment 5 minfrin 2017-06-15 10:26:18 UTC
In my case it didn't help to debug my issue. What did help was exposing the state of the queues on the dot pipeline diagram, which allowed me to see the problem clearly and effectively in a simple manner.
Comment 6 GStreamer system administrator 2018-11-03 12:41:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/239.