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>

Although it's not allowed to use only allows 'nclc' in ISOM files, there
are samples that do not always respect this rule. This change prevents
atom overread and a spurious color range initialization.

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

Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.

Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.

Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.

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

And use it in libavformat.

Based on a similar patch by Stefano Sabatini <stefasab@gmail.com>.

The strptime implementation is supposed to support whitespace and %T.

They are no longer initialized in ff_h264_decode_init() since 43fd3dd8,
so svq3 needs to initialize the manually.

Fixes svq3 decoding, broken since 43fd3dd8.

The previous documentation was very vague and almost misleading.

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The generic code copies the main context's private data to all the
others. However that is quite dangerous, as it might end up copying some
pointers that are or will become invalid.

Since everything we actually need will be copied later in
update_thread_context(), it's safest to zero the private data in
init_thread_copy(), so it works the same way as init for the main
context.

It will always be initialized when actually parsing the PPS.

There is no real advantage to initializing any of those in init,
assuming yuv420, before the real stream parameters are known.

This makes sure the various DSP contexts get properly initialized in
ff_h264_set_parameter_from_sps() whatever the value of
raw_bits_per_sample.

There is in general no reason for the currently active SPS to be the one
referenced by the PPS being parsed.

Bug-Id: CID 1292519

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

The way it is currently designed is fundamentally unsafe and cannot be
reasonably fixed without completely rewriting it.