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>

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>

After this claim was made in e34e3619 kamedo2 did an in-depth ABX
test comparing these encoders:

https://hydrogenaud.io/index.php?topic=111085.0

Result: FFmpeg AAC wasn't as good as libfdk_aac on average.

I know some things have changed since then such as, "use the fast
coder as the default" (fcb681ac) for example, so maybe the situation
is different now.

However, I am unaware of any recent comparison. So without any
substantiation we shouldn't make such a blantant claim.
Signed-off-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>