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

Needed for enum AVCodecID

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

Do not error out if some subcomponents cannot be enabled.

Reported-By: RT|AO

Also fix #endif comments in the FFT init code.

The timebase change in the zmbv-8bit test is due to the fact that
previously the timebase string was evaluated as floating point, then
converted to a rational. After this commit, the timebase is passed
directly as is.

This should allow using more complex allocators than simple malloc
wrappers.

It makes more sense to not claim anything about the SAR if we don't know
anything. No changes in the FATE tests, since this is what avconv ends
up doing anyway.

Make sure that the minimum set of dependencies needed by the tools
and the examples are enabled.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

And make sure to enable all the components needed
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

An AVIO offset is int64_t.

Bug-Id: 921

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Today, we track the short term RPS size for DXVA, but only if the
SliceHeader RPS is being used. Otherwise it's left uninitialized.

NVIDIA's VDPAU implementation requires that the size be accurately
tracked even if an SPS RPS is being used. In this case, it's really
counting the size of the RPS idx information, but you end up with
mangled output if the value is not accurate.

VDPAU also needs the size of the long term RPS.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.

Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkviSigned-off-by: Rémi Denis-Courmont <remi@remlab.net>

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.