Bump the API version requirement to 6.

Based on a patch by Agatha Hu <ahu@nvidia.com>.

Based on a patch by Agatha Hu <ahu@nvidia.com>.

For some unknown reason enabling these causes proper CBR padding,
so as there are no known downsides just always enable them in CBR mode.
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

Signed-off-by: NAnton Khirnov <anton@khirnov.net>

Based on a patch by Philip Langdale <philipl@overt.org>

Signed-off-by: NAnton Khirnov <anton@khirnov.net>

Signed-off-by: NDiego Biurrun <diego@biurrun.de>

This function copies the encoded bistream into the caller's packet,
calling it 'get_frame' is misleading.

An input frame always corresponds to exactly one output packet, so there
is no point in complicating the situation by managing them separately.

When there is a non-zero decoding delay due to reordering, the first dts
should be lower than the first pts (since the first packet fed to the
decoder does not produce any output).

Use the same scheme used in mpegvideo_enc (which comes from x264
originally) -- wait for first two timestamps and extrapolate linearly to
the past to produce the first dts value.

When B-frames are enabled and the encoder returns success, all currently
pending buffers immediately become valid and can be returned to the
caller. We can only return one packet at a time, so all the other
pending buffers should be transferred to a new 'ready' fifo, from where
they can be returned in subsequent calls (in which the encoder does not
produce any new output). This bug was hidden by the incorrect testing of
the encoder return value (the return value was overwritten before it was
tested).

Otherwise, closing the encoder can crash.

Return proper error codes and print more descriptive error messages.

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

Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Convert doxygen to multiline and express bitfields more simply.
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.

There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.

The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().

This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Partially based on the work of Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>