[MPlayer-users] Re: divx 6

[Michael Niedermayer]

Hi

On Sun, May 07, 2006 at 01:13:43AM +0200, Alexander Noe' wrote:
> Michael Niedermayer schrieb:
> 
> >do they have 2 or more frames with differnt sizes in a chunk? rich said
> >they are unplayable without index, not only unseekable, so my guess is yes
> >and thats where you break the avi spec
> 
> That's what AVIF_MUSTUSEINDEX is for.

not according to the specs


> 
> Here you see M$'s skills in writing, the explanation actually says 
> "should use", but then the name of this flag would be kinda silly, so 
> one of those is a typo, and we are working with b0rky specs. I didn't 
> even notice that one so far.
> 
> You can say the existence of this flag is b0rked, but an AVI file is 
> not required to be playable without the index.

let me quote the spec first ...
-----
AVIF_MUSTUSEINDEX
Indicates that application should use the index, rather than the physical ordering of the chunks in the file, to determine the order of presentation of the data. For example, this flag could be used to create a list of frames for editing.
-----

this is about the order of presentation, the AVIF_MUSTUSEINDEX flag in 
noway invalidates the rest of the spec ...


> 
> >compressed video frames can vary in size -> dwSampleSize = 0
> >"If it is zero, each sample of data (such as a video frame) must be in a 
> >separate chunk."
> 
> You could put several audio frames, like several MP3 frames, into one 
> chunk this way, and point to each frame in the index. This would still 
> be using the low overhead rule.

i dont think thats valid either, but iam not overly interrested in arguing
about this much longer ...


> 
> Also:
> >>>
> dwScale
> 
> Used with dwRate to specify the time scale that this stream will use. 
> Dividing dwRate by dwScale gives the number of samples per second. For 
> video streams, this is the frame rate. For audio streams, this rate 
> corresponds to the time needed to play nBlockAlign bytes of audio, 
> which for PCM audio is the just the sample rate.
> <<<
> 
> You can read it like "dwScale and dwRate can be used to redefine what 
> a frame or a sample is by setting those values to something resulting 
> in the definition you want to enforce". And voilà, no conflict anymore 
> even with several unseparable units of viewable data (this is what you 
> are referring to as 'video frame' but is subject to be redefined) in 
> the same chunk...

to me "For video streams, this is the frame rate" is clear enough ...
anyway its irrelevant low overhead odml-avis dont set dwScale/Rate that
way or? not to mention if they did then the odml index itself would
have to point to the new "frames" and not the individual ones

you can twist it whichever way you want these files are not valid
avi files, sorry
thats also why many players have difficulty playing them, they where
written based on the spec ...

why exactly are you trying so hard to make low overhead odml-avi look
like they where spec conformant?

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is