Fixes: signed integer overflow: 1020048 * 4096 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5753877751660544

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: -2147483647 - 61436 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_IMA_APM_fuzzer-5092176004644864

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

The specs note that images should be in the GENERAL layout when exporting
for maximum compatibility.
CUDA exported images are handled differently, and the queue is the same,
so we don't need to do that there.

As it turns out, we were already assuming and treating all images as if they had
concurrent access mode. This just changes the flag to CONCURRENT, which has less
restrictions than EXCLUSIVE, and fixed validation messages on machines with
multiple queues.
The validation layer didn't pick this up because the machine I was testing on
had only a single queue.

Calling vkGetImageSubresourceLayout is only legal for linear and drm images.

This is a leftover from an old version which used the 1.0 Vulkan API
with the maintenance extensions being required.

This solves a huge oversight - it lets users reliably use their own
AVVulkanDeviceContext. Otherwise, the extensions supplied and enabled
are not discoverable by anything outside of hwcontext_vulkan.
Also clarifies that any user-supplied VkInstance must be at least 1.1.

Also documents all options supported by the hwdevice.
This lets users enable all extensions they need without writing their own
instance initialization code.

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>

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

For every variantstream vs, vs->packets_written is set to one, only to be
set to zero a few lines below. Given that the relevant structure has
been zeroed during the allocation, this commit removes both assignments.
A redundant initialization for vs->init_range_length has been removed as
well a few lines below. Given that the relevant structure has been
zeroed during the allocation, this commit removes both assignments. A
redundant initialization for vs->init_range_length has been removed as
well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

ff_format_io_close() already does it for us.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

By the av_strtok() description:
 * On the first call to av_strtok(), s should point to the string to
 * parse, and the value of saveptr is ignored. In subsequent calls, s
 * should be NULL, and saveptr should be unchanged since the previous
 * call.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

note it'll cause a small difference in accuracy for the pts, please see the testing result below:
 $ wget http://samples.ffmpeg.org/archive/all/unknown+unknown+unknown+unknown+5029_paramount_en_1250.viv
 $ ./ffmpeg -t 0.04 -i ./unknown+unknown+unknown+unknown+5029_paramount_en_1250.viv -f null -
 old:
 pts: 522
 pts: 1044
 pts: 1567
 pts: 3918
 pts: 8097
 pts: 12277
 pts: 16457
 ...

 new:
 pts: 522
 pts: 1045
 pts: 1567
 pts: 3918
 pts: 8098
 pts: 12278
 pts: 16457
 ...
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

This allows any phys_device derived to be used as a display rendering device.

Fixes: out of array access
Fixes: 20659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-5735812071424000

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

V4L2 api can indicate that flushing of the capture buffers is completed
by setting the V4L2_BUF_FLAG_LAST flag.
Use guards because the flag was only defined in Linux v4.2.

Reference:
linux/Documentation/media/uapi/v4l/dev-decoder.rst

    "The client must continue to handle both queues independently,
     similarly to normal decode operation. This includes:
     ...
     - queuing and dequeuing CAPTURE buffers, until a buffer marked with
       the V4L2_BUF_FLAG_LAST flag is dequeued"
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

v4l2_m2m devices may send an empty packet/frame while draining
to indicate that all capture buffers have been flushed.

Currently, the empty packet/frame is not handled correctly:
When encoding, the empty packet is forwarded to the muxer, usually
creating warnings.
When decoding, a reference to the memory is created anyway. Since in
the past this memory contained a decoded frame, it results in an extra
frame being decoded.

This commit discards the empty packet/frame.

References:
linux/Documentation/media/uapi/v4l/dev-decoder.rst:

    "The last buffer may be empty (with :c:type:`v4l2_buffer` bytesused = 0)
     and in that case it must be ignored by the client, as it does not
     contain a decoded frame."

linux/Documentation/media/uapi/media/v4l/vidioc-encoder-cmd.rst:

    "...This buffer may be empty, indicated by the
     driver setting the ``bytesused`` field to 0."
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

Regression since 4d9b9c5e
Fixes: Null pointer dereference
Fixes: 21642/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5670101358739456

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

The demuxer code assumes the existence of a video stream

Fixes: assertion failure
Fixes: 21512/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5699660783288320

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

Fixes: 8233/PPY6574574605_cut.mp3
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: 21089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5135981419429888
Fixes: out of array read

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

Fixes: Timeout (84sec -> 2sec)
Fixes: 21127/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5098412367413248

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: 21469/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5199357982015488

Alternatively the arrays can be made bigger or the index can be clipped.
In case a real file with such huge tiles exist we ask the user to upload it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: OOM
Fixes: 20774/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5678608951803904
Fixes: 20956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5713643025203200

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

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

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

Signed-off-by: David Manouchehri <david.manouchehri@riseup.net>

When the Ogg muxer writes a page, it has to do three things: It needs to
write a page header, then it has to actually copy the page data and then
it has to calculate and write a CRC checksum of both header as well as
data at a certain position in the page header.

To do this, the muxer used a dynamic buffer for both writing as well as
calculating the checksum via an AVIOContext's feature to automatically
calculate checksums on the data it writes. This entails an allocation of
an AVIOContext, of the opaque specific to dynamic buffers and of the
buffer itself (which may be reallocated multiple times) as well as
memcopying the data (first into the AVIOContext's small write buffer,
then into the dynamic buffer's big buffer).

This commit changes this: The page header is no longer written into a
dynamic buffer any more; instead the (small) page header is written into
a small buffer on the stack. The CRC is then calculated directly via
av_crc() on both the page header as well as the page data. Then both the
page header and the page data are written.

Finally, ogg_write_page() can now no longer fail, so it has been
modified to return nothing; this also fixed a bug in the only caller of
this function: It didn't check the return value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>