Based on code from the BMP parser.

Addresses ticket #8574
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: left shift of negative value -14336
Fixes: 20298/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5675484201615360

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout
Fixes: out of array access
Fixes: 20274/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5649631988154368
Fixes: 19275/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5757535722405888

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 2145417478 + 76702564 cannot be represented in type 'int'
Fixes: 20313/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RA_144_fuzzer-5734487724130304

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Previously, there was no way to flush an encoder such that after
draining, the encoder could be used again. We generally suggested
that clients teardown and replace the encoder instance in these
situations. However, for at least some hardware encoders, the cost of
this tear down/replace cycle is very high, which can get in the way of
some use-cases - for example: segmented encoding with nvenc.

To help address that use case, we added support for calling
avcodec_flush_buffers() to nvenc and things worked in practice,
although it was not clearly documented as to whether this should work
or not. There was only one previous example of an encoder implementing
the flush callback (audiotoolboxenc) and it's unclear if that was
intentional or not. However, it was clear that calling
avocdec_flush_buffers() on any other encoder would leave the encoder in
an undefined state, and that's not great.

As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.

I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.

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

This copies the behaviour of the libopenjpeg decoder.
Fixes ticket #5919.

Fixes ticket #8612.

This generates a potential memory leak, and mixes side data from the last
packet with other properties from the first.

Keep all the properties from the first packet only in the output packet
instead.
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: index 224 out of bounds for type 'uint8_t [224]'
Fixes: 21534/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-6291612167831552

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: out of array access
Fixes: 21515/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5766121576988672

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.

This fixes Trac #8073

Fixes ticket #8607.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>

There should have language in the metadata of streams which show to user
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

add option for resend init file after m3u8 refresh everytime.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

When flushing the capture buffers, the driver may send a V4L2_EVENT_EOS
to notify that draining is completed. Currently, v4l2_m2m does not
subscribe to this event, which can cause some devices (i.e. imx8qm) to
hang at the end of encoding/decoding. Support for handling the event is
added in this commit.

Some devices may not signal V4L2_EVENT_EOS. This is logged as a warning
message during initialization and not treated as a fatal error.
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

The only difference of the currently used write_packet()-function to
ff_raw_write_packet() is that the former also counts the number of
frames. Yet doing so in the muxer itself is unnecessary as this is
already done generically in write_packet() in libavformat/mux.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

as has happened with flac_picture.o and the Matroska demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

These muxers don't depend on the WebM Chunk or the WebM DASH Manifest
muxers.

Furthermore, remove some #if checks in webm_chunk.c and webmdashenc.c.
They are always true now that webm_chunk.c and webmdashenc.c are only
compiled when their corresponding muxers are enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

It does not use anything from libavformat/matroska.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

avio_internal.h has been included in this muxer since the beginning and
was never needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

libavutil/avstring.h is unnecessary since 8a632b3e. The other
unnecessary headers were never used.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The webm_chunk muxer requires the WebM muxer, yet it does not directly
require anything from libavformat/matroska.c (it does not even include
the corresponding header). So remove the dependency from the Makefile
and add a _select to configure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

When QSV is enabled in FFmpeg, the command "ffmpeg -hwaccels" shows a
duplicate entry in acceleration methods for QSV:

Hardware acceleration methods:
vaapi
qsv
drm
opencl
qsv
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

This has happened when writing chapters: Both editions as well as
chapters are by default not hidden and given that we don't support
writing hidden chapters at all, we don't need to write said elements at
all. The same goes for ChapterFlagEnabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

Commit 9842fd3a stopped guessing colr
values.
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

The mdcv atom isn't in ISO/IEC 14496-12:2015 but it is expected to be
added soon. See:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html

The mdcv atom is already parsed in FFmpeg in mov.c.
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

The clli atom is expected to be standardized soon. See
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259529.html

We now write the clli atom by default.
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

The switch cases were missing:

  - Primaries: bt470m, film, smpte428, and ebu3213.
  - TRCs: gamma22, gamma28, linear, log, log_sqrt, iec61966_2_4, bt1361,
    iec61966_2_1, bt2020_10bit, and bt2020_12bit.
  - Space: rgb, fcc, ycgco, bt2020_cl, smpte2085, chroma-derived-nc,
    chroma-derived-c, and ictcp.

They also annoyingly remapped the following (which are functionally
equivalent but can be treated differently by clients):

  - smpte240m primaries to smpte170m.
  - smpte170m TRC to bt709.
  - bt470bg color space to smpte170m.

The enum values in FFmpeg are the same values as ITU-T H.273 and
ISO/IEC 23001-8 so we can just use them directly, which is both simpler
and preserves the user intent.
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi

Failure reported in:
http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-randomSigned-off-by: Linjie Fu <linjie.fu@intel.com>

Up until now, mkv_write_track() received the index of the stream whose
header data it is about to write as parameter; this index has until
recently been explicitly used to generate both TrackNumber and TrackUID.
But this is no longer so and as there is no reason why the function
for writing a single TrackEntry should even know the index of the
TrackEntry it is about to write, said index is replaced in the list of
function parameters by the corresponding AVStream and mkv_track.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>