[gst-devel] seeking VBR

[Xavier Bestel]

Le mer 27/11/2002 à 12:27, Joshua N Pritikin a écrit :
> 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?

Just disconnect it for 3 frames ?

> > 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?

I was thinking about an NLE who could save other informations (corrected
ratio, etc.) with the timecache.
But the more I think about it, the more I feel the "right" solution is
input-plugin dependant: saving would vary very much depending on where
the data comes from. A streaming client or a file plugin won't do the
same thing. The gnome-vfs plugin should take advantage of the nautilus
meta-data.

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

Mmh .. this seems unnecessary complex. I don't think doing a bunch of
additions to convert the timestamps from relative to absolute will have
any mesurable cost.

	Xav