GNOME Bugzilla – Bug 640153
[souphttpsrc] enable save-to-disk while playing HTTP streaming
Last modified: 2011-02-15 02:06:41 UTC
Created attachment 178916 [details] [review] patch for souphttpsrc to enable save-to-disk Users could save HTTP streaming content while watching it and they can watch it again later by playing the file saved earlier. Since souphttpsrc is the actual element doing HTTP download, and it knows the offset when seek happens. So I modified this plugin to save content being downloaded. I added one property in souphttpsrc, save-to-path, and when this property is set, the content will be saved to the path specified. If save-to-path is NOT set, the streaming content will NOT be saved. for example: gst-launch souphttpsrc location=http://some.address.com/meego-demo.mp4 save-to-path=/home/meego/ ! decodebin ! ffmpegcolorspace ! xvimagesink by executing the command, not only is http://some.address.com/meego-demo.mp4 being played, but also a file, meego-demo.mp4, is saved locally to /home/meego/ in addtion, in some cases when souphttpsrc is not directly used and it is not straightforward to set properties as the example above. for example, souphttpsrc could be dynamically assembled by a playbin2 to form a pipeline. e.g. pipeline = gst_element_factory_make("playbin2", "playbin"); g_object_set(G_OBJECT(pipeline), "uri", "http://some.address.com/meego-demo.mp4", NULL); apparently there is no appropriate property to set in playbin2 to pass along the 'save-to-disk' property. to address this, I have an element message with structure name, prepare-save-to-path, posted during gst_soup_http_src_start, so that whoever catches this message can get a hold of souphttpsrc and set the property, 'save-to-path', accordingly. file modified: ext/soup/gstsouphttpsrc.h ext/soup/gstsouphttpsrc.c
The same can be done with queue2, look at the temp-* properties. Is there any advantage in saving directly in souphttpsrc instead of using queue2?
during streaming, the content is not always received sequentially. e.g. some index info is stored at the end of the file, so that part is retrieved ahead than its position. by using queue, this will cause file content saved out of order and not being able to be played later.
queue2 makes sure to store the content in the correct order. It also doesn't download parts of the stream twice and instead returns the already downloaded content btw
It's really none of the http src element's business to save things in files, use queue2 for that.
ah... apparently I don't understand queue2 enough. could you please show me how configure queue2 in the playbin2 situation ? where should I put queue2 when assembling pipeline ? thanx
queue2 is used automatically in playbin2. The thing you want is download buffering and you can enable that flag in playbin2. Also take a look at totem to see how you can deal with the saved file and how you can handle the buffering messages.
thanx Wim for the pointers and totem example. definitely will look into this!!
after a few tests, I found out that only with certain formats of media, is a temp file created. here is what I have tried... - set the 'download' FLAG(0x80) in playbin2 - hooked a callback to playbin2's "deep-notify::temp-location" signal. the callback does nothing but print the property "temp-location" of that playbin2 - set uri of my playbin2 to some HTTP streaming source. the result is that only certain file formats(mp4..) would issue the " deep-notify::temp-location" signal, hence, a temp file is created. some others(wmv, ogv..) wouldn't. On further checking queue2(gstreamer-0.10.28) it seems to me that a temp file is only created if it is in pull mode. is it correct ? am I missing something here ?
Maybe you can add your test-app here, as I don't see how it would be format-dependent.
Created attachment 180872 [details] test code to see if a temp file is created by queue2
thanx, I've added my test app here. to build it: gcc -o pp save-test.c -g `pkg-config --cflags --libs gstreamer-base-0.10 gobject-2.0` to run it: ./a.out http://some.uri/test.mp4 FYI, i filed another bug about this, too. from the comment, currently queue2 did work for certain media types only. https://bugzilla.gnome.org/show_bug.cgi?id=642277#c1 It depends on the media type. There's a hard-coded list in uridecodebin, see gsturidecodebin.c, ca. line 965 onwards: /* media types we can download */ static const gchar *download_media[] = { "video/quicktime", "video/mj2", "audio/x-m4a", "application/x-3gp", "video/x-flv", "video/x-msvideo", "video/webm", NULL };