[gst-devel] seeking VBR
Joshua N Pritikin
vishnu at pobox.com
Wed Nov 27 03:28:04 CET 2002
On Wed, Nov 27, 2002 at 11:53:59AM +0100, Xavier Bestel wrote:
> Le mer 27/11/2002 Ã 11:09, Joshua N Pritikin a Ã©critÂ :
> > OK, but there are still some steps remaining to achieve frame-accurate
> > seek with only an I-frame index:
> > * Seek to the nearest I-frame
> > * Decode the I-frame, but don't display it
> > * Decode, but don't display the intermediate P & B frames
> > * Once the desired frame is found then resume normal playback
> IMHO all this should only be done by the app. The app would just ask
> "what's the I frame just before that point" and seek there, then it
> would decode until it reaches the desired time point. This would enable
> some apps to do something useful with the decoded frames (even if they
> are not displayed), e.g. cache them.
Yah, that's fine too. However, we still need to provide an API
to accomplish it. Currently, i don't think there is a way to tell
xvideosink to skip the next 3 frames or osssink to drop the next
3/25 seconds. (Correct me if i am mistaken.) Something like a
> > This looks pretty easy except for load/save. What i suggest is to save
> > each timecache as a directory instead of as a single file. This way
> > we can put big-endian binary data in individual files along side
> > an XML file with all the metadata. If this sounds strange then we
> > can also support a tar.gz format transparently.
> Maybe the load/save ops should be done (or doable) by the app.
Dunno. Personally, i'd want to make the timecache an opaque data
> Some apps
> will want to save some other metadata about the mpeg, and want to avoid
> to have a gazillion metafiles. Nautilus could integrate the timecache in
> its metadata.
What use cases do you have in mind? Nautilus can store a tar of
XML & binary data in its metadata-cache just as easily as any other
> Plus, some apps don't need the certainty info (e.g. a NLE
> will always start indexing from beginning, so its indexes will be
The certainty flags consume an insignificant amount of space. i don't
see any reason to omit them, even if they remain unused.
Another idea which is probably obvious: When we convert fuzzy or uncertain
data into certain data, maybe we can avoid changing all the values.
For example, if all timestamps are changing by a constant amount
then we can add a timestamp_base field to the TimeCacheGroup and
only update this one value.
> What would be great is a decoder/demuxer-independant API. Being able to
> say "seek to the decodable frame just before this timestamp" on any type
> of file (mpeg, avi/qt with anything inside, etc.) would help a lot.
Yah, obviously. Perhaps the terminology in GstTimeCache should be
changed. Instead of (location, timestamp) tuples, use arbitrary
names like (value1, value2).
Victory to the Divine Mother!! after all,
More information about the gstreamer-devel