GNOME Bugzilla – Bug 783667
queue, queue2: make segment position readable so that stalled/starved queues are obvious
Last modified: 2018-11-03 12:41:28 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.
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
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/
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.
(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).
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.
-- 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.