GNOME Bugzilla – Bug 642277
playbin, uridecodebin: add API to force downloading buffering for all/other media types
Last modified: 2013-08-16 11:00:02 UTC
Created attachment 180812 [details] test sample code i tried to save http streaming content to a local file. i did the following: - set the 'download' FLAG(0x80) in playbin2 - set uri of the playbin2 to some HTTP streaming source - hooked a callback to playbin2's "deep-notify::temp-location" signal. the callback does nothing but print the property "temp-location" of that playbin2 - start playbin2 i expected my callback being invoked and telling me what the temp file is. 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. attached is my test file, 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
> 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. 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 };
it seems clear that queue2 only download certain media types, may i suggest another way to do the download ? (which i had developed a patch already :) https://bugzilla.gnome.org/show_bug.cgi?id=640153 thanx,
The better solution would be a property on queue2 to force downloading of other media types too
Just to be clear, queue2 itself doesn't care about the media types. It is playbin2/uridecodebin that will only plug a queue2 element for certain media types if so requested. I agree with the other patch having been WONTFIXed. If you always want to save the http data, there are different ways of achieving that: - you could set up a pad probe on the source's source pad and capture data there and do with it whatever you like - you could create a convenience bin http source with a higher rank than souphttpsrc that contains souphttpsrc ! queue2 or some other element that saves date to disk.
Erm what I meant was a property on playbin2, not queue2, for forcing the behaviour for all media types. Or another flag
i see. now I understand queue2 is capable of saving other types, and I am not trying to get rid of queue2. the scenario that I am trying to achieve is to save HTTP streaming content while it is being played. I plan to do it as high level as possible, preferably playbin2 only, so the user/developer doesn't need to fiddle with underlying components like making specific pipelines, etc. As I figure i don't have much to say to add a property in playbin2 so I settle for adding a property in httpsoupsrc, which, can be leveraged by playbin2 easily by add a property in playbin2, IF this patch is accepted :) I am proposing 'another' way to save http streaming and it doesn't conflict whatever queue2 is doing. just a different way, maybe more from a network perspective than media perspective. the following is my reason to do it in httpsoupsrc, please correct me: 1) this is a media-type-blind solution. as comment above, playbin2/uridecodebin needs to specifically plug queue2 for supported types. This patch in httpsoupsrc doesn't need that. ALL types using httpsoupsrc to do http download are covered and AFAIK, most http streaming do use httpsoupsrc. 2) this is a very simple. maybe the implementation is not refined(error checking, Windows cases...), but for proof of concept, this shows, with dozens lines of code, this will do the trick. 3) as opposed to application being notified about the location of the saved file(queue2), this patch allows application actively sets where the saving location is. just a thought :)
(In reply to comment #5) > Erm what I meant was a property on playbin2, not queue2, for forcing the > behaviour for all media types. Or another flag i'd like that, too. hence i do this. IF this souphttpsrc patch is accepted, i can propose to patch playbin2 to add a property(already done:). my initial goal is to do this: gst-launch playbin2 uri=http://some.server/demo.avi save-to-path=/home/gst/Video no need to worry about media types, just saying :)
Instead of your souphttpsrc patch that adds lots of code that does the same as other code elsewhere it would much easier to just add this property to playbin2/uridecodebin. Do you want to do it?
sure, i can give it a shot.
Any news on this?
Could also be done as a signal, with the current whitelist as default implementation. Then the application can override this and add other media types if it wants to, or just return TRUE for all.
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 704933 ***