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

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

They are used by dnxhd and mpegvideo_enc exclusively, move them to codec
private options instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This returns something like "v12_dev0-1332-g333a27c". This is much more
useful than the individual library versions, of which there are too
many, and which are very hard to map back to releases or git commits.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

The audio decoder is not in fate-g2m3 dependencies and the wma2 decoder
is probably not bit-exact since it it float based.

EOVERFLOW is not available on all platforms.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This will fix remaining format warnings.

Fix warning from clang "absolute value function 'abs' given an argument
of type 'long long' but has parameter of type 'int' which may cause
truncation of value [-Wabsolute-value]".

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

ELS and ePIC decoder courtesy of Maxim Poliakovski,
cleanup and integration by Diego Biurrun.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Most of the fate-dds-* and fate-txd-* tests already
output into the same pixel format regardless of
platform endianness, so there's no need to force
conversion to another format.

This fixes the tests fate-txd-16bpp, fate-txd-odd,
fate-dds-rgb16, fate-dds-rgb24 and fate-dds-xrgb on
big endian, where the tests seem to fail due to issues
with certain conversion codepaths in swscale.

Those conversion codepaths should of course be fixed, but
the individual decoder tests should use as little extra
conversion steps as possible.
Signed-off-by: Martin Storsjö <martin@martin.st>

Partially based on code by Marton Balint and Kieran Kunhya.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

CC: libav-stable@libav.org
Found-By: ago@gentoo.org

Make sure to not write the custom `encoder` string in that case.

Bug-Id: 845
CC: libav-stable@libav.org

CC: libav-stable@libav.org

The container cropping is applied only when difference is within 16
pixels, and the smallest value between the two is chosen.

Bug-Id: 383
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

Bug-Id: CID 1308152

The old one is the result of the reverse engineering and guesswork.
The new one has been written following the now-available specification.

This work is part of Outreach Program for Women Summer 2014 activities
for the Libav project.

The fate references had to be changed because the old demuxer truncates
the last frame in some cases, the new one handles it properly.
The seek-test reference is changed because seeking works differently
in the new demuxer. When seeking, the packet is not read from the stream
directly, but it is rather constructed by the demuxer. That is why
position is -1 now in the reference.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Since it's truncated, the result depends on how specifically the demuxer
and the decoder handle errors.

Since it's truncated, the result depends on how specifically the demuxer
and the decoder handle errors.

Should fix a large number of possible races with frame threading.

Fixes possible invalid reads, once one of those refs is freed, but the
others remain.
CC: libav-stable@libav.org

We still want to flush the filters on EOF and possibly apply streamcopy.

This also ensures this is always done, avoiding infinite loops if an
error occurs at the end of the input.

Based on a patch by Michael Niedermayer <michaelni@gmx.at>.
CC: libav-stable@libav.org
Found-by: Kieran Kunhya <kierank@obe.tv>

Any other x265 symbol may not exported, e.g. if the build is a
multilib (10-bit and 8-bit in one) build.

This is the only symbol we directly call, and is available in the
build number we check for.

Fixes the configure check on multilib x265 builds.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>