Summary: | GStreamer-WARNING **: wrong STREAM_LOCK count 0 after changing HTML5 video.src | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jason Gerard DeRose <jderose> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | pnormand |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Linux |
Description
Jason Gerard DeRose
2011-12-20 18:37:39 PST
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. 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 :) 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! (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. Any news on this issue Jason? (In reply to comment #5) > Any news on this issue Jason? Ping? :) 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 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! |