[MPlayer-dev-eng] [PATCH] ae_lavc: set nBlockAlign like libavformat

[Reimar Döffinger]

On Sat, Aug 27, 2011 at 09:52:44PM +0200, Nicolas George wrote:
> 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.

Hm, yes, sorry. I had the wrong idea again about what frame size means.

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

Well, for some codecs the "customary" value if such exists might be
better.
For others something extreme like 0xfffffff (255 MB or so) might be
simpler and more reliable, particularly since I do not know whether all
codecs set frame_size.

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

With -oac copy we probably won't have much choice if the input file is
in such a format.

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

The muxer mostly takes the values as they come from the demuxer, sight
unseen.
This works with the mkv demuxer that keeps the dwScale/dwRate as they
are, based on bitrate.
For demuxer lavf I guess there are two ways to fix it: Also keeping
dwScale/dwRate (will break other things) or by using the same logic
as you suggest for ae_lavc - but then that IMO should not be duplicated
but go into some shared file.