[gst-devel] seeking VBR

[Joshua N Pritikin]

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
semi-flush event?

> > 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
structure.

> 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
format, no?

> Plus, some apps don't need the certainty info (e.g. a NLE
> will always start indexing from beginning, so its indexes will be
> certain).

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,
  http://sahajayoga.org                  http://why-compete.org