Re: Recommendations for DEMUXER layer

On Mon, Dec 29, 2003 at 09:04:05PM +0100, Arpi wrote:
> Hi,
> 
> > > agree, but you're wrong.
> > > AVI demuxer (we're talking about g1, as g2 avi has no seeking yet)
> > > does seek to frame boundaries, using packet size of nBlockAlign.
> > > although for some codec/encoders, it's set to 1, so it can seek to
> > > any position. most common case is cbr mp3, where it used to be 1.
> > 
> > My idea was for the demuxer to always seek only to the beginning of a
> > chunk -- or are encoded audio frames sometimes split across chunks?!
> > :(
> 
> its possible.
> also possible (do you want sample files?) tat the whole audio of
> a whole film is stored in a _single_, ~100mb chunk. what a mess!

OK, thanks for making it that blatently clear that my idea sux. :)

> but it's quite usual that 10 sec (or even more) of audio is stored
> together in a single chunk, containing many (100+) frames of mp3 or ac3.
> it's lame to burst-decode it any time you seek in the file...

I was thinking of burst-frame, not necessarily burst-decode. But
that's lame too if there can be so much...

> lets forget about avi chunks, its' an internal problem of the avi
> demuxer. the avi header contains the audio block size, which is the
> elementary size of independent, aligned audio blocks. you want those
> blocks, not the raw chunks. believe me...

OK, fair enough.

> > > anywya the pts is still exact, as pts is calculated by samplerate
> > > (drRate/dwScale) multiplied by block (nBlockAlign size!) number.
> > > so, for AVI files this is not an issue. anywya there may be formats
> > > where it can be.
> > 
> > Well, Suppose you want to seek to pts X in a file, and you do so by
> > this method. But, the resulting byte position happens to be 10 bytes
> > after the start of the audio frame. So you lose this whole frame, and
> > begin framing/decoding at the next one, which is maybe 1000 bytes
> > later. This seems bad for perfect a/v sync. IMO it would be better for
> > the demuxer to seek to a point where it knows valid frames begin (if
> > this is always possible) and let the framer pick the exact frame to
> > start using.
> 
> go and rtfs g1's avi demuxer
> it does:
> 1. find vidoe frame we want to seek to
> 2. find nearest video keyframe
> 3. find audio block boundary right at or behind the keyframe selected at 2.
> 4. find the chunk containing that audio block
> 5. if position from 4. is bellow pos from 2., then find how many video
>    frames you will read from stream before the keyframe, set skip_video_frames
> 6. skip N audio blocks from the audio chunk, to get to the position
>    selected at 3.
> 7. calculate teh time difference between start of that audio block and
>    the keyframe, put the value to audio_delay to compensate delay.
> 
> yes its not easy, this is why i spent so much time on that mess.

I did RTFS it... :( That's why I was hoping we might be able to
simplify the design for G2.


Rich