GNOME Bugzilla – Bug 334664
Calls _write_ready even though we can't play the file anymore
Last modified: 2006-09-04 10:19:21 UTC
Please describe the problem: Howdy -- I was all set to take my new GStreamer 0.10 enabled Totem plugin for a test drive. I headed over to the Onion to listen to their radio news. Totem didn't seem to think it could handle the audio file. Strange, I thought. It handles audio/mpeg files just fine from the desktop. Looking at about:plugins, audio/mpeg is not one of the MIME types Totem thinks it supports. So I headed over to Plugger's testing grounds to see what Totem *could* handle. For most of the video types, Totem simply sits there as if it were playing, but playing nothing. For some of them, it gives an error that Totem could not play fd://0 It'd be great if Totem Mozilla were reliable as an embedded media player. Thanks! -jag Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
We only add support for embed media, and only on request (ie. we don't support everything the stand-alone Totem would). In which page, and which link did you see that?
For the non-support of audio/mpeg, try: http://www.theonion.com/content/node/46213 For the play-without-playing behavior, try: http://fredrik.hubbe.net/plugger/menu.html?f=test.mov For the fd://0 error, try: http://fredrik.hubbe.net/plugger/menu.html?f=test.wav -jag
This appears to me as a bug by "design", I wonder how it can even work for anyone (probably distro specific patches or I overlook something) After being (very) annoyed by the fact that the mozilla plugin does not work at all (for me at least) I was eager to upgrade to the latest version and compile it from source. It still was buggy and only showing a second of a movie then stopping as described in the first comment. After investigating the problem, I found out for most of the time the totem-mozilla-viewer's command line arguments for the movice source are the bug. A typical case is a call like: totem-mozilla-viewer --xid # --x # --y # --url <movieurl> fd://0 In the code, this results in the viewer setting "emb->filename" to "fd://0" and "emb->orig_filename" to "<movieurl>". Looking further, "emb->orig_filename" is not used to open the file in the plugin at all, infact "emb->filename" is which always will contain "fd://0" which can not be played back... So logically that can not work at all. However I ask myself why it plays back a short snip of a movie and stops right after even with this totally not-supposed-to-open-anything-aside "fd://0". I assume that it correctly attempts to play from the url provided however after some sort of "initialization" it attempts to play "fd://0" which can not be played resulting in stopping the plugin. I edited the totem-mozilla-viewer.c myself for the --url argument to set "emb->filename" and "ignore" the "fd://0" argument. Suddenly all movies played back and it started working for me. However there is prolly a reason for emb->orig_filename/filename usage. Just someone has to fix it otherwise I assume totem-mozilla-viewer can be considered broken on all distros. I might of course overlook something since I am not a dev but hope this information helps. My setup: Firefox 1.5.0.1 Totem 1.4.0 GStreamer 0.8 Gnome 2.12
I don't want to be an ass here, but I've done masses of work to assure that the plugin works for common media types. On the last 0.8 gst releases (you really need 0.8.12 here, 0.8.11 has none of those patches and works poorly for streaming input, ıf at all), it supports all major media types (including, but not limited to, mpeg quicktime avi asf/wmv wma wav mp3 ogg etc). I test (most of) those media types daily on my favourite websites, and they still work. If they dont, update gst/totem. I haven't tested gst0.10, but was told it doesn't support streaming for most media types. The only thing not supported is rewind on eos, so you need to reload a page to see the media again. An annoying bug, and I will probably fix it at some point.
And for the comment above, it plays from stdin because the mozilla process provides us with data (for cookies/authentication etc.). It is supposed to be like that and should work fine. It is not the cause of your problem. You probably use an old totem/gst0.8.
(In reply to comment #2) > For the non-support of audio/mpeg, try: > http://www.theonion.com/content/node/46213 Indeed, doesn't work. But we would need the plugin to only handle embedded media. Otherwise people would get the plugin when they try to download MP3s or videos from the web. Dependency added. > For the play-without-playing behavior, try: > http://fredrik.hubbe.net/plugger/menu.html?f=test.mov This doesn't play with xine-lib either, probably a slightly broken file. > For the fd://0 error, try: > http://fredrik.hubbe.net/plugger/menu.html?f=test.wav Works fine.
(In reply to comment #6) > (In reply to comment #2) > > For the play-without-playing behavior, try: > > http://fredrik.hubbe.net/plugger/menu.html?f=test.mov > > This doesn't play with xine-lib either, probably a slightly broken file. This has side effects though. We seem to keep on calling _write_ready even though we know we can't play the file any further. We'd need to tell the front-end to stop trying to send us data. That's the only bug left in this bug, bug 301913 contains the audio/mpeg support.
Created attachment 70550 [details] [review] totem-stop-sending-data.patch Start of a patch. But it seems that we actually send back "0" as we should. -1 to stop?
Couldn't we store the NPStream* in NewStream in our plugin struct, and then destroy the stream in the callback?
Created attachment 70557 [details] [review] totem-stop-sending-data-2.patch The same one, but that manages to send and receive the signals. Problem is that _write_ready doesn't stop being called even if we send back -1. Let's try with deleting the stream now.
[ Yes, the only special return value for WriteReady is 0, see this comment in ns4xPluginInstance.cpp: // if WriteReady returned 0, the plugin is not ready to handle // the data, suspend the stream (if it isn't already // suspended). ]
I just committed this to CVS. It doesn't stop the spinner in the front-end though, so not closing just yet. 2006-08-09 Bastien Nocera <hadess@hadess.net> * src/totem-mozilla-interface.xml: * src/totem-mozilla-plugin.cpp: * src/totem-mozilla-scriptable.h: * src/totem-mozilla-viewer.c: (totem_embedded_class_init), (totem_embedded_emit_stop_sending_data), (totem_embedded_open), (on_eos_event): add a StopSendingData signal to the viewer, and call it when the front-end should stop sending us data, the plugin then stops sending data, and destroys the stream (Closes: #334664)
Christian, to reproduce the bug: - Go to a page that will be streaming video/audio - run "killall totem-mozilla-viewer" - see the browser spinner still spinning, and trying to push data from the site where the video is.
Pushed to Mozilla's bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=351284