Bug 74986 – GStreamer-WARNING **: wrong STREAM_LOCK count 0 after changing HTML5 video.src

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Jason Gerard DeRose]

I'm using WebKitGtk (with PyGI and Python3, although my hunch is that's irrelevant) for a video browser.

Playback using the <video> element works awesome, but when I switch from one video to the next by changing the video.src from the DOM with JavaScript, I get this error in the terminal:

GStreamer-WARNING **: wrong STREAM_LOCK count 0

Once this happens, the app freezes up. The next video doesn't play, and I can't do anything... not even close the app. After the timeout, I can force quite.

Haven't yet spotted a pattern to this. It doesn't happen every time... sometimes I can play, say 5 videos or so before this happens.

Regardless, hats off to everyone who has worked on the WebKitGtk GStreamer integration... the performance is incredible.  I can play 50mbit/s 1080p video from a 5D Mark II perfectly smoothly, yet have the rich layout and friendly web-metaphores available with WebKit!  My UI designer is happy! :)

[Jason Gerard DeRose]

One other quick note... this isn't just an issue with MOV files from the 5D Mark II, I've also tested a lot with webm proxy files, and there doesn't seem to be any difference.

[Philippe Normand]

Could be an issue with either the DOM bindings or PyGI...
Can you try to re-implement your use-case in pure javascript? Changing video.src is quite common and this is the first time I hear about this issue :)

[Jason Gerard DeRose]

Philippe,

So I'm just using PyGI to setup the Gtk Window and that sort of thing... PyGI isn't playing any part during the video playback, that's all JavaScript controlling it.

In terms of re-implementing my use-case in pure JavaScript... is it still okay if PyGI is what's doing the setup on the Gtk side of things?  Or what do you mean by that?

But I'll keep playing with this and see if I can come up with an isolated way of reproducing it.  It's all HTTP too... the UI talks to a locally running CouchDB and that's what serves all the HTML, JavaScript, and CSS files.

The video files are currently coming over HTTP too, although we want to use a GStreamer URI handler plugin in the near future so there is no HTTP there.

Thanks!

[Philippe Normand]

(In reply to comment #3)
> Philippe,
> 
> So I'm just using PyGI to setup the Gtk Window and that sort of thing... PyGI isn't playing any part during the video playback, that's all JavaScript controlling it.
> 
> In terms of re-implementing my use-case in pure JavaScript... is it still okay if PyGI is what's doing the setup on the Gtk side of things?  Or what do you mean by that?
> 

Not sure. Is your code available online? Maybe I can have a look...

The "wrong STREAM_LOCK count 0" warning is emitted by GstTask. It seems the call to g_static_rec_mutex_unlock_full() returns 0, meaning that the stream lock wasn't first acquired in the calling thread.

It'd be interesting to know which element uses that GstTask, which thread acquires the lock and which one tries to release it.

Can you try to run your code in gdb like this?

G_DEBUG=fatal_criticals gdb -args /usr/bin/python ...

When the warning is emitted you could inspect the stack trace and the list of threads.

[Philippe Normand]

Any news on this issue Jason?

[Philippe Normand]

(In reply to comment #5)
> Any news on this issue Jason?

Ping? :)

[Jason Gerard DeRose]

Philippe,

Sorry I didn't get back to you sooner!  I haven't encounter this for a while, but I've also been doing less playback lately (been working in other areas).

If you look at comment #2 here, someone else is seemingly getting the same bug with exaile, suggesting it's a GStreamer issue, not WebKitGTK

https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/906784

But even when I do encounter this bug, I haven't figured out how to reliably reproduce it yet.  I'll do some more serious digging on this, but I wont have time till next week.

Sorry again for the delay!

Cheers,
Jason

[Philippe Normand]

Seems like this was a bug in glib: https://bugzilla.gnome.org/show_bug.cgi?id=670846

Please update glib and try again :) Feel free to reopen if needed!