[MPlayer-users] Re: lavc-Options for *BEST* quality?

[D Richard Felker III]

On Thu, Feb 13, 2003 at 06:02:14PM +0000, Mark Zealey wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Thu, Feb 13, 2003 at 06:40:46PM +0000, Diego Zuccato wrote:
> 
> > > > continuous, but it would allow seeking in incomplete files.
> > That was the key point ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > > Anyway seeking is already possible in incomplete files with the MPCF
> > > draft, altho a little more work is required. You have to seek one
> > > packet at a time, not in whole keyframe steps.
> > Well, I don't know what it is. Mine was just a proposal... Nothing about
> > a missing "global index", that is really useful if the file is complete.
> > But then you have to sacrifice 100K of memory just to keep it... O:-)

Actually a lot more. The 100k is compressed; in memory you'd want to
store it flat for simplicity. But even a couple megs is generally
considered trivial by mplayer developers. :)

> > The dear old complexity tradeoff... Is it better to keep a bug struct
> > accessible in short time or a small one that requires a lot of time to
> > be accessed? (think about n-ary trees vs binary-trees... a node in a
> > binary-tree is smaller, but the tree is deeper. And is it worth keeping
> > a parent pointer in every node or is it better to do a search every time
> > the parent is needed?)
> 
> Why not have like a key seek packet, so eache keyframe has a set of pointers to
> the next and previous keyframe, but every 10 keyframes there is a pointer to a
> keyframe 10 keyframes away, a sort of super key-frame, this could be layered
> many times over, and wouldn't take up much space but would allow much better
> seeking about non-indexed files. To seek to a place in the file it would be
> almost a binary-search down the 'tree' of next/prev pointers to keyframes...

You can already do a nice pseudo-binary-search using average bitrate
and looking for startcodes. For example if you want to seek to 50%
time, seek to the middle of the file first and look for a startcode
and timestamp. Then re-calculate bitrate averages on both sides based
on this timestamp and recurse into whichever side the timestamp you're
looking for is on. Should be very fast and doesn't require extra
header info.

Rich