While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder.  It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.

This improves behaviour with drivers which do not support packed
headers, such as AMD VCE on mesa/gallium.

This allows better checking of capabilities and will make it easier
to add more functionality later.

It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.

It is used to select functions that work with 9-15bits.

Make sure the scaling functions for the 9-15bits are used for
9-15bits bit depths correctly.

Follow a 420, 422, 444 order instead of a random one.
This simplifies double-checking additions of new formats.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

And use a macro to reduce the boilerplate.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This will make the x86 asm simpler.

ARM conversion by Martin Storsjö <martin@martin.st> and Janne Grunau
<janne-libav@jannau.net>

The x86 version processes 16 floats per iteration, so len must be a
multiple of 16.

It has no effect, since the code is supposed to operate the same way for
any bit depth.

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

Also change shl to add, since it can be faster on some CPUs.

CC: libav-stable@libav.org

This version, which is the only one doing two processing cycles per loop
iteration, computes the load/store indices incorrectly for the second
cycle.

CC: libav-stable@libav.org

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

It is supported by the NVIDIA video SDK 7.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Fix out of bounds read.

Bug-Id: 962
Found by: F4B3CD@STARLAB and Agostino Sarubbo
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Fixes an oversight in 1316df7a.

CC: libav-stable@libav.org

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

This was introduced in bc2a3296.

The whole block that the statement was added to is only
relevant when used as a demuxer, but the other statements
there have had other if statements guarding them. Make
sure to only run this whole block if being used as a
demuxer.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

If the input has been decoded from a stream which uses edge cropping
then the whole surface need not be valid.  This defines an input
region for the scaler so we only use the active area of the frame.

There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.

Also remove the redundant casts which were hiding the error here.