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

[D Richard Felker III]

On Wed, Mar 16, 2005 at 01:26:27AM +0200, Ivan Kalvachev wrote:
> 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.

Then you already need to do at least one seek operation anyway.

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

Nope, just reading the very end of the file for a backwards-pointer
(reverse vlc?) to the index.

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

Exactly. What is the problem with this? If the file is complete, you
can seek and get the duration. If not, duration is not meaningful.

> Using error recovery in perfectly normal stream, for executing perfectly
> trivial tasks, is what i consider design flaw.

No one ever suggested using 'error recovery' for this.

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

Yes it is a big issue. The nut muxer should never seek.

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

There isn't a way, for good reason. Dummy space does not belong in the
file.

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

Totally allowed. Did you read the spec?

> How will the old demuxers react on new startcodes? Again recovery 
> procedure in perfectly normal stream is not good idea.

No 'error recovery' is needed. The packet is simply skipped.

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

You misread. NUT has been designed to MINIMIZE the effects of mplayer
bugs. :)

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

If you're doing linear reading, the index is useless.

> And KiSS

Exactly why the index should always be in one place.

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

I don't care either way.

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

This is a technical discussion.

Rich