GNOME Bugzilla – Bug 608301
Use appsrc instead of fd://0
Last modified: 2014-04-30 11:21:42 UTC
i can't seek in videos in totem-plugin, however, it works perfectly the player. also, it would be nice to have the buffer meter and the elapsed/remaining time in the plugin.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 606341 ***
sorry, but i don't see how this bug is related to the other. i am not saying that videos do not work well, it is just that i can't seek in the totem plugin for flv videos. seeking in wmv videos is ok
To be more clear, I use totem plugin to play Videos in all video sharing websites ( youtube, googlevideo, vimeo, sevenload, break ... ). The only thing that I am missing is the ability to seek in videos using the plugin. If i right click on the video and choose "open with movie player", i can seek normally in the player. I think that the way seeking is implemented in the plugin lacks some stuffs. So It must not be hard to fix. Hope you will fix this Bastien.
Steps to reproduce this : 1. Use http://userscripts.org/scripts/show/50771 in a greasemonkey capable browser 2. Open a youtube video 3. Try to seek Actual Results: no seeking Expected Results: normal seeking
the attached patch fixes the issue for me
Created attachment 156855 [details] [review] what i use to solve my seeking problem
*** Bug 594889 has been marked as a duplicate of this bug. ***
Review of attachment 156855 [details] [review]: That patch can obviously not be used like that, as that would mean that some websites (the ones with one-time URLs) would stop working. The correct way to fix this would be for totem-plugin-viewer to use appsrc, instead of relying on fd://0.
Using appsrc would allow us to seek even when queue2 doesn't do download buffering for us.
Also note that, for the current usage, there is a bug in queue2 which means that even once fully downloaded, the stream will not start playing back. You can reproduce the bug easily by doing: gvfs-cat http://www.istartedsomething.com/uploads/guidedhelp.mov | totem fd://0 and seeing it never start up. 0:00:07.523627314 769 0x137cc80 DEBUG queue2 gstqueue2.c:1302:gst_queue2_locked_enqueue:<queue20> we have EOS 0:00:07.523648120 769 0x137cc80 DEBUG queue2 gstqueue2.c:776:update_buffering:<queue20> filled 100 percent 0:00:07.723551736 769 0xdf0130 DEBUG queue2 gstqueue2.c:1935:gst_queue2_handle_src_query:<queue20> query buffering 0:00:07.723632531 769 0xdf0130 DEBUG queue2 gstqueue2.c:1983:gst_queue2_handle_src_query:<queue20> duration -1, writing 11737097 0:00:07.723667092 769 0xdf0130 DEBUG totem bacon-video-widget-gst-0.10.c:2440:bvw_query_buffering_timeout: start 0, stop -1 0:00:07.723686880 769 0xdf0130 DEBUG totem bacon-video-widget-gst-0.10.c:2447:bvw_query_buffering_timeout: download buffer filled up to -100.000000% Once that bug is fixed, you should at least be able to seek when it's fully downloaded, and before it's played once.
If you use the latest GStreamer core, this should make it possible to seek whilst the video is being downloaded, even when it's the browser doing the streaming. Still nowhere near as good as using appsrc, but a nifty hack nonetheless. commit 9c487aff7017df24aa2f8b22e69b9c599725e4f3 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Apr 9 14:56:30 2010 +0100 Split setting up and opening browser streams Wait until we have the browser stream set up before opening stdin in the browser, which means we might have a chance to get the stream size. With recent GStreamer changes, this means that download buffering would work, and that we'd get download progress and seeking without needing to wait until the end of the download. Helps with https://bugzilla.gnome.org/show_bug.cgi?id=608301
The browser plugin has been removed from Totem. See this post for more details: http://www.hadess.net/2014/04/good-bye-totem-browser-plugin.html