Instead, hardcode the use of the _arm implementation of add_pixels,
and use the C version for put_pixels (as no arm-optimized version
exists). Since there's separate implementations of idct{,_put,_add}
for neon, this has no practical impact on performance.
This tries to handle cases where separate invocations of decode_frame()
(each running in separate threads) write to respective fields in the
same AVFrame->data[]. Having per-field owners makes interaction between
readers (the referencing thread) and writers (the decoding thread)
slightly more optimal if both accesses are field-based, since they will
use the respective producer's thread objects (mutex/cond) instead of
sharing the thread objects of the first field's producer.
In practice, this fixes the following tsan-warning in fate-h264:
WARNING: ThreadSanitizer: data race (pid=21615)
Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes: write M1006):
#0 ff_thread_report_progress pthread_frame.c:569 (ffmpeg:x86_64+0x100f7cf54)
[..]
Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes: write M1004):
#0 update_context_from_user pthread_frame.c:335 (ffmpeg:x86_64+0x100f81abb)
Fixes the following tsan warning when running fate-vsynth_lena-ffvhuff:
WARNING: ThreadSanitizer: data race (pid=6484)
Write of size 8 at 0x7d64000154b8 by main thread (mutexes: write M1331):
#0 update_context_from_user src/libavcodec/pthread_frame.c:331 (ffmpeg+0x000000dca887)
[..]
Previous read of size 8 at 0x7d64000154b8 by thread T2 (mutexes: write M1334):
#0 draw_slice src/libavcodec/huffyuvdec.c:857 (ffmpeg+0x000000bcc86f)
Add a codec capable of decoding some formats of the RFC4175. For now
it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth.
For 8-bit it's a simple pass-through, for 10-bit it depacks the stream
in the AV_PIX_FMT_YUV422P10 pixel format.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Fixes tsan warnings in fate-apng:
WARNING: ThreadSanitizer: data race (pid=51230)
Read of size 4 at 0x7d50000042fc by main thread (mutexes: write M1000):
#0 frame_copy_props frame.c:302 (ffmpeg:x86_64+0x1019a35d6)
[..]
Previous write of size 4 at 0x7d50000042fc by thread T1 (mutexes: write M997):
#0 decode_idat_chunk pngdec.c:708 (ffmpeg:x86_64+0x100f5562a)
* commit 'a1d9de304fe63614e3aa8117fef17491fa80093d':
Fix some mismatches between function parameter and doxygen parameter names.
Merged-by: Clément Bœsch <u@pkh.me>
Fixes a reported (but false) race condition in tsan for fate-apng:
WARNING: ThreadSanitizer: data race (pid=6274)
Read of size 4 at 0x7d680001ec78 by main thread (mutexes: write M1338):
#0 update_thread_context src/libavcodec/pngdec.c:1456 (ffmpeg+0x000000dacf0c)
[..]
Previous write of size 4 at 0x7d680001ec78 by thread T1 (mutexes: write M1335):
#0 decode_idat_chunk src/libavcodec/pngdec.c:737 (ffmpeg+0x000000dae951)
Values from subsequent values are guaranteed to be identical (since
poc and nal_unit_type are checked to be the same between slices), so
this doesn't affect output in any way, but does resolve the remaining
reported race conditions (by tsan) in fate-hevc.
In practice, this fixes tsan warnings like this:
WARNING: ThreadSanitizer: data race (pid=25334)
Read of size 4 at 0x7d9c0001adcc by main thread (mutexes: write M1386):
#0 hevc_update_thread_context src/libavcodec/hevcdec.c:3310 (ffmpeg+0x000000b41c7c)
[..]
Previous write of size 4 at 0x7d9c0001adcc by thread T1 (mutexes: write M1383):
#0 hls_slice_header src/libavcodec/hevcdec.c:596 (ffmpeg+0x000000b43a22)
Otherwise the thread may still be in the middle of decoding a previous
frame, which would effectively trigger a race condition on any field
concurrently read and written.
In practice, this fixes tsan warnings like the following:
WARNING: ThreadSanitizer: data race (pid=17380)
Write of size 4 at 0x7d64000160fc by main thread:
#0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000dca515)
[..]
Previous read of size 4 at 0x7d64000160fc by thread T2 (mutexes: write M1821):
#0 ff_thread_report_progress src/libavcodec/pthread_frame.c:565 (ffmpeg+0x000000dcb08a)
Fixes tsan warnings in several audio codecs (flac, alac, wavpack, tta
and tak) that look like this:
WARNING: ThreadSanitizer: data race (pid=14340)
Read of size 4 at 0x7d64000169d8 by main thread (mutexes: write M1335):
#0 update_context_from_thread src/libavcodec/pthread_frame.c:284 (ffmpeg+0x000000dc795f)
[..]
Previous write of size 4 at 0x7d64000169d8 by thread T1 (mutexes: write M1333):
#0 wavpack_decode_block src/libavcodec/wavpack.c:1012 (ffmpeg+0x00000112b175)
This is how the ref list manager links bitstream IDs to H264Picture/Ref
objects, and is local to the producer thread. There is no need for the
consumer thread to know the bitstream IDs of its references in their
respective producer threads.
In practice, this fixes tsan warnings when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=19295)
Read of size 4 at 0x7dbc0000e614 by main thread (mutexes: write M1914):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:112 (ffmpeg+0x0000013b3709)
[..]
Previous write of size 4 at 0x7dbc0000e614 by thread T2 (mutexes: write M1917):
#0 build_def_list src/libavcodec/h264_refs.c:91 (ffmpeg+0x0000013b46cf)
* commit '182cf170a544bce069c8690c90b49381150a1f10':
vp8: Return stream format information from parser
Return codes are adjusted to consume the whole packet in case of error
as the API does not allow returning AVERROR codes (a negative return
value is valid).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b6582b29277e00e5d49f400e58beefa5a21d83b8':
qsv: Add VC-1 decoder
See fb57bc6c34.
Merged for cosmetic purposes to reduce differences with libav.
Merged-by: James Almer <jamrial@gmail.com>
* commit '0940b748bdba36c4894fc8ea6be631d821fdf578':
qsvdec: Only warn about unconsumed data if it happens more than once
Merged-by: James Almer <jamrial@gmail.com>
* commit '3b50dbc51fb0978d09c1a5b83d4bf5a59d170e1e':
ratecontrol: Use correct function pointer casts instead of void*
Merged-by: James Almer <jamrial@gmail.com>
* commit '72a19f4013ec2c7f8581416f8ad4bf81df163fb6':
mpegaudiodsp: aarch64: Adjust function prototype after 2caa93b813
Merged-by: James Almer <jamrial@gmail.com>
The value must be identical between slices, since mbaff depends on
picture_structure and sps, both of which are checked to be identical
to the first slice before this point.
In practice, this silences some tsan warnings in fate-h264.
This fixes race conditions reported by tsan in fate-lagarith. The races
were because each thread's LagarithContext::avctx was set to the first
thread's AVCodecContext.
