[Bug 642277] [queue2] not all streaming files are saved

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=642277
  GStreamer | gst-plugins-good | 0.10.28

--- Comment #6 from jia-cheng.hu at intel.com 2011-02-23 11:22:10 UTC ---
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 :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.