GNOME Bugzilla – Bug 331701
[0.10] mozilla plugin freezes for quicktime trailers
Last modified: 2006-02-27 20:03:22 UTC
Two days ago I was able to play movie trailers from http://www.apple.com/trailers/ (maybe not all, but most). Now, after an update of my test GNOME HEAD build under /opt with jhbuild, the Totem mozilla plugin freeze trying to view any trailer. I don't know if it's a Totem issue or qtdemux issue (I updated gst* stuff too), but downloading the trailer for iPod (this[1] for example) I'm able to play it in Totem. [1] http://movies.apple.com/movies/weinstein/doogal/doogal_p320.m4v.zip ~ 8MB
Created attachment 59664 [details] A screenshot of freezed totem-mozilla
GStreamer or xine-lib backend? Could you get a backtrace of the hang?
(In reply to comment #2) > GStreamer or xine-lib backend? GStreamer, of course ;-) > Could you get a backtrace of the hang? How can I backtrace a browser plugin?
If everything else works fine, then just attach your debugger to the running totem-mozilla-viewer, and get the trace from there.
I hope I perfomed the proper task 1. Open epiphany and go to http://www.apple.com/trailers/weinstein/doogal/trailer1r/ 2. Open a terminal and see totem-mozilla-viewer plugin PID with 'ps aux` 3. Run 'gdb /opt/gnome2/libexec/totem-mozilla-viewer PID` 4. Run in gdb `thread apply all bt` The result is the following Thread 1 (Thread -1228671296 (LWP 22868)):#0 0xffffe410 in __kernel_vsyscall ()
+ Trace 66529
That's the trace from the wrong PID (dmix does a fork() to create a sound server for the first process to use a sound device if no others are using it; your trace is from the dmix sound server process) :) I can reproduce the problem though, might be related to the one in bug #331690 (that would explain the immediate EOS event; it still shouldn't freeze of course).
+ Trace 66531
The hang is fixed in GStreamer core CVS now. Movie still doesn't work though, because typefinding fails. Typefinding fails because in streaming mode the typefindelement only tries to do typefinding once it has at least x kB of data, but the quicktime file originally played is just 244 bytes and only contains a redirection URI. Setting TYPE_FIND_MIN_SIZE to 0 in gstreamer/plugins/elements/gsttypefindelement.c makes it work, but I'm not sure this is the right thing to do in general. Probably we should keep the min. limit, but just try to typefind whatever data we've got if we get an EOS before having found a type. Gotta sleep over this first though.
Fixed in GStreamer core now. Apologies for the temporary regression - will add a test case for this. 2006-02-27 Tim-Philipp Müller <tim at centricular dot net> * plugins/elements/gsttypefindelement.c: (gst_type_find_element_handle_event): When we get an EOS event and have not found a type yet (most likely because we had not yet accumulated TYPE_FIND_MIN_SIZE of data yet), try to determine the type given the data we have so far. Fixes typefinding for very short streams again, most notably quicktime redirections as used on Apple's trailer site (#331701).