Change one relevant assert to av_assert0 while here.

Fixes timecode calculation for NTSC frame rates.
Fixes ticket #5978.

Added linux support for amf encoder through vulkan.

To use h.264(AMD VCE) encoder on linux amdgru-pro version 19.20+ and
amf-amdgpu-pro package(amdgru-pro contains, but does not install
automatically) are required.

This driver can be installed using amdgpu-pro-install script in
official amd driver archive.

Initialization of amf encoder occurs in this order:
1) trying to initialize through dx11(only windows)
2) trying to initialize through dx9(only windows)
3) trying to initialize through vulkan

Only Vulkan initialization available on linux.

It may be propagated only once for the entire stream.
Signed-off-by: James Almer <jamrial@gmail.com>

ff_reget_buffer() will attempt to create a writable copy of the frame,
which is not needed when the decoder intends to return a reference to
the same buffer as the previous frame.

Should reduce data copy, hopefully achieving a similar speed up as
a9dacdee without dropping frames.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

This reverts commit a9dacdee.

This patch effectively made the decoder output vfr content out of samples
where cfr is expected.

Addresses ticket #7880.
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: Infinite loop
Fixes: 16260/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ATRAC9_fuzzer-5676365617037312
Fixes: 16260/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ATRAC9_fuzzer-5768093879500800

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

The reference frame isn't valid after seeking
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes ticket #8093
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

This was a regression in 5fdcf85bSigned-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

wavelets allow significant size expansion and they are also not
very fast.

Fixes: Timeout
Fixes: 16480/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5659892689403904 (108sec -> 17ms)
Fixes: 16480/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5749422717140992 (big ->15sec)

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout (infinite)
Fixes: 16732/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-5642166377906176

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

Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 15764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5102101203517440

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

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

CID: 1452644
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

CID: 1452445
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

fix CID: 1426931
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Add the support of dehaze filter in existing derain filter source
code. As the processing procedure in FFmpeg is the same for current
derain and dehaze, we reuse the derain filter source code. The
model training and generation scripts are in repo
https://github.com/XueweiMeng/derain_filter.gitReviewed-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: Xuewei Meng <xwmeng96@gmail.com>

Missed in c180f0f6

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

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

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

It will be needed by the next commit.
Signed-off-by: James Almer <jamrial@gmail.com>

Try to seek to end of file and if signature is found seek backwards until
last valid chunk is found.

Try to find next valid chunk in offsets of 0x8000 from last good one.

vtctx->cached_hw_frames_ctx is unref'd in videotoolbox_uninit,
but videotoolbox_hevc used ff_videotoolbox_uninit which
doesn't unref cache_hw_frames_ctx.
Signed-off-by: Pavel Koshevoy <pkoshevoy@gmail.com>

See https://trac.ffmpeg.org/ticket/7687

If an encoded frame is returned split over two or more
IL buffers due to the size, then there is a race between
whether get_buffer will fail, return NULL, and a truncated
frame is passed on, or IL will return the remaining part
of the encoded frame.
If get_buffer returns NULL, part of the frame is left behind
in the codec, and will be collected on the next call. That
then leaves a frame stuck in the codec. Repeat enough times
and the codec FIFO is full, and the pipeline stalls.

A performance improvement in the Raspberry Pi firmware means
that the timing has changed, and now frequently drops into the
case where get_buffer returns NULL.

Add code such that should a buffer be received without
OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
set, so we wait for the remainder of the frame.
This code has been made conditional on the Pi build in case
other IL implementations don't handle ENDOFFRAME correctly.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Martin Storsjö <martin@martin.st>

fixes https://trac.ffmpeg.org/ticket/6586Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The packet counting based approach caused excessive sdt/pat/pmt for VBR, so
let's use a timestamp based approach instead similar to how we emit PCRs.
SDT/PAT/PMT period should be consistent for both VBR and CBR from now on.

Also change the type of sdt_period and pat_period to AV_OPT_TYPE_DURATION so no
floating point math is necessary.

Fixes ticket #3714.
Signed-off-by: Marton Balint <cus@passwd.hu>