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

[Diego Zuccato]

D Richard Felker III wrote:

> Total data read is irrelevant since the index will only be about 100k
> anyway. On the other hand, seeks are very expensive. If I want to seek
> 90 minutes into a movie, that's 180 seeks times 150 ms/seek (average
> for a cdrom) = 27 seconds!! That is total nonsense!!
Think about when the file is incomplete... Now, if you try to watch a
movie from cdrom (especially from a slow one, like an 8x usually found
in laptops) and want to be able to seek, you have to read the whole CD
twice!

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

BYtE,
 Diego.