aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/pthread_frame.c
Commit message (Collapse)AuthorAgeFilesLines
* lavc/pthread: use THREAD_SAFE_CALLBACKS() to simplifx more codeJun Zhao2018-08-311-4/+2
| | | | | | use THREAD_SAFE_CALLBACKS() to simplifx more code Signed-off-by: Jun Zhao <mypopydev@gmail.com>
* avcodec: remove unnecessary calls to ff_init_buffer_info()James Almer2018-02-141-2/+0
| | | | | | | | And remove the function altogether while at it. It's a duplicate of another. Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* w32pthreads: always use Vista+ API, drop XP supportwm42017-12-261-4/+0
| | | | | | | | | | | This removes the XP compatibility code, and switches entirely to SWR locks, which are available starting at Windows Vista. This removes CRITICAL_SECTION use, which allows us to add PTHREAD_MUTEX_INITIALIZER, which will be useful later. Windows XP is hereby not a supported build target anymore. It was decided in a project vote that this is OK.
* avcodec/pthread_frame: remove usage of AVCodecContext accessorsJames Almer2017-11-151-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* Merge commit '5182a28b5de060c51c21b36053ab205bfbbbbe31'James Almer2017-10-231-5/+0
|\ | | | | | | | | | | | | * commit '5182a28b5de060c51c21b36053ab205bfbbbbe31': lavc: Drop deprecated global afd field Merged-by: James Almer <jamrial@gmail.com>
| * lavc: Drop deprecated global afd fieldVittorio Giovara2017-03-231-5/+0
| | | | | | | | Deprecated in 08/2014.
| * lavc: Add hwaccel_flags field to AVCodecContextwm42017-03-201-0/+2
| | | | | | | | | | | | | | | | This "reuses" the flags introduced for the av_vdpau_bind_context() API function, and makes them available to all hwaccels. This does not affect the current vdpau API, as av_vdpau_bind_context() should obviously override the AVCodecContext.hwaccel_flags flags for the sake of compatibility.
| * pthread_frame: do not run hwaccel decoding asynchronously unless it's safeAnton Khirnov2016-12-191-6/+46
| | | | | | | | | | | | | | | | | | | | Certain hardware decoding APIs are not guaranteed to be thread-safe, so having the user access decoded hardware surfaces while the decoder is running in another thread can cause failures (this is mainly known to happen with DXVA2). For such hwaccels, only allow the decoding thread to run while the user is inside a lavc decode call (avcodec_send_packet/receive_frame).
| * pthread_frame: ensure the threads don't run simultaneously with hwaccelAnton Khirnov2016-12-191-0/+35
| |
| * pthread_frame: use better memory orders for frame progressWan-Teh Chang2016-12-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0. In ff_thread_report_progress(), the fast code path can load progress[field] with the relaxed memory order, and the slow code path can store progress[field] with the release memory order. These changes are mainly intended to avoid confusion when one inspects the source code. They are unlikely to have measurable performance improvement. ff_thread_report_progress() and ff_thread_await_progress() form a pair. ff_thread_await_progress() reads progress[field] with the acquire memory order (in the fast code path). Therefore, one expects to see ff_thread_report_progress() write progress[field] with the matching release memory order. In the fast code path in ff_thread_report_progress(), the atomic load of progress[field] doesn't need the acquire memory order because the calling thread is trying to make the data it just decoded visible to the other threads, rather than trying to read the data decoded by other threads. In ff_thread_get_buffer(), initialize progress[0] and progress[1] using atomic_init(). Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
* | avcodec: add missing FF_API_DEBUG_MV wrappersJames Almer2017-08-251-0/+2
| | | | | | | | Signed-off-by: James Almer <jamrial@gmail.com>
* | pthread_frame: revert 2e664b9c1e73c80aab91070c1eb7676f04bdd12d.Wan-Teh Chang2017-07-271-2/+4
| | | | | | | | | | | | | | | | The patch does not fix the tsan warning it was intended to fix. Reverting the patch moves the av_log() back to the outside of the lock. Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
* | pthread_frame: save the FF_DEBUG_THREADS option in PerThreadContext.Wan-Teh Chang2017-07-111-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the debug_threads boolean field to PerThreadContext. For PerThreadContext *p, p->debug_threads records whether the FF_DEBUG_THREADS bit is set in p->avctx->debug, and p->debug_threads and p->avctx->debug are kept in sync. The debug_threads field is defined as an atomic_int to allow atomic read by another thread in ff_thread_await_progress(). This fixes the tsan warning that 2e664b9c1e73c80aab91070c1eb7676f04bdd12d attempted to fix: WARNING: ThreadSanitizer: data race (pid=452658) Write of size 4 at 0x7b640003f4fc by main thread (mutexes: write M248499): #0 update_context_from_user [..]/libavcodec/pthread_frame.c:335:19 (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe73859) [..] Previous read of size 4 at 0x7b640003f4fc by thread T130 (mutexes: write M248502, write M248500): #0 ff_thread_await_progress [..]/libavcodec/pthread_frame.c:591:26 (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe749a1) Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
* | avcodec/pthread_frame, decode: allow errors to happen on drainingMuhammad Faiz2017-04-301-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, all frames and errors are correctly reported in order. Also limit the numbers of error during draining to prevent infinite loop. This fix fate failure with THREADS>=4: make fate-h264-attachment-631 THREADS=4 This also reverts a755b725ec1d657609c8bd726ce37e7cf193d03f. Suggested-by: wm4, Ronald S. Bultje, Marton Balint Reviewed-by: w4 <nfxjfg@googlemail.com> Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
* | Merge commit '549d0bdca53af7a6e0c612ab4b03baecf3a5878f'James Almer2017-04-221-1/+1
|\| | | | | | | | | | | | | | | | | | | * commit '549d0bdca53af7a6e0c612ab4b03baecf3a5878f': decode: be more explicit about storing the last packet properties Also copy pkt->size in extract_packet_props(), as it's needed for AVFrame.pkt_size Merged-by: James Almer <jamrial@gmail.com>
| * decode: be more explicit about storing the last packet propertiesAnton Khirnov2016-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | The current code stores a pointer to the packet passed to the decoder, which is then used during get_buffer() for timestamps and side data passthrough. However, since this is a pointer to user data which we do not own, storing it is potentially dangerous. It is also ill defined for the new decoding API with split input/output. Fix this problem by making an explicit internally owned copy of the packet properties.
| * pthread_frame: Unreference hw_frames_ctx on per-thread codec contextsMark Thompson2016-11-101-0/+2
| | | | | | | | | | | | | | | | | | | | When decoding with threads enabled, the get_format callback will be called with one of the per-thread codec contexts rather than with the outer context. If a hwaccel is in use too, this will add a reference to the hardware frames context on that codec context, which will then propagate to all of the other per-thread contexts for decoding. Once the decoder finishes, however, the per-thread contexts are not freed normally, so these references leak.
| * pthread_frame: properly propagate the hw frame context across frame threadsAnton Khirnov2016-11-101-0/+11
| |
| * pthread_frame: use atomics for frame progressAnton Khirnov2016-10-021-10/+17
| |
| * pthread_frame: use atomics for PerThreadContext.stateAnton Khirnov2016-10-021-28/+39
| |
| * pthread_frame: use a thread-safe way for signalling threads to dieAnton Khirnov2016-10-021-9/+11
| | | | | | | | Current code uses a plain int in a racy way, which is UB.
* | pthread_frame: make accesses to debug field be protected by owner lock.Ronald S. Bultje2017-04-071-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | pthread_frame: don't return stale error codes after flushwm42017-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | pthread_frame: allow per-field ThreadFrame owners.Ronald S. Bultje2017-04-061-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | pthread_frame: call update_context_from_user() after acquiring lock.Ronald S. Bultje2017-04-031-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | pthread_frame: Propagate sw_pix_fmt across threadsMark Thompson2017-03-311-0/+1
| | | | | | | | | | | | | | This is required by the VP9 hwaccels (both DXVA2 and VAAPI) when threads are enabled. Tested-by: Hendrik Leppkes <h.leppkes@gmail.com>
* | pthread_frame: minor simplification to error handlingwm42017-03-291-14/+5
| | | | | | | | | | | | | | | | | | | | | | Get rid of the "ret" variable, and always use err. Report the packet as consumed if err is unset. This should be equivalent to the old code, which obviously required err=0 for p->result>=0 (and otherwise, p->result must have had the value err was last set to). The code block added by commit 32a5b631267 is also not needed anymore, because the new code strictly returns err if it's >=0. Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
* | pthread_frame: don't sync items between threads for intra-only codecs.Ronald S. Bultje2017-03-281-1/+1
| | | | | | | | | | | | | | | | | | Intra-only codecs should either be able to read these items from the bitstream, or they should be set upon codec initialization. In both cases, syncing these items at runtime is unnecessary. In practice, this fixes race conditions for decoders that read these values from the bitstream.
* | pthread_frame: fix uninitialized variable readwm42017-03-271-1/+1
| | | | | | | | | | | | | | | | | | Could lead to random behavior. This possibly happened due to commit 32a5b631267. This should/could probably be simplified, but for no apply a minimal fix to quell the errors. Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
* | pthread_frame: do not attempt to unlock a mutex on the wrong threadwm42017-03-271-10/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | async_mutex has is used in a very strange but intentional way: it is locked by default, and unlocked only in regions that can be run concurrently. If the user was calling API functions to the same context from different threads (in a safe way), this could unintentionally unlock the mutex on a different thread than the previous lock operation. It's not allowed by the pthread API. Fix this by emulating a binary semaphore using a mutex and condition variable. (Posix semaphores are not available on all platforms.) Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
* | lavc: Add hwaccel_flags field to AVCodecContextwm42017-03-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This "reuses" the flags introduced for the av_vdpau_bind_context() API function, and makes them available to all hwaccels. This does not affect the current vdpau API, as av_vdpau_bind_context() should obviously override the AVCodecContext.hwaccel_flags flags for the sake of compatibility. Cherry-picked from Libav commit 16a163b5. Reviewed-by: Mark Thompson <sw@jkqxz.net>
* | pthread_frame: remove some dead codewm42017-03-211-7/+1
| | | | | | | | Whatever it was supposed to do.
* | pthread_frame: do not run hwaccel decoding asynchronously unless it's safeAnton Khirnov2017-03-211-7/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain hardware decoding APIs are not guaranteed to be thread-safe, so having the user access decoded hardware surfaces while the decoder is running in another thread can cause failures (this is mainly known to happen with DXVA2). For such hwaccels, only allow the decoding thread to run while the user is inside a lavc decode call (avcodec_send_packet/receive_frame). Merges Libav commit d4a91e65. Signed-off-by: wm4 <nfxjfg@googlemail.com> Tested-by: Michael Niedermayer <michael@niedermayer.cc>
* | pthread_frame: ensure the threads don't run simultaneously with hwaccelAnton Khirnov2017-03-211-0/+34
| | | | | | | | | | | | Merges Libav commit 8dfba25c. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | pthread_frame: use better memory orders for frame progressWan-Teh Chang2017-03-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0. In ff_thread_report_progress(), the fast code path can load progress[field] with the relaxed memory order, and the slow code path can store progress[field] with the release memory order. These changes are mainly intended to avoid confusion when one inspects the source code. They are unlikely to have measurable performance improvement. ff_thread_report_progress() and ff_thread_await_progress() form a pair. ff_thread_await_progress() reads progress[field] with the acquire memory order (in the fast code path). Therefore, one expects to see ff_thread_report_progress() write progress[field] with the matching release memory order. In the fast code path in ff_thread_report_progress(), the atomic load of progress[field] doesn't need the acquire memory order because the calling thread is trying to make the data it just decoded visible to the other threads, rather than trying to read the data decoded by other threads. In ff_thread_get_buffer(), initialize progress[0] and progress[1] using atomic_init(). Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Anton Khirnov <anton@khirnov.net> Merges Libav commit 343e2833. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | pthread_frame: Unreference hw_frames_ctx on per-thread codec contextsMark Thompson2017-03-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When decoding with threads enabled, the get_format callback will be called with one of the per-thread codec contexts rather than with the outer context. If a hwaccel is in use too, this will add a reference to the hardware frames context on that codec context, which will then propagate to all of the other per-thread contexts for decoding. Once the decoder finishes, however, the per-thread contexts are not freed normally, so these references leak. Merges Libav commit fd0fae60. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | pthread_frame: properly propagate the hw frame context across frame threadsAnton Khirnov2017-03-211-0/+11
| | | | | | | | | | | | Merges Libav commit 84f22568. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | pthread_frame: use atomics for frame progressAnton Khirnov2017-03-211-10/+17
| | | | | | | | | | | | Merges Libav commit 59c70227. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | pthread_frame: use atomics for PerThreadContext.stateAnton Khirnov2017-03-211-37/+47
| | | | | | | | | | | | Merges Libav commit 64a31b28. Signed-off-by: wm4 <nfxjfg@googlemail.com>
* | avcodec/pthread_frame: Check av_packet_ref() for failureMichael Niedermayer2017-02-061-1/+7
| | | | | | | | Fixes CID1396242
* | lavc/pthread_frame: protect read state access in setup finish functionClément Bœsch2017-01-161-1/+1
| |
* | avcodec/pthread_frame: Remove unused variableMichael Niedermayer2016-03-151-1/+0
| | | | | | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* | Move the |die| member of FrameThreadContext to PerThreadContext.Wan-Teh Chang2016-03-011-6/+5
| | | | | | | | | | | | | | | | | | | | | | This fixes a data race warning by ThreadSanitizer. FrameThreadContext.die is read by all the worker threads but is not protected by any mutex. Move it to PerThreadContext so that each worker thread reads its own copy of |die|, which can then be protected with PerThreadContext.mutex. Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
* | lavc, lavu: use avutil/thread.h instead of redundant conditional includesClément Bœsch2015-12-071-8/+1
| |
* | avcodec/pthread_frame: update doxygen for update_context_from_threadGanesh Ajjanagadde2015-10-091-0/+1
| | | | | | | | | | Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
* | Merge commit '9f90b24877016e7140b9b14e4b1acee663bb6d8a'Hendrik Leppkes2015-09-051-38/+3
|\| | | | | | | | | | | | | * commit '9f90b24877016e7140b9b14e4b1acee663bb6d8a': lavc: Drop deprecated get_buffer related functions Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
| * lavc: Drop deprecated get_buffer related functionsVittorio Giovara2015-08-281-27/+5
| | | | | | | | Deprecated in 11/2012.
* | disable deprecation warnings in deprecated codeAndreas Cadhalpun2015-08-221-1/+8
| | | | | | | | | | Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
* | Merge commit 'def97856de6021965db86c25a732d78689bd6bb0'Michael Niedermayer2015-07-271-1/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'def97856de6021965db86c25a732d78689bd6bb0': lavc: AV-prefix all codec capabilities Conflicts: cmdutils.c ffmpeg.c ffplay.c libavcodec/8svx.c libavcodec/aacenc.c libavcodec/ac3dec.c libavcodec/adpcm.c libavcodec/alac.c libavcodec/atrac3plusdec.c libavcodec/bink.c libavcodec/dnxhddec.c libavcodec/dvdec.c libavcodec/dvenc.c libavcodec/ffv1dec.c libavcodec/ffv1enc.c libavcodec/fic.c libavcodec/flacdec.c libavcodec/flacenc.c libavcodec/flvdec.c libavcodec/fraps.c libavcodec/frwu.c libavcodec/gifdec.c libavcodec/h261dec.c libavcodec/hevc.c libavcodec/iff.c libavcodec/imc.c libavcodec/libopenjpegdec.c libavcodec/libvo-aacenc.c libavcodec/libvorbisenc.c libavcodec/libvpxdec.c libavcodec/libvpxenc.c libavcodec/libx264.c libavcodec/mjpegbdec.c libavcodec/mjpegdec.c libavcodec/mpegaudiodec_float.c libavcodec/msmpeg4dec.c libavcodec/mxpegdec.c libavcodec/nvenc_h264.c libavcodec/nvenc_hevc.c libavcodec/pngdec.c libavcodec/qpeg.c libavcodec/ra288.c libavcodec/rv10.c libavcodec/s302m.c libavcodec/sp5xdec.c libavcodec/takdec.c libavcodec/tiff.c libavcodec/tta.c libavcodec/utils.c libavcodec/v210dec.c libavcodec/vp6.c libavcodec/vp9.c libavcodec/wavpack.c libavcodec/yop.c Merged-by: Michael Niedermayer <michael@niedermayer.cc>
| * lavc: AV-prefix all codec capabilitiesVittorio Giovara2015-07-271-1/+2
| | | | | | | | | | | | Express bitfields more simply. Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-31 19:56:15 +0000