GNOME Bugzilla – Bug 114973
cache plugin
Last modified: 2008-10-04 21:40:56 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
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. :).
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.
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)
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.
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).
queue2 is well on its way to implement exactly this functionality.
I'm closing this, since it was my bug in the first place, and we have several elements that roughly provide this.