summaryrefslogtreecommitdiff
path: root/libavcodec/pthread_frame.c
Commit message (Collapse)AuthorAge
* avcodec/avcodec: Store whether AVCodec->close needs to be calledAndreas Rheinhardt2021-04-28
| | | | | | | | | | | | | | | Right now all AVCodecContexts except those using frame-threaded decoding call the codec's init function and expect its close function to be called. In order to make sure that the close function is not called for frame-threaded decoding ff_frame_thread_free() resets AVCodecContext.codec (and because of this it has to free the private AVOptions of the main AVCodecContext itself). This is not obvious and potentially fragile. Instead add a field to AVCodecInternal that indicates whether close should be called for this AVCodecContext. It is always zero when using frame-threaded decoding, so that resetting the codec is no longer necessary and has been removed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec: Remove deprecated AVCodecContext.coded_frameAndreas Rheinhardt2021-04-27
| | | | | | | | | | Deprecated in 40cf1bbacc6220a0aa6bed5c331871d43f9ce370. (The currently disabled filter vf_mcdeint and vf_uspp were users of this field; they have not been changed, so that whoever wants to fix them can see the state of these filters when they were disabled.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: James Almer <jamrial@gmail.com>
* pthread_frame: introduce a codec callback to update the user-facing contextHendrik Leppkes2021-04-14
|
* avcodec/pthread_frame: ReindentationAndreas Rheinhardt2021-03-26
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/pthread_frame: Check initializing mutexes/condition variablesAndreas Rheinhardt2021-03-26
| | | | | | | | | | | | | | | | | | Up until now, initializing the mutexes/condition variables wasn't checked by ff_frame_thread_init(). This commit changes this. Given that it is not documented to be save to destroy a zeroed but otherwise uninitialized mutex/condition variable, one has to choose between two approaches: Either one duplicates the code to free them in ff_frame_thread_init() in case of errors or one records which have been successfully initialized. This commit takes the latter approach: For each of the two structures with mutexes/condition variables an array containing the offsets of the members to initialize is added. Said array is used both for initializing and freeing and the only thing that needs to be recorded is how many of these have been successfully initialized. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/pthread_frame: Fix cleanup during initAndreas Rheinhardt2021-03-26
| | | | | | | | | | | | | | | | | In case an error happened when setting up the child threads, ff_frame_thread_init() would up until now call ff_frame_thread_free() to clean up all threads set up so far, including the current, not properly initialized one. But a half-allocated context needs special handling which ff_frame_thread_frame_free() doesn't provide. Notably, if allocating the AVCodecInternal, the codec's private data or setting the options fails, the codec's close function will be called (if there is one); it will also be called if the codec's init function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP is set. This is not supported by all codecs; in ticket #9099 it led to a crash. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/pthread_frame: Factor initializing single thread outAndreas Rheinhardt2021-03-26
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/pthread_frame: use av_packet_alloc() to allocate packetsJames Almer2021-03-17
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec: deprecate AVCodecContext.debug_mvJames Almer2021-01-25
| | | | | | It's been unused for almost three years now. Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec: remove long dead debug_mv codeJames Almer2021-01-25
| | | | | | FF_API_DEBUG_MV has been zero since ffmpeg 4.0 Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec: deprecate thread_safe_callbacksAnton Khirnov2020-11-27
| | | | | | | | | They add considerable complexity to frame-threading implementation, which includes an unavoidably leaking error path, while the advantages of this option to the users are highly dubious. It should be always possible and desirable for the callers to make their get_buffer2() implementation thread-safe, so deprecate this option.
* pthread_frame: use av_buffer_replace() to simplify codeAnton Khirnov2020-09-28
|
* pthread_frame: change the criterium for updating thread contextsAnton Khirnov2020-07-07
| | | | | | | | | | | Currently the next thread's context is updated from the previous one's if the codec descriptor is not marked as intra-only. That is not entirely correct, since that property does not necessarily imply anything about how a specific decoder implementation behaves. Instead, use the presence of the update_thread_context() callback to decide whether an update should be performed. Fixes races in CFHD, should cause no behaviour change in any other decoders.
* pthread_frame: change the way delay is setAnton Khirnov2020-06-09
| | | | | | | | | It is a constant known at codec init, so set it in ff_frame_thread_init(). Also, only set it for video, since the meaning of this field is not well-defined for audio with frame threading. Fixes availability of delay in callbacks invoked from the per-thread contexts after 1f4cf92cfbd3accbae582ac63126ed5570ddfd37.
* lavc: Rename hwaccel.h to hwconfig.hMark Thompson2020-04-26
| | | | | This already applied to decoders as well as hwaccels, and adding encoder support was going to make the name even more inaccurate.
* lavc: do not implicitly share the frame pool between threadsAnton Khirnov2020-04-10
| | | | | | | | | | | | | Currently the frame pool used by the default get_buffer2() implementation is a single struct, allocated when opening the decoder. A pointer to it is simply copied to each frame thread and we assume that no thread attempts to modify it at an unexpected time. This is rather fragile and potentially dangerous. With this commit, the frame pool is made refcounted, with the reference being propagated across threads along with other context variables. The frame pool is now also immutable - when the stream parameters change we drop the old reference and create a new one.
* pthread_frame: do not copy a range of AVCodecContext fields at onceAnton Khirnov2020-04-10
| | | | | This is extremely fragile against reordering and hides what is actually being copied. Copy all the fields manually instead.
* pthread_frame: do not embed full AVFrame structs into per-thread contextsAnton Khirnov2020-04-10
| | | | | Use the AVFrame API to properly allocate and free frames for delayed release.
* pthread_frame: do not share priv_data between multiple codec contextsAnton Khirnov2020-04-10
| | | | | | | | Specifically, between the user-facing one and the first frame thread one. This is fragile and dangerous, allocate separate private data for each per-thread context.
* pthread_frame: merge the functionality for normal decoder init and ↵Anton Khirnov2020-04-10
| | | | | | | | | | | | | | | | init_thread_copy The current design, where - proper init is called for the first per-thread context - first thread's private data is copied into private data for all the other threads - a "fixup" function is called for all the other threads to e.g. allocate dynamically allocated data is very fragile and hard to follow, so it is abandoned. Instead, the same init function is used to init each per-thread context. Where necessary, AVCodecInternal.is_copy can be used to differentiate between the first thread and the other ones (e.g. for decoding the extradata just once).
* lavc: replace AVCodecInternal.allocate_progress with an internal capAnton Khirnov2020-04-10
| | | | This is a constant codec property, so a capability flag is more appropriate.
* pthread_frame: make sure ff_thread_release_buffer always cleans the frameAnton Khirnov2020-04-10
|
* lavc/pthread_frame: Update user context in ff_frame_thread_freeLinjie Fu2020-03-27
| | | | | | | | | | | | | | | | | | | | | | Resolution/format changes lead to re-initialization of hardware accelerations(vaapi/dxva2/..) with new hwaccel_priv_data in the worker-thread. But hwaccel_priv_data in user context won't be updated until the resolution changing frame is output. A termination with "-vframes" just after the reinit will lead to: 1. memory leak in worker-thread. 2. double free in user-thread. Update user context in ff_frame_thread_free with the last thread submit_packet() was called on. To reproduce: ffmpeg -hwaccel vaapi(dxva2) -v verbose -i fate-suite/h264/reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo -vsync passthrough -vframes 47 -y out.yuv Signed-off-by: Linjie Fu <linjie.fu@intel.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
* avcodec: add an AVCodecContext field to signal types of packet, frame, and ↵James Almer2020-02-22
| | | | | | | | coded stream side data to export Add an initial mvs flag to is, analog to the export_mvs flags2 one. Signed-off-by: James Almer <jamrial@gmail.com>
* lavc/pthread: use THREAD_SAFE_CALLBACKS() to simplifx more codeJun Zhao2018-08-31
| | | | | | 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-14
| | | | | | | | 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-26
| | | | | | | | | | | 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-15
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* Merge commit '5182a28b5de060c51c21b36053ab205bfbbbbe31'James Almer2017-10-23
|\ | | | | | | | | | | | | * commit '5182a28b5de060c51c21b36053ab205bfbbbbe31': lavc: Drop deprecated global afd field Merged-by: James Almer <jamrial@gmail.com>
| * lavc: Drop deprecated global afd fieldVittorio Giovara2017-03-23
| | | | | | | | Deprecated in 08/2014.
| * lavc: Add hwaccel_flags field to AVCodecContextwm42017-03-20
| | | | | | | | | | | | | | | | 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-19
| | | | | | | | | | | | | | | | | | | | 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-19
| |
| * pthread_frame: use better memory orders for frame progressWan-Teh Chang2016-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25
| | | | | | | | Signed-off-by: James Almer <jamrial@gmail.com>
* | pthread_frame: revert 2e664b9c1e73c80aab91070c1eb7676f04bdd12d.Wan-Teh Chang2017-07-27
| | | | | | | | | | | | | | | | 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-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-22
|\| | | | | | | | | | | | | | | | | | | * 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-14
| | | | | | | | | | | | | | | | | | | | | | 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-10
| | | | | | | | | | | | | | | | | | | | 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-10
| |
| * pthread_frame: use atomics for frame progressAnton Khirnov2016-10-02
| |
| * pthread_frame: use atomics for PerThreadContext.stateAnton Khirnov2016-10-02
| |
| * pthread_frame: use a thread-safe way for signalling threads to dieAnton Khirnov2016-10-02
| | | | | | | | 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-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-31
| | | | | | | | | | | | | | This is required by the VP9 hwaccels (both DXVA2 and VAAPI) when threads are enabled. Tested-by: Hendrik Leppkes <h.leppkes@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-27 17:44:57 +0000