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: NLuca Barbato <lu_zero@gentoo.org>

ELS and ePIC decoder courtesy of Maxim Poliakovski,
cleanup and integration by Diego Biurrun.
Signed-off-by: NDiego Biurrun <diego@biurrun.de>
Signed-off-by: NLuca 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: NMartin Storsjö <martin@martin.st>

Partially based on code by Marton Balint and Kieran Kunhya.
Signed-off-by: NVittorio 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: NVittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: NLuca 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: NAnton 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: NKieran 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: NDerek Buitenhuis <derek.buitenhuis@gmail.com>

get_bits should not be used with more than 25 bits.
Signed-off-by: NAndreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>

Found-By: NMichael Niedermayer <michaelni@gmx.at>
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: NPaul B Mahol <onemda@gmail.com>