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>

With fate test using the SLPPLP_A_VIDYO_2 conformance file, which contains
two sublayers with full PTL information.

In some situations it might be tab character and in others normal space.

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

move the variable declaration at start of upper for block and
remove the redundant brace.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>

They are come from 2003 and delete them.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>

Fixes: Out of memory
Fixes: 10970/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IMM4_fuzzer-5698750043914240
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

The first element of H264RedundantPPSContext is not a pointer to an
AVClass as required.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

After inspecting the source code of x265, mpv and ffmpeg, I've found that
ffmpeg mistakenly regards EVC_NAL_BLA_N_LP and HEVC_NAL_IDR_N_LP as non-
reference frames, which are acutally reference frames according to the
specification in x265, and drops them.

This patch should address the problem. I have tested it with mpv.
Signed-off-by: Mark Wu <wfwf1997@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Writes missing (delay) samples after EOF.
Signed-off-by: bnnm <bananaman255@gmail.com>

vp9 now supports [0, 6]
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.com>

enables temporal dependency model
Signed-off-by: James Zern <jzern@google.com>

report by coverity
CID 1439934
CID 1439935

This improves the speed of decoding large patches of constant color

Fixes: Timeout
Fixes: 10967/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5630803793936384

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

only 16b alpha is supported (not 8 bits)

following official encoder, alpha data doesn't impact
yuv plane quality.

So the alpha data encoding is done after the yuv part.
It's also avoid to loose quality in yuv part when
alpha is not uniform.

the alpha encoding funcs is mainly take from prores_ks
encoder, except for the alpha data reorganization