Re: Recommendations for DEMUXER layer

Just one quick question.
Here you talk about PTS - presentation time stamps.
Are you sure that they are not DTS- decoder time stamps?
Or maybe we need both?

They differs a little.

  Ivan Kalvachev
 iive


D Richard Felker III said:
> 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
>
> _______________________________________________
> MPlayer-G2-dev mailing list
> [email protected]
> http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev
>