Use only proper AVFrame API (no assigning of whole frames, since that
hardcodes sizeof(AVFrame) into lavc).

Make a copy of the side data, so the caller can use av_frame_unref/free
on non-refcounted frames, eliminating the need for
avcodec_get_frame_defaults()/avcodec_free_frame().

Not just on failure. This is the same thing that is done in the audio
path and should prevent leaks in decoders that allocate a frame, but
then end up not writing into it.

av_frame_unref() works fine on unallocated frames.

data[0] may be NULL for valid frames with hwaccel pixel formats.

All decoders should now handle it properly.

It is always called by passing fields from an AVCodecContext.

It's a private field, not meant to be accessed from outside lavc.

It's a private field, it should not be visible to callers.

Deprecate AVCodecContext.thread_opaque

avcodec_set_dimensions() is supposed to be an internal utility function,
there is no reason whatsoever for it to be public. Therefore deprecate
it.

Used by LXF.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The to_free AVframe must be freed just like the other ones.
Indeed, the calling application may expect all frames to be
released.

(This regression caused use-after-free in VLC with hwaccel.)

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This also simplifies the code.

Those were useful when avcodec_thread_init() was a public functions. It
was deprecated and removed some time ago, so those checks are not needed
anymore.

This fixes https://bugzilla.libav.org/show_bug.cgi?id=514.

Signed-off-by: Martin Storsjö <martin@martin.st>

Notwithstanding the return value the frame should be freed if
is not going to be used.

Reported-by: Matthew Wolenetz <wolenetz@chromium.org>

Otherwise some code might mistakenly think it is allowed to unref those
buffers, which would lead to double unref.

Needed e.g. for h264 cropping to work properly.

Signed-off-by: Martin Storsjö <martin@martin.st>

Since c977039e58 plane count for
PIX_FMT_HWACCEL pixel formats is 0 instead of 1. The created dummy
AVBuffers are still bogus since AVFrame does not hold frame data when
AVHWAccels are used.

Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows dropping the mpegvideo dependency from a number of
components.

This also fixes standalone building of the h264 parser, which
was broken in 64e438697.

Signed-off-by: Martin Storsjö <martin@martin.st>

Number of planes is not always equal to the number of components even
for formats marked with PIX_FMT_PLANAR -- e.g. NV12 has three components
in two planes.

It is supposed to be height * linesize, not width * linesize.
Thanks to Hendrik Leppkes for pointing out the bug.

This allows reporting missing features and requesting samples from
all libraries in a standard way; with a simplified API.

AVCodecContext release_buffer() shall be NULL for audio codecs using
get_buffer. The backward compatibility code hence have to check before
calling it.

planes - FF_ARRAY_ELEMS would be evaluated as unsigned and underflow
instead of being negative as was intended.

Fixes build without threads after
759001c534.

This should ensure that a valid channel layout is always set on a frame,
until a better solution is implemented.

This will allow us to avoid copying the packets in many cases.

This breaks ABI.

Make sure the behavior does not change with the locale.

Signed-off-by: Martin Storsjö <martin@martin.st>

Make av_get_codec_tag_string() show codec tag string characters in a more
intelligible ways. For example the ascii char "@" is used as a number, so
should be displayed like "[64]" rather than as a printable character.

Apart alphanumeric chars, only the characters ' ' and '.' are used
literally in codec tags, all the other characters represent numbers.

This also avoids relying on locale-dependent character class functions.

Signed-off-by: Martin Storsjö <martin@martin.st>

There may be more decoders that rely on this. Those should be found and
fixed.