GNOME Bugzilla – Bug 795551
Sporadic stall during seeking on Gstreamer 1.10.4 and higher
Last modified: 2018-05-14 14:10:21 UTC
Hello Gstreamer developers, I would like to report a sporadic stall in gstreamer 1.10.4 (Debian 9) or higher versions while reading video files. I have created a standalone script, the file and the video file can be found in the following location: https://drive.google.com/open?id=14imemqvC5bP7xhDsFPbUkHG9SWmSK4Fz https://drive.google.com/open?id=15xZ1wcuQBN7pPxU7Ru08hSR7YagUQV6w The GDB stack trace from my machine can be found here: https://drive.google.com/open?id=1M8Srjd1Qp4Y8C8Edepme2lwzzWSpOZM3 The stall seems to be appearing in gst_element_seek_simple (). Here is what I am trying to do in my application: 1. Create the playbin. 2. Set the playbin to PLAYING. 3. Seek and read the first frame. 4. Seek and read the 41st frame and read 4 more samples (file has a total of 45 frames). 5. Seek back to 1st frame. That is where the STALL happens. I have put the number of iterations to be 5000 but usually the stall appears in around 200-300 iterations. This is a work stoppage issue for us as the stalls are far more frequent in our application.
The appsink specific commits should probably also go into 1.14, the other is a new regression in master. commit dbd9ff1cf5108aeb51e1559222f386eb85d2abd2 (HEAD -> master, origin/master, origin/HEAD) Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed May 2 18:39:31 2018 +0300 appsink: Handle unlock in drain query handling too And also handle flushing, we might otherwise wait here forever when flushing too. commit 9f9000e693694ea33c21607140ffc29aa1734062 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed May 2 18:35:23 2018 +0300 appsink: Make sure to also handle unlock when waiting for EOS to be handled Otherwise shutting down during EOS waiting will cause a deadlock. https://bugzilla.gnome.org/show_bug.cgi?id=795551 commit a19497ab67cf9517fb12f2bf30e034078d36a958 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed May 2 18:11:58 2018 +0300 appsrc/sink: Fix optimization for only signalling waiters if someone is actually waiting It is possible that both application and the stream are waiting currently, if for example the following happens: 1) app is waiting because no buffer in appsink 2) appsink providing a buffer and waking up app 3) appsink getting another buffer and waiting because it's full now 4) app thread getting back control Previously step 4 would overwrite that the appsink is currently waiting, so it would never be signalled again. https://bugzilla.gnome.org/show_bug.cgi?id=795551
As I use the gstreamer that is on the system, I will continue running into this issue on systems running older versions of Gstreamer. Is there a workaround available? OR is it possible to port this to older gstreamer versions? Dinesh
You'll have to talk to whoever is providing you your older version of GStreamer. They will have to backport the fix to that old version, but it should just cleanly apply to the older versions. E.g. for 1.12 you would only need the "appsink: Make sure to also handle unlock when waiting for EOS to be handled" commit, the others are not relevant for 1.12. The change will be in the next stable 1.14 release soonish.