GNOME Bugzilla – Bug 638781
Video hangs on seek with FLUSH flag
Last modified: 2011-10-04 23:15:03 UTC
In Shotwell, we create video thumbnails by doing a seek through a file, then capturing the buffer to a Pixbuf. Our seek uses a FLUSH flag because many GStreamer codecs seem to require it. However, we've had to disable it due to a problem with a voice annotation video generated by a Sony camera. The video plays correctly in Totem, but when we try to create a thumbnail it hangs on the line: thumbnail_pipeline.seek_simple(Gst.Format.TIME, Gst.SeekFlags.NONE, video_length / 3); This bug is not specific to Shotwell; the following code sample has the same problem: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/examples/snapshot/snapshot.c The issue only occurs for me when the "ugly" plugins are installed on my Maverick box. For more information, see this bug in the Yorba ticket database: http://trac.yorba.org/ticket/3041 This is the file having the issue: http://trac.yorba.org/attachment/ticket/3041/DSC09210.MPG
I can't reproduce this with the -base/tests/examples/snapshot program (neither with the mpeg demuxer from -bad nor with the one from -ugly). Could you attach a GST_DEBUG=*:5 log please so we know what plugins are used exactly? Could you test with git please? > Our seek uses a FLUSH flag because many > GStreamer codecs seem to require it. It also makes more sense than not using it in this case. > However, we've had to disable it due to a problem with a voice annotation video > generated by a Sony camera. That doesn't seem like a good reason not use it (It should work either way of course, but the FLUSH code path is *way* more tested because that's what's used when seeking in media players).
Created attachment 177628 [details] GStreamer log
I've attached a log as requested. I'll try building GStreamer from trunk later this week and testing with the latest and greatest.
the information is provide, reopening...
Eric, does it work better with latest releases ?
We've actually moved creating video thumbnails into a separate process. Last I checked was in Ubuntu Maverick, where the problem occurred 100% of the time. I discovered something that might be of interest to you, however; when testing with the sample video (in the initial description) I was able to stop GStreamer from hanging with the same code by switching from time-based positioning to a percentage.
So I assume this to be OBSOLETE. Please reopen if this is still an issue.