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

D Richard Felker III dalias at aerifal.cx
Tue Mar 15 18:54:10 CET 2005


On Tue, Mar 15, 2005 at 05:44:34PM +0100, Michael Niedermayer wrote:
> > 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

agree. with this implementation it really makes little difference.
ivan was talking about the bad implementation where you always read
index at startup, like mplayer's avi demuxer does.

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

exactly. it's abusive to do streaming playback from someone's ftp or
http server like this, even without seeking. eliminating one
additional seek won't really help the situation.

with that said, i sometimes abuse mplayer's http seek support to test
samples on mphq :P

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

rotfl!
we should put this in the promo material! ;)

rich





More information about the MPlayer-cvslog mailing list