Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

or if x/y go beyond padded area.

This is mostly useful when paired with the aspect option.
Defaults aren't changed.

Idea for this was taken from mpv's soon-to-be-removed expand vf.
Reviewed-by: Paul B Mahol <onemda@gmail.com>

It was addressed in b8f26779

While they shouldn't be present, they are harmless if they are.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

This merges commits 8e2ea691 and
096a8eff by Anton Khirnov, with the
following change:

- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.

The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

The av_log() is done outside the lock, but this way the accesses to the
field (reads and writes) are always protected by a mutex. The av_log()
is not run inside the lock context because it may involve user callbacks
and doing that in performance-sensitive code is probably not a good idea.

This should fix occasional tsan warnings when running fate-h264, like:

WARNING: ThreadSanitizer: data race (pid=10916)
  Write of size 4 at 0x7d64000174fc by main thread (mutexes: write M2313):
    #0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000df7b06)
[..]
  Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write M2311):
    #0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592 (ffmpeg+0x000000df8b3e)

I'm hoping that this will address the remaining tsan fate-h264 issues:

WARNING: ThreadSanitizer: data race (pid=24478)
  Read of size 8 at 0x7dbc0001c828 by main thread (mutexes: write M3243):
    #0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x0000013b78d8)
[..]
  Previous write of size 1 at 0x7dbc0001c82e by thread T2 (mutexes: write M3245):
    #0 ff_h264_direct_ref_list_init src/libavcodec/h264_direct.c:137 (ffmpeg+0x000001382c93)

But I'm not sure because I haven't been able to reproduce locally.

Fix decoding frame.jpg from ticket #267

Regression since 9c7ee374 / 212c6a1d

This fixes assertion failures introduced in 4fbb56ac.

Reviewed-by: michaelni
Reviewed-by: durandal_1707

Fixes: integer overflows
Fixes: 911/clusterfuzz-testcase-5415105606975488

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegReviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '212c6a1d':
  mjpegdec: Check return values of functions that may fail
Merged-by: Clément Bœsch <u@pkh.me>

* commit '3ee5f25d':
  dxva2: Adjust printf length modifiers where appropriate
Merged-by: Clément Bœsch <u@pkh.me>

* commit '239d02ef':
  avisynth: Cast to the right type when loading avisynth library functions

This commit is a noop, we are using dlsym() instead of GetProcAdress().
Merged-by: Clément Bœsch <u@pkh.me>

* commit '3fe2a01d':
  lavc: move decoding-related code from utils.c to a new file
Merged-by: James Almer <jamrial@gmail.com>

* commit '328cd2b5':
  lavc: move encoding-related code from utils.c to a new file
Merged-by: James Almer <jamrial@gmail.com>

* commit '45d199d5':
  aac_adtstoasc_bsf: validate and forward extradata if the stream is already ASC

This commit is a noop, see 6e1902baMerged-by: James Almer <jamrial@gmail.com>

* commit '1762a39e':
  mss2: only use error correction for matching block counts

This commit is a noop, see 2566ad98Merged-by: James Almer <jamrial@gmail.com>

* commit 'd0c84c41':
  avconv: Fix the audio next dts computation

This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>

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

* commit 'eb135516':
  ac3enc: Avoid unnecessary macro indirections

This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>

* commit 'f0d3e43b':
  ac3enc: Reshuffle functions to avoid forward declarations
Merged-by: James Almer <jamrial@gmail.com>

* commit 'e22c63ac':
  ac3enc: Reshuffle some float/fixed-mode ifdefs to avoid a dummy function
Merged-by: James Almer <jamrial@gmail.com>

* commit 'd30719e6':
  hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size pool

This commit is a noop, see 2b8151c8Merged-by: James Almer <jamrial@gmail.com>

* commit '4adbb44a':
  tta: avoid undefined shifts
Merged-by: James Almer <jamrial@gmail.com>

* commit 'dc4b6250':
  tta: use get_unary() instead of a custom implementation

This commit is a noop, see 58b36959Merged-by: James Almer <jamrial@gmail.com>

* commit 'e122b12c':
  build: Drop gcrypt support

This commit is a noop. GCrypt support is exposed in configure as a
command line option, and it's independent of GnuTLS.
Merged-by: James Almer <jamrial@gmail.com>

avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'

Fixes: 619/clusterfuzz-testcase-5803914534322176

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

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is assigned from 64bit input in some branches and used with 64bit timestamps
This thus fixes a potential integer truncation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Consider the following sequence of events:

- open a codec without AV_CODEC_CAP_DELAY
- decode call fails with an error
- ff_thread_flush() is called
- drain packet is sent

Then the last step would make ff_thread_decode_frame() return an error,
because p->result can still be set to an error value. This is because
submit_packet returns immediately if AV_CODEC_CAP_DELAY is not set, and
no worker thread gets the chance to reset p->result, yet its value is
trusted by ff_thread_decode_frame().

Fix this by clearing the error fields on flush.

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

These data are necessary when transmitting HDR over HDMI.
Signed-off-by: James Almer <jamrial@gmail.com>

As found in HEVC.
Signed-off-by: James Almer <jamrial@gmail.com>