[MPlayer-G2-dev] Recommendations for DEMUXER layer

[Arpi]

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!

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

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

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

> > my "favourite" one is the quicktime mov, where the demuxer cannot
> > work without knowing the compression ratio (actually compressed and
> > uncompressed frame/block size), as mov audio chunk headers contain
> > the uncompressed(!) size of block, while it contains compressed data.
> > how dumb they were when created this mess...
> 
> Quicktime is idiotic...

wonder!!! we agree on something! :)

> > > My recommendation would be to _always_ seek to a boundary the demuxer
> > > understands. That way you have exact pts, and no broken packets for
> > > the decoder or muxer to deal with. The demuxer can skip video frames
> > > up to the next keyframe (the point you were trying to seek to) and the
> > > audio pipeline can skip the audio _after_ decoding it so that it can
> > > keep track of the exact number of samples. (Since audio decoding is
> > > very fast, this should not impact performance when seeking.)
> > 
> > the framer api -we're talking about yesterday- should solve this.
> 
> :))))

and i should write that mail down...

> > > 2. After seeking, demuxers call resync_audio_stream, which depends on
> > >    there being an audio decoder! I found this problem a long time ago
> > >    while adding seeking support to mencoder: it was crashing with -oac
> > >    copy! It's bad because it makes the demuxer layer dependent on the
> > >    codec layer.
> > > 
> > > My recommendation is to eliminate resync_audio_stream, and instead
> > > just report a discontinuity the next time the demuxer stream is read.
> > > That way the codec, if one exists, can decide what to do when it reads
> > > from the demuxer, without having to use a callback from the demuxer
> > > layer to the codec. Also, resync should become unnecessary for most
> > > codecs if my above seeking recommendation is implemented.
> > 
> > i like this idea!
> > that resync* shit was always an ugly hack :(
> 
> :)))
> 
> BTW same thing works for video, to prevent misdecoding of B frames
> after seeking and flush inverse telecine buffers after seeking too! :)

sure.
Michael said it (B frame bug after seeking in IPB mpeg) long time ago
but i didnt believe it... actually this bug exists from mpg12player v0.001
and was reported many times even in teh first days of mplayer...
(video starts with green frame, green macroblocks etc)


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu