[gst-devel] seeking VBR

[Xavier Bestel]

Le mer 27/11/2002 à 11:09, Joshua N Pritikin a écrit :
> On Tue, Nov 19, 2002 at 07:24:44PM +0100, Wim Taymans wrote:
> > The seeking event on the mpeg video decoder would then first figure out
> > what the nearest I frame is, it would convert the timestamp (or frame number)
> > to the PTS. It would then do a timeseek on its sinkpad with the PTS
> > value. Mpegdemux would get the seek on the PTS, it would map this to the
> > byteoffset of the videopacket with that PTS and would then forward the
> > byteseek to filesrc.
> 
> 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.

> Correct?  Is it true that P frames depend on the previous P frame?  Or only the
> previous I frames?
> 
> > - API to to mapping from byte<->timeoffset
> > - API to get individual index records.
> > - API to get info about a record (is it a keyframe (I frame,... ), ..)
> > - API to load/save timecache (XML?, customizable?)
> 
> 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. 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. 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).


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.

	Xav - just rambling