The mp_audio_from_avframe() function requires the AVFrame to be
refcounted, and merely increases its refcount while referencing the same
data. For non-refcounted frames, it simply did nothing and potentially
would make the caller pass around a frame with dangling pointers.
(libavcodec should always return refcounted frames, but it's not clear
what other code does; and also the function should simply work, instead
of having weird requirements on its arguments.)
A helper to allocate refcounted audio frames from a pool. This will
replace the static buffer many audio filters use (af->data), because
such static buffers are incompatible with refcounting.
A first step towards refcounted audio frames.
Amazingly, the API just does what we want, and the code becomes
simpler. We will need to NIH allocation from a pool, though.
In most places where af_fmt2bits is called to get the bits/sample, the
result is immediately converted to bytes/sample. Avoid this by getting
bytes/sample directly by introducing af_fmt2bps.
This avoids too many realloc() calls if the caller is appending to an
audo buffer. This case is actually quite noticeable when using something
that buffers a large amount of audio.
This includes the case when lavc decodes audio with more than 8
channels, which our audio chain currently does not support.
the changes in ad_lavc.c are just simplifications. The code tried to
avoid overriding global parameters if it found something invalid, but
that is not needed anymore.
libav* is generally freaking horrible, and might do bad things if the
data pointer passed to it are not aligned. One way to be sure that the
alignment is correct is allocating all pointers using av_malloc().
It's possible that this is not needed at all, though. For now it might
be better to keep this, since the mp_audio code is intended to replace
another buffer in dec_audio.c, which is currently av_malloc() allocated.
The original reason why this uses av_malloc() is apparently because
libavcodec used to directly encode into mplayer buffers, which is not
the case anymore, and thus (probably) doesn't make sense anymore.
(The commit subject uses the word "cargo cult", after all.)
Based on earlier work by Stefano Pigozzi.
There are 2 changes:
1. Instead of mp_audio.audio, mp_audio.planes[0] must be used.
2. mp_audio.len used to contain the size of the audio in bytes. Now
mp_audio.samples must be used. (Where 1 sample is the smallest unit
of audio that covers all channels.)
Also, some filters need changes to reject non-interleaved formats
properly.
Nothing uses the non-interleaved features yet, but this is needed so
that things don't just break when doing so.
The point is selecting a minimal fallback. The AOs will call this
through the AO API, so it will be possible to add options affecting
the general channel layout selection.
It provides the following mechanism to AOs:
- forcing the correct channel order
- downmixing to stereo if no layout is available
- allow 5.1 <-> 5.1(side) fallback
- handling "unknown" channel layouts
This is quite weak and lots of code/complexity for little gain. All AOs
already made sure the channel order was correct, and the fallback is of
little value, and could perhaps be done in the frontend instead, like
stereo downmixing with --channels=2 is handled. But I'm not really sure
how this stuff should _really_ work, and the new code will hopefully
provides enough flexibility to make radical changes to channel layout
negotiation easier.
mp_audio has some redundant fields. Setters like mp_audio_set_format()
initialize these properly.
Also move the mp_audio struct to a the file audio.c.
We can remove a mysterious line of code from af.c:
in.format |= af_bits2fmt(in.bps * 8);
I'm not sure if this was ever actually needed, or if it was some kind of
"make it work" quick-fix that works against the way things were supposed
to work. All filters etc. now set the format correctly, so if there ever
was a need for this code, it's definitely gone.
