On Fri, 17 Oct 2014, Tim Walker wrote:
On 15 Oct 2014, at 13:40, Martin Storsjö <[email protected]> wrote:
When downmixing multichannel streams, the decoder requires the output
buffer in aacDecoder_DecodeFrame call to be of fixed size in order to
hold the actual number of channels contained in the stream. For example,
for a 5.1ch to stereo downmix, the decoder requires that the output buffer
is allocated for 6 channels, regardless of the fact that the output is in
fact two channels.
Due to this requirement, the output buffer is allocated for the maximum
output buffer size in case a downmix is requested (and also during
decoder init). When a downmix is requested, the buffer used for output
during init will also be used for the entire duration the decoder is open.
Otherwise, the initial decoder output buffer is freed and a buffer large
enough only for the actual output size is used instead.
I'm having trouble following. Let's say we have a 5.1 source:
- during init, we allocate a buffer than can hold 6 channels' worth of
decoded data
Actually, this buffer only is allocated on the first decode_frame call,
not during init, and for non-downmix cases we free the temp buffer when
the first frame has been decoded successfully, but that's details
- if a downmix is requested, the 6-channel buffer allocated during init
gets used
- if no downmix is requested, the 6-channel buffer allocated during init
is freed and a buffer large enough only for the actual output size is
used, but, that would also be a 6-channel buffer, so what's the point of
not using the initial buffer?
It's not "a buffer large enough only for the actual output size", it's
"the output AVFrame" that is allocated once we know the exact number of
channels, vs a generic buffer allocated with av_malloc. The point in
not using the initial buffer is that we'd rather decode straight into
the AVFrame if possible, to avoid an extra memcpy.
I'm not sure if it's kosher to request e.g. a 6 channel AVFrame and then
just flip it to 2 channels after allocation - if it is, then we could of
course simplify that, but that is unrelated to this patch, this is what we
do already.
Does the commit message fail to mention we may have a "downmix" scenario
where the maximum number of channels is greater than the actual number
of channels (aka "upmix")?
I tested this, and the library won't upmix in this case
Does the commit message fail to mention another scenario not related to
the number of channels?
I don't know?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
