GNOME Bugzilla – Bug 766673
opusdec stops decoding after some time if seek was caused
Last modified: 2018-01-20 15:01:22 UTC
Created attachment 328212 [details] GST_DEBUG=*:5 log Hello, I fetch data from HTTP and then decode it (via decodebin) and play it back to the JACK. I have noticed that if I do seek sometimes Ogg/Opus stream stops playing back after +/- 30s after seek. It works fine with MP3 and Ogg/Vorbis so I assume it's an opusdec issue.
Seek was failed after receiving EOS event because oggdemux disabled delayed seek after got EOS event on purpose. https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/ogg/gstoggdemux.c#n2422 It tells that have an issue when there is a queue2 in the pipeline. So I assume it's one of the remaining enhancement work of oggdemux.
Good hint but I am not using queue2 anywhere in my app. I am using plain queue. AFAIK decodebin uses multiqueue. Do you think that can apply also to multiqueue?
No, It disabled all the time whether the queue is added to the pipeline or not. I'll dig more or maybe Vincent who wrote this could give some advice.
The bug with queue2 is that if it gets EOS, it will push and pause its task. Since oggdemux wants to seek again, and continue, it can't tell the upstream queue2 to restart, and the pipeline hangs. oggdemux also can't tell if there is a queue2 upstream. If an EOS is received while scanning for the end timestamp, the threshold at which to stop may be increased (EOS_AVOIDANCE_THRESHOLD), but this means more imprecision in length determination. This is a handwavy value though, so it'd be nice to find a solution that doesn't rely on stopping before EOS.
Upstream queue should restart on a flushing seek, or (if you don't do a flushing seek on purpose) you could do a segment seek so that it doesn't push an eos event when done (perhaps we need an extra flag so upstream doesn't post a segment_done message on the bus as well, which might be confusing to the app).
It was always a flushing seek IIRC. Maybe needs to be tried again, there might have been another problem getting in the way, but I distinctly remember queue2's task staying paused.
Any news on this? That would be a clear bug in queue2 if it did that, and would also cause problems in general.
(In reply to Sebastian Dröge (slomo) from comment #7) > Any news on this? That would be a clear bug in queue2 if it did that, and > would also cause problems in general. Seems to work nowadays: https://bugzilla.gnome.org/show_bug.cgi?id=767689
(In reply to Marcin Lewandowski from comment #2) > Good hint but I am not using queue2 anywhere in my app. I am using plain > queue. AFAIK decodebin uses multiqueue. Do you think that can apply also to > multiqueue? Can you post the pipeline you're using ?
FWIW, I can't reproduce this with gst-play-1.0 using pulsesink. Can you reproduce it with pulsesink instead of jack ? I also had to fix https://bugzilla.gnome.org/show_bug.cgi?id=768991 for seeking to work with gst-play-1.0, in case that makes any difference.
Thanks for all the bugs you have hunted. I am no longer using JACK in my project and it has advanced so much that I am not sure whether I will be able to recreate a test case. I'll try but it may take some time as whole team has to work on something else for a while.
Could that actually be just a symptom of the cause for https://bugzilla.gnome.org/show_bug.cgi?id=766659 ? If some other element hangs, and some element between the hanging element and downstream has some buffer, the pipeline might continue playing for a bit.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!