[MPlayer-dev-eng] [PATCH] ae_lavc: set nBlockAlign like libavformat
Nicolas George
nicolas.george at normalesup.org
Sat Aug 27 21:52:44 CEST 2011
Le decadi 10 fructidor, an CCXIX, Reimar Döffinger a écrit :
> > I do not think this is broken. As far as I understand the spec,
> > dwScale/dwRate is what, in sane formats, is called the time_base. Therefore,
> > setting dwScale=frame_size and dwRate=sample_rate is correct. That is what
> > lavf does too, except it reduces the fraction.
> No, that is just nonsense for VBR.
> This is about the best I found, see the part talking about VBR:
> http://www.virtualdub.org/blog/pivot/entry.php?id=27
> dwScale/dwRate should be set to how much audio in seconds an audio
> frame results in,
Please forgive me if I am missing something obvious, but it seems to me that
is exactly frame_size/sample_rate: frame size is the number of samples in an
audio frame, and sample_rate is the number of samples in a second.
And that is also the time base, assuming the timestamp is the frame number,
increasing by 1 each time.
> and nBlockAlign to some "huge" value
That seems coherent: lavf uses the following rule:
packet_duration = ceil(packet_size / nBlockAlign)
If nBlockAlign is bigger than any possible packet_size, the result is
packet_duration = 1.
> (for which I suspect setting to frame_size might be a rather unreliable
> substitute).
That is probably true, especially for codecs that accept very high bitrates
or lots of channels. The frame size in bytes is probably a good guess, on
the other hand.
> For the CBR case it really can/should be set to correspond to the byterate,
> and nBlockAlign to 1.
It only matters if a single audio frame can contain several audio "packets"
that can be decoded separately. IMHO, we do not want to produce those
monsters, except for the special case of PCM.
> I think the sample in bug 1958 uses this, and it
> is completely broken by how demux_lavf sets up dwScale/dwRate while it
> works fine with demuxer mkv.
I will try to look into it, but right now I am confused by the fact that you
are talking about the demuxer, not the muxer.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110827/b975f0b0/attachment-0001.asc>
More information about the MPlayer-dev-eng
mailing list