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

[Ivan Kalvachev]

On Tue, 15 Mar 2005 17:44:34 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Tuesday 15 March 2005 14:17, Ivan Kalvachev wrote:
> > 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

I was giving example of normal opening of the file. Not seeking!
Seeking is done when playing starts, e.g. to skip opening.

Anyway, this is only example for what i am trying to convince you.
Making nut ONLY linear writable have also other
basic design disadvantages.

It makes impossible to write down the exact position of the index.
So searching for index should be done by reading random part of the end
of the file, using error recovery mechanism. 

Also this means that we may not know the duration of the file,
without seeking to the end. There we should get index or using recovery
mechanism to locate (key)frame and extract pts from it.

Using error recovery in perfectly normal stream, for executing perfectly
trivial tasks, is what i consider design flaw.
What do you think? (yeh it will work, ogm works too)

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

They will if there is program to do it. E.g. Can you find avi muxer that
can move index in beginning? Can FFmpeg do it? AVI-Mux?
And for windows luser that want to preview partial download, this is
major problem because WMP always want to read the index.
(anyway this is not relevant for nut)

Well, It actually would be better if nut muxer does put the index in the
beginning on it's own. As index is very small it is not an real issue to
leave 64kb of junk data, so 6 hours of movie could be covered by it.

This of course rise another point.How to make an dummy space in
NUT?(without using some ugly hack)

This also reminds me about the problem of future extensions.
What if in some future moment we need an new packet type for 
irrelevant data?
How will the old demuxers react on new startcodes? Again recovery 
procedure in perfectly normal stream is not good idea.

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

 Very funny. This is feature not bug:)
This is MPlayer Container Format... It would be sad if MPlayer have
major drawbacks with it:P

Just for protocol. I don't think linear write is bad feature.
I think linear reading is also nice feature.
And KiSS

BTW,
Do you think we should move this thread in -dev?
It is already quite big for -cvs.

Wish You Luck
   Ivan Kalvachev
 iive

P.S.
Dalias Shut The Fuck UP. If you want to tell me something, say it in the irc.
I want an technical discussion with Michael.