As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
When coding lossless jpeg the priv context will be pointing to LJpegEncContext
rather than MpegEncContext, which the function expects.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit '33a2b73b98374de4781ae0497cf74b2ce07a9615':
mpeg4audio: correctly propagate meaningful error values
This commit is a noop, see 50b1453915
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a91f1023bc06091ef84dce0f1e12b72d7f3ba3ca':
examples: fix a typo in an error message
This commit is a noop, see 3aa1ff30f3
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'cad42fadcd2c2ae1b3676bb398844a1f521a2d7b':
aarch64: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
This commit is a noop, see 8b11a89c06
Merged-by: Clément Bœsch <u@pkh.me>
* commit '9c8bc74c2b40537b0997f646c87c008042d788c2':
arm: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
This commit is a noop, see 388f6e6715
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3c87039a404c5659ae9bf7454a04e186532eb40b':
arm: vp9itxfm: Only reload the idct coeffs for the iadst_idct combination
This commit is a noop, see ecd343aa1f
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c4c5f5386c83bb8d66f8d67cd8533c8697f06d04':
vp9dsp: add DC only versions for idct/idct.
This commit is a noop, see 64821f5a7c
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e4382a4ab48138d43a19ea0da96f536a5e49b50c':
hevc: Eliminate pointless variable indirection
This commit is a noop, the code is different in FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0983f9117f31521643162cb85380672495a9de1b':
metasound: Drop unused tables
This commit is mostly a noop, see
276a8666d2e8319f602e
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8b56dbe7435d8cfe3964f447fc45fe98db5d9042':
configure: Do not add newlines in filter()/filter_out() functions
Merged-by: Clément Bœsch <u@pkh.me>
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>
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 8e2ea69135 and
096a8effa3 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>
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.