Signed-off-by: Marton Balint <cus@passwd.hu>

After adding field type management to the common yadif logic, we can
remove the duplicate copy of that logic from bwdif.

The bwdif filter can use common yadif frame management if we track
when a field is the first or last field in a sequence. While this
information is not used by yadif, the added benefit of removing the
duplicated frame management logic makes it worth tracking this state
in the common code.

We have a pattern of wrapping CUDA calls to print errors and
normalise return values that is used in a couple of places. To
avoid duplication and increase consistency, let's put the wrapper
implementation in a shared place and use it everywhere.

Affects:

* avcodec/cuviddec
* avcodec/nvdec
* avcodec/nvenc
* avfilter/vf_scale_cuda
* avfilter/vf_scale_npp
* avfilter/vf_thumbnail_cuda
* avfilter/vf_transpose_npp
* avfilter/vf_yadif_cuda

Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

The valid range is -255 to 255.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes #7538.

Internally in ISOBMFF the FLAC-in-ISOBMFF draft uses "fLaC"
as the identifier for FLACSampleEntry, and there seems to be no
MPEG-DASH specification for the in-manifest identifier for FLAC.

After testing the browsers' implementations, it seems like all of
the major browser vendors have decided to utilize the MIME type for
FLAC ("audio/flac") as the identifier. This change set leads to
that string being utilized for FLAC streams instead of the sample
entry identifier ("fLaC"), which is the default behavior.

Verified by auri_ on IRC to play with the major browsers.

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

Fixes: signed integer overflow: -1625810908 - 582229060 cannot be represented in type 'int'
Fixes: 10977/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SHORTEN_fuzzer-5732602018267136

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: 10972/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5707569640243200

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

Using the value of buffering frames inferred from the old level is
not a sensible approach when one wants to guess the level.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

profile_idc for level 1b should be 11, not 10.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Report by coverity
CID 1441165

Reverts some accidental change in commit e621b1ca.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>

It is not needed and may be uninitialized.

A fade out (usually at the end of a video) can easily start beyond
INT32_MAX (about 36 minutes).  Regression since d40dc641.

videotoolbox returns an already cropped stream which led to double
cropping. this issue was introduced with the refactor of the cropping
mechanism in commit 07596e45 for h264 and 000fb61a for HEVC.

to fix this we set the cropping of the frame and the output frame to 0.

Tested-by: ponpon
Fixes ticket #7544.

Signed-off-by: Jun Zhao <mypopydev@gmail.com>

fix ticket: 7527
check dirname before use it
refine webvtt code in the hls_delete_old_segments

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

Instead of using a combination of bitreader and -writer for copying data,
one can byte-align the (obsolete and removed) bitreader to improve performance.
With the right alignment one can even use memcpy. The right alignment
normally exists for CABAC and hence for H.265 in general.
For aligned data this reduced the time to copy the slicedata from
776520 decicycles to 33889 with 262144 runs and a 6.5mb/s H.264 video.
For unaligned data the number went down from 279196 to 97739 decicycles.
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Also add SIMD which works on lines because it is faster then calculating it on
8x8 blocks using pixelutils.
Signed-off-by: Marton Balint <cus@passwd.hu>

Instead of using a combination of bitreader and -writer for copying data,
one can byte-align the (obsolete and removed) bitreader to improve performance.
One can even use memcpy in the normal case.
This improved the time needed for writing the slicedata from 33618 to
2370 decicycles when tested on a video originating from a DVD (4194394
runs).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>