Bug-Id: CID 1295124

The FATE server does not report this information anyway and omitting
it makes the successful run send much less data.

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

Use direcly avio_w8().

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

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

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

This field is mandatory in dynamic manifests.

Signed-off-by: Martin Storsjö <martin@martin.st>

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

Bug-Id: CID 1267902
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

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

Signed-off-by: James Almer <jamrial@gmail.com>

ac may be NULL and then accessing ac->avctx results in a segmentation fault.

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

warning: incompatible
      pointer types assigning to 'me_cmp_func' (aka 'int (*)(struct
      MpegEncContext *, uint8_t *, uint8_t *, ptrdiff_t, int)') from 'int
      (MpegEncContext *, uint8_t *, uint8_t *, int, int)'
      [-Wincompatible-pointer-types]

Fix a rather lengthy initialization warning from clang.

nlvl_to and nlvl_from can be set to 1 if both alias and target files
are in the same directory, so actually check the first character of the
string. We can do this because MacOS filepaths (alis type 2) are always
converted to UNIX filepaths (alis type 18).

Absolute paths can be stored in alis type 2 and 18 according to my research:
the first is the canonical MacOS filepath, with path level separated by
colons, and the volume name within the filepath, while the second should be the
absolute filesystem path from the mount point.

Based on work by Kostya Shishkov <kostya.shishkov@gmail.com>.

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

Add some bounds checking to CLLC; reduce HQX variable scoping,
add an error message.

They belong to the same family of codecs.

Inspired by a patch from Ferdinand Oeinck <ferdo@demon.nl>.

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

In preparation for multithreaded decoding.

This applies to every library where performance is not critical.

And deprecate av_dlog macro.

CC: libav-stable@libav.org

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

The AVSC_API changes in the new headers mean that the 2.6 alphas
are just as incompatible as 2.5 is.

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

In order to safely exit when the user tries to use AviSynth 2.5, the
continue_on_fail value for 2.6's functions need to be set to 1.
Otherwise, the library loader fails before the 'upgrade to 2.6'
log message appears.

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

They seem to sometimes trigger with old AVI files. They are just
confusing, do not help anyone, and use sloppy language.

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

This is optional, but ensures that linking with -Wl,--as-needed does not
drop the library containing the MMAL VC driver. The driver normally
"registers" itself in the library constructor, but since no symbols are
explicitly referenced, the linker could remove it with --as-needed
enabled.

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

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

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

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Based on code from libavcodec/libx264.c

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

These headers can't be included in any arbitrary order.

Signed-off-by: Martin Storsjö <martin@martin.st>

Also reshuffle headers into canonical order where appropriate.

Handle error return from ff_listen_bind without leaking file descriptors.

Signed-off-by: Anders Nystrom <anders.nystrom@southpole.se>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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