[MPlayer-dev-eng] [PATCH] -oac copy with ac3 sound and lavf ts demuxer issues (Was: Re: [MEncoder-users] Video/Audio asynchronous)

[Michael Niedermayer]

Hi

On Sat, Feb 24, 2007 at 03:58:17PM +0100, Matthias Hopf wrote:
> On Feb 20, 07 17:25:50 +0100, Michael Niedermayer wrote:
> > > - Why is nBlockAlign, wBitsPerSample not set correctly?
> > 
> > should be fixed, please test
> 
> nBlockAlign at least is, thanks a lot!
> wBitsPerSample is not, as codec->bits_per_sample is already 0.

hmm if bits_per_sample=0 works fine too? then ill ignore this


> 
> > > - Why is dwRate/dwScale/dwStart/dwLength/dwSuggestedBufferSize wrong?
> > >   What are the right values?
> > >   I assume codec->frame_size and/or codec->sample_rate are wrong.
> > >   lavf gets it right for constant bit rate, but an unknown ac3 stream is
> > >   inherrently variable, so a VBR approach is the right thing (TM) to do.
> > > 
> > > Can anyone with a deeper understanding how demuxing in mplayer actually
> > > works comment on my findings?
> > 
> > without checking i would say mplayer is wrong and the rate/scale from lavf
> > is correct, sadly you dont say which values the wrong and correct variables
> > actually had so its hard to say for sure ...
> 
> With current SVN, audio is detected, but not really played, and supposed
> file duration is way off (too long).
> 
> I rechecked, and first stumbled over another issue: lavf thinks this
> video is 1920x1080 at 59.96fps(!), while mpegts detects 29.976. I called
> the lavf calls with -ofps 30000/1001 in order to ignore this for now.

well if lavf says 60000/1001 then i would suspect that to be true
telecined mpeg specifies frames based on such a timebase

it would be interresting to look the frame lengths (dts difference)
if there are 2 different legths with 2/3 ratio then 60000/1001 is correct


> 
> I analyzed the two avi streams, and found the following values in the
> headers to differ:
> 
>                                    lavf           mpegts
> dwTotalFrames                      $19            $27
> dwLength                           $19            $27
>    - aud AVI Stream Header
> dwScale                            $4             $1
> dwRate                             $7d            $bb80
> dwStart                            $1             $642
> dwLength                           $11            $60aa
> dwSuggestedBufferSize              $600           $5dc0
> dwSampleSize                       0              1
>    - aud AVI Stream Format
> nChannels                          6              2
> wBitsPerSample                     0              $10
> 
> Some variables of lavf:
> codec->frame_size                  $600
> codec->sample_rate                 $bb80
> 
> which sounds perfectly sensible to me (1536 samples for 384kbit/s AC3
> packets, 48000 Hz).
> 
> > note dwSampleSize MUST be 0 for VBR streams
> 
> I think I understand *that* part of avi...
> 
>          - If the dwSampleSize is 0, then it's VBR stream, so its bitrate
>          isn't constant. It means that 1 chunk stores 1 sample, and
>          dwRate/dwScale gives the chunks/sec value.
> 
> So how can I check the chunk size? One AC3 frame is 1152 in this
> case (384kbit/s), but where is this stored?

well you can easily find the size in bytes of each chunk, just search for 
00dc the size is the 32bit int afterwards after that comes the next chunk
the 00 specifies the stream id (so it could also be 01 if there are 2 streams),
the dc are 2 more or less random letters

or just run mplayer -v -v over it, that will IIRC also dump the chunk
sizes amongth other things


also the chunk sizes and their content MUST match from what lavf gives
mencoder and what mencoder stored in the stream copy case with vbr, this
is what i suspect will not be true and likely what causes the problems

mencoder is full of hacks to workaround its own bugs sadly they break
fatally if correct data is feeded to it ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070224/730a0cef/attachment.pgp>