[MPlayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.69,1.70

Michael Niedermayer michaelni at gmx.at
Tue Mar 15 17:44:34 CET 2005


On Tuesday 15 March 2005 14:17, Ivan Kalvachev wrote:
> Michael,
> Are you going to answer my mail?
> Or just ignore me like you use to do.
> Take care
>    Ivan Kalvachev
>   iive
> On Thu, 10 Mar 2005 01:15:09 +0200
> Ivan Kalvachev <ivan at cacad.com> wrote:
> > > what do u want to use a index for if u are limited to sequential/linear
> > > reads? seeking would be impossible per definition
> >
> > Seeking backwards is impossible by definition..
> >
> > Anyway, it is not a case of impossible seeking, just a case where
> > it should be avoided when possible.
> > e.g.
> > Just give you example with avi files.
> > Opening stream. reading header.
> > seeking to end (close, and open stream again). read index
> > seeking to beginning (close, and open stream again), start reading.

no, u seek to where the user wants to seek to
1. read header
(user seeks)
2. read index
3. read where the user wants to seek to

> >
> > If server is configured to allow only 3 opens of same file per second,
> > then one more seeking will throw you away as flooder/DDoS-er

its always possible to construct a situation where some problems exists, and 
the ability to place the index at the start will not solve this problem, as 
noone will rebuild their files after muxing to have the index at the start 
(especially not the warez kiddy ftp admin who runs such a server)

> >
> > Also don't forget how painful is mplayer cache when it have to fill the
> > cache. with default 20% it reads few megabytes that it throws away just
> > to start read them again after a while.

use nut, it has been designed so as to minimize the effect of various mplayer 
bugs ...


"nothing is evil in the beginning. Even Sauron was not so." -- Elrond

More information about the MPlayer-cvslog mailing list