After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 114973 - cache plugin
cache plugin
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: NONE
Assigned To: David Schleef
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-06-11 21:32 UTC by David Schleef
Modified: 2008-10-04 21:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Schleef 2003-06-11 21:32:27 UTC
A cache plugin is similar to a queue.  It reads data from its sink pad at
whatever rate is possible, and keeps track of the buffers.  It pushes data
to its src pad at the rate needed by downstream (if possible).  It keeps a
copy of all buffers to make seeking possible.  Optionally, it stores data
on disk.

Uses:

  fdsrc ! cache ! ... -- Mozilla pushes data to a plugin at whatever rate
the data is received, and expects the plugin to take it.  This means that
the cache is necessary to hold data before it is used by downstream.  It
also allows downstread to seek, since fdsrc isn't seekable.

  v4lsrc ! cache ! xvideosink -- implement simple seeking on v4lsrc.

Options:

  - parameters to show the min/max timestamps that are seekable in the data
stream.  This could be used in a slider-bar widget that shows time elapsed
in a player.

  - parameter to cache data on disk
Comment 1 Ronald Bultje 2003-06-11 22:23:21 UTC
Allow me to do some bashing (I love that ;) ):

* fdsrc should support seeking
* v4lsrc should support querying TOTAL (number of frames emitted)
* queue already does buffering (functioning as a network cache)

I do like the seek-in-nonseekable-stream idea, but then, I'd name it
differently. :).
Comment 2 David Schleef 2003-06-11 22:54:47 UTC
fdsrc: I'd really like to see you try to seek on a socket or pipe.

The main purpose to seek on a non-seekable stream.

Please suggest a new name.  I don't like it much either.


Comment 3 Stephane Loeuillet 2004-12-19 00:40:31 UTC
even if it is not a true element, isn't this what Ronald added to totem lately ?

couldn't this code be moved to gst-plugins
or is it tied to gnomevfssrc and/or totem ?

doesn't rythmbox have such code too ?
(waiting a bit before starting playing a webstream)
Comment 4 Ronald Bultje 2005-04-14 16:50:44 UTC
Not the same. Dave added an appsrc to gst-sandbox/mozilla-plugin/ which does the
above. It has some issues, though, most of which are fixeable:

* it doesn't separate between webstreams and webfiles.
* it caches into memory instead of on-disk.
* totem doesn't use it. :).

The first may be hard to fix, but well, shouldn't be all too hard. The second is
a design thingy that is fixeable. I may end up doing this and integrating it
into Totem. Totem, right now, uses fd://0 for this purpose because of 1&&2.
Comment 5 Andy Wingo 2006-01-27 15:50:13 UTC
It would be really nice to get somethign like this working at some point, so that you get a seek bar like in the quicktime player (whereby you can seek in whatever's been downloaded so far, and it times it to start playing whenever it thinks it can play the whole stream without rebuffering).
Comment 6 Wim Taymans 2007-06-07 09:45:20 UTC
queue2 is well on its way to implement exactly this functionality.
Comment 7 David Schleef 2008-08-09 01:35:56 UTC
I'm closing this, since it was my bug in the first place, and we have several elements that roughly provide this.