> In file included from src/decoder/DecoderBuffer.cxx:21:0:
> src/decoder/DecoderBuffer.hxx:41:20: error: 'uint8_t' was not declared in this scope
>   DynamicFifoBuffer<uint8_t> buffer;
>                     ^
> src/decoder/DecoderBuffer.hxx:41:27: error: template argument 1 is invalid
>   DynamicFifoBuffer<uint8_t> buffer;
>                            ^
> src/decoder/DecoderBuffer.hxx: In member function 'void DecoderBuffer::Clear()':
> src/decoder/DecoderBuffer.hxx:61:10: error: request for member 'Clear' in '((DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'int'
>    buffer.Clear();
>           ^
> src/decoder/DecoderBuffer.hxx: In member function 'size_t DecoderBuffer::GetAvailable() const':
> src/decoder/DecoderBuffer.hxx:78:17: error: request for member 'GetAvailable' in '((const DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'const int'
>    return buffer.GetAvailable();
>                  ^
> src/decoder/DecoderBuffer.hxx: In member function 'ConstBuffer<void> DecoderBuffer::Read() const':
> src/decoder/DecoderBuffer.hxx:87:19: error: request for member 'Read' in '((const DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'const int'
>    auto r = buffer.Read();
>                    ^
> src/decoder/DecoderBuffer.hxx:88:27: error: could not convert '{<expression error>, <expression error>}' from '<brace-enclosed initializer list>' to 'ConstBuffer<void>'
>    return { r.data, r.size };
>                            ^
> src/decoder/DecoderBuffer.hxx: In member function 'void DecoderBuffer::Consume(size_t)':
> src/decoder/DecoderBuffer.hxx:105:10: error: request for member 'Consume' in '((DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'int'
>    buffer.Consume(nbytes);
>           ^

This seems to be caused by a lacking include, fixed by the below patch.

I'm unsure what made this appear now, though, compiler and toolchain
libraries seem to be the same upstream versions that built 0.19.14-1
just fine in late March.

Required for OpusTags packets which contain artwork.

See https://bugs.musicpd.org/view.php?id=4520

Reduce some overhead.  It is not necessary to copy the object.

av_free_packet() was deprecated in FFmpeg 3.0.

Adds support for stream codecs which havn't been explicitly listed in
ffmpeg_mime_types.

Fixes http://bugs.musicpd.org/view.php?id=4432

Allocate the buffer dynamically using av_malloc(), and free
AVIOContext.buffer in the destructor, as mandated by the libavformat
documentation.

Fixes http://bugs.musicpd.org/view.php?id=4446

Eliminates some duplicate code, and as a side effect, this works
around clang 3.8 compiler warning because a negative value was
shifted.

If there's a stream tag, don't let the song tag override it in the
next update_stream_tag() call.

If the song tag comes from a stream, and MPD playback restarts, MPD
would believe the tag should override the newly received tag.  This
makes the previous tag appear stuck.  This change passes the song tag
only if it's authoritative - i.e. if it's a song file.

Reduce runtime overhead.

When seeking to the beginning of a packet, skip the samples that come
before the desired time stamp.

Ask FFmpeg to seek to the next packet boundary *before* the seek
position, so we don't miss audio data.  Now we get too much, but we'll
solve that in the next commit.

Don't abort the process if there's not enough memory.  This buffer is
not important and can be large.

Merge two free() calls.

A bug report was submitted with a 600 kB ID3 tag that could not be
read by MPD.

Here's a change to dynamically allocate the DSD ID3 tag buffer.
Pretty much anything with cover art is going to exceed the existing,
static 4k limit...  Here's a change to dynamically allocate the buffer
and sanity check it at some upper limit.  I rather arbitrarily pulled
256k out of thin air just to keep a corrupt file from causing it to
trying to allocate a buffer larger than available memory.

Works around assertion failure due to something that appears to be a
(minor) FFmpeg bug.

Version 2.5 fixed an API oddity, however it broke API compatibility,
at least with C++.  Disable the workaround when a libavformat version
is detected that is recent enough.

libmp4v2 is licensed under MPL 1.1, which is incompatible with GPLv2.
Unfortunately, this means that we must remove the plugin.

More information can be found in the Debian bug report:

 http://bugs.debian.org/767504

Check opus_decoder!=nullptr instead.