aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* avcodec/vp9: Fix race when attaching side-data for show-existing frameAndreas Rheinhardt2024-04-191-7/+11
| | | | | | | | | | | | | | | | | | | | | | | When outputting a show-existing frame, the VP9 decoder simply created a reference to said frame and returned it immediately to the caller, without waiting for it to have finished decoding. In case of frame-threading it is possible for the frame to only be decoded while it was waiting to be output. This is normally benign. But there is one case where it is not: If the user wants video encoding parameters to be exported, said side data will only be attached to the src AVFrame at the end of decoding the frame that is actually being shown. Without synchronisation adding said side data in the decoder thread and the reads in av_frame_ref() in the output thread constitute a data race. This happens e.g. when using the venc_data_dump tool with vp90-2-10-show-existing-frame.webm from the FATE-suite. Fix this by actually waiting for the frame to be output. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/vp9: Switch to ProgressFramesAndreas Rheinhardt2024-04-1910-116/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | This already fixes a race in the vp9-encparams test. In this test, side data is added to the current frame after having been decoded (and therefore after ff_thread_finish_setup() has been called). Yet the update_thread_context callback called ff_thread_ref_frame() and therefore av_frame_ref() with this frame as source frame and the ensuing read was unsynchronised with adding the side data, i.e. there was a data race. By switching to the ProgressFrame API the implicit av_frame_ref() is removed and the race fixed except if this frame is later reused by a show-existing-frame which uses an explicit av_frame_ref(). The vp9-encparams test does not cover this, so this commit already fixes all the races in this test. This decoder kept multiple references to the same ThreadFrames in the same context and therefore had lots of implicit av_frame_ref() even when decoding single-threaded. This incurred lots of small allocations: When decoding an ordinary 10s video in single-threaded mode the number of allocations reported by Valgrind went down from 57,814 to 20,908; for 10 threads it went down from 84,223 to 21,901. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/vp3: Switch to ProgressFramesAndreas Rheinhardt2024-04-191-94/+53
| | | | | | | | | | | Avoids implicit av_frame_ref() and therefore allocations and error checks. It also avoids explicitly allocating the AVFrames (done implicitly when getting the buffer) and it also allows to reuse the flushing code for freeing the ProgressFrames. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/mimic: Switch to ProgressFramesAndreas Rheinhardt2024-04-191-39/+22
| | | | | | | | Avoids implicit av_frame_ref() and therefore allocations and error checks. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/decode: Add new ProgressFrame APIAndreas Rheinhardt2024-04-198-1/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Frame-threaded decoders with inter-frame dependencies use the ThreadFrame API for syncing. It works as follows: During init each thread allocates an AVFrame for every ThreadFrame. Thread A reads the header of its packet and allocates a buffer for an AVFrame with ff_thread_get_ext_buffer() (which also allocates a small structure that is shared with other references to this frame) and sets its fields, including side data. Then said thread calls ff_thread_finish_setup(). From that moment onward it is not allowed to change any of the AVFrame fields at all any more, but it may change fields which are an indirection away, like the content of AVFrame.data or already existing side data. After thread A has called ff_thread_finish_setup(), another thread (the user one) calls the codec's update_thread_context callback which in turn calls ff_thread_ref_frame() which calls av_frame_ref() which reads every field of A's AVFrame; hence the above restriction on modifications of the AVFrame (as any modification of the AVFrame by A after ff_thread_finish_setup() would be a data race). Of course, this av_frame_ref() also incurs allocations and therefore needs to be checked. ff_thread_ref_frame() also references the small structure used for communicating progress. This av_frame_ref() makes it awkward to propagate values that only become known during decoding to later threads (in case of frame reordering or other mechanisms of delayed output (like show-existing-frames) it's not the decoding thread, but a later thread that returns the AVFrame). E.g. for VP9 when exporting video encoding parameters as side data the number of blocks only becomes known during decoding, so one can't allocate the side data before ff_thread_finish_setup(). It is currently being done afterwards and this leads to a data race in the vp9-encparams test when using frame-threading. Returning decode_error_flags is also complicated by this. To perform this exchange a buffer shared between the references is needed (notice that simply giving the later threads a pointer to the original AVFrame does not work, because said AVFrame will be reused lateron when thread A decodes the next packet given to it). One could extend the buffer already used for progress for this or use a new one (requiring yet another allocation), yet both of these approaches have the drawback of being unnatural, ugly and requiring quite a lot of ad-hoc code. E.g. in case of the VP9 side data mentioned above one could not simply use the helper that allocates and adds the side data to an AVFrame in one go. The ProgressFrame API meanwhile offers a different solution to all of this. It is based around the idea that the most natural shared object for sharing information about an AVFrame between decoding threads is the AVFrame itself. To actually implement this the AVFrame needs to be reference counted. This is achieved by putting a (ownership) pointer into a shared (and opaque) structure that is managed by the RefStruct API and which also contains the stuff necessary for progress reporting. The users get a pointer to this AVFrame with the understanding that the owner may set all the fields until it has indicated that it has finished decoding this AVFrame; then the users are allowed to read everything. Every decoder may of course employ a different contract than the one outlined above. Given that there is no underlying av_frame_ref(), creating references to a ProgressFrame can't fail. Only ff_thread_progress_get_buffer() can fail, but given that it will replace calls to ff_thread_get_ext_buffer() it is at places where errors are already expected and properly taken care of. The ProgressFrames are empty (i.e. the AVFrame pointer is NULL and the AVFrames are not allocated during init at all) while not being in use; ff_thread_progress_get_buffer() both sets up the actual ProgressFrame and already calls ff_thread_get_buffer(). So instead of checking for ThreadFrame.f->data[0] or ThreadFrame.f->buf[0] being NULL for "this reference frame is non-existing" one should check for ProgressFrame.f. This also implies that one can only set AVFrame properties after having allocated the buffer. This restriction is not deep: if it becomes onerous for any codec, ff_thread_progress_get_buffer() can be broken up. The user would then have to get a buffer himself. In order to avoid unnecessary allocations, the shared structure is pooled, so that both the structure as well as the AVFrame itself are reused. This means that there won't be lots of unnecessary allocations in case of non-frame-threaded decoding. It might even turn out to have fewer than the current code (the current code allocates AVFrames for every DPB slot, but these are often excessively large and not completely used; the new code allocates them on demand). Pooling relies on the reset function of the RefStruct pool API, it would be impossible to implement with the AVBufferPool API. Finally, ProgressFrames have no notion of owner; they are built on top of the ThreadProgress API which also lacks such a concept. Instead every ThreadProgress and every ProgressFrame contains its own mutex and condition variable, making it completely independent of pthread_frame.c. Just like the ThreadFrame API it is simply presumed that only the actual owner/producer of a frame reports progress on said frame. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/threadprogress: Add new API for frame-threaded progressAndreas Rheinhardt2024-04-192-0/+171
| | | | | | | | | | | | | | | The API is similar to the ThreadFrame API, with the exception that it no longer has an included AVFrame and that it has its own mutexes and condition variables which makes it more independent of pthread_frame.c. One can wait on anything via a ThreadProgress. One just has to ensure that the lifetime of the object containing the ThreadProgress is long enough. This will typically be solved by putting a ThreadProgress in a refcounted structure that is shared between threads. Reviewed-by: Anton Khirnov <anton@khirnov.net> Reviewed-by: epirat07@gmail.com Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* doc/muxers: add mmfStefano Sabatini2024-04-191-0/+9
|
* doc/muxers: add microdvdStefano Sabatini2024-04-191-0/+5
|
* doc/muxers/md5: apply misc consistency fixesStefano Sabatini2024-04-191-5/+7
|
* doc/muxers/matroska: add missing options, apply misc style fixesStefano Sabatini2024-04-191-7/+37
|
* lavf/matroskaenc: apply consistent style to options descriptionsStefano Sabatini2024-04-191-13/+13
|
* lavc/vvc: Skip enhancement layer NAL unitsFrank Plowman2024-04-181-0/+6
| | | | | | | | | | The native VVC decoder does not yet support quality/spatial/multiview scalability. Bitstreams requiring this feature could cause crashes. Patch fixes this by skipping NAL units which are not in the base layer, warning the user while doing so. Signed-off-by: Frank Plowman <post@frankplowman.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/mov: ignore old infe box versionsJames Almer2024-04-181-5/+8
| | | | | | | | | | | Some files with no image items have them, and were working prior to the recent HEIF parsing overhaul. Ignore such boxes instead, to recover the old behavior. Fixes a regression since d9fed9df2a9e70c9375d3b2591db35c09303d369. Tested-by: Wu Jianhua <toqsxw@outlook.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/frame: remove comment about avcodec_get_frame_class()Andrew Sayers2024-04-181-2/+1
| | | | | | The function was deprecated a while back and deleted last year. Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/ac3enc: Avoid copying samplesAndreas Rheinhardt2024-04-183-34/+17
| | | | | | | | | | | | | | Only the last 256 samples of each frame are used; the encoder currently uses a buffer for 1536 + 256 samples whose first 256 samples contain are the last 256 samples from the last frame and the next 1536 are the samples of the current frame. Yet since 238b2d4155d9779d770fccb3594076bb32742c82 all the DSP functions only need 256 contiguous samples and this can be achieved by only retaining the last 256 samples of each frame. Doing so saves 6KiB per channel. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/ac3enc: Combine cpl_coord buffersAndreas Rheinhardt2024-04-182-8/+7
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/ac3enc: Combine loopsAndreas Rheinhardt2024-04-181-17/+7
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/ac3enc: Avoid indirections, allocations of small arraysAndreas Rheinhardt2024-04-182-51/+15
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/ac3enc: Avoid allocation for mdct_windowAndreas Rheinhardt2024-04-185-16/+8
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/ac3enc: Avoid allocation for windowed_samplesAndreas Rheinhardt2024-04-183-8/+15
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavfi/tonemap_vaapi: Add support for HDR to HDR tone mappingXinpeng Sun2024-04-182-30/+203
| | | | | | | | | | Usage example: ffmpeg -y -hwaccel vaapi -hwaccel_output_format vaapi -i hdr.mp4 \ -vf "tonemap_vaapi=display=7500 3000|34000 16000|13250 34500|15635 16450|500 10000000:extra_hw_frames=64" \ -c:v hevc_vaapi output.mp4 Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavfi/tonemap_vaapi: Update the logHaihao Xiang2024-04-181-1/+1
| | | | | | demote the message to AV_LOG_VERBOSE. Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavfi/tonemap_vaapi: By default use bt709 for output frameHaihao Xiang2024-04-182-4/+7
| | | | | | | By default don't use the color properties from input frame as output frame properties when performing HDR to SDR conversion Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* Changelog: Add pad_vaapi, drawbox_vaapi entryHaihao Xiang2024-04-181-0/+1
| | | | Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavfi: Add drawbox_vaapi filterHaihao Xiang2024-04-185-0/+457
| | | | Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavfi: Add pad_vaapi filterHaihao Xiang2024-04-185-0/+363
| | | | Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avcodec/vaapi_encode_h265: use is_reference to fill reference_pic_flagTong Wu2024-04-181-4/+1
| | | | | | | This codec supports FLAG_B_PICTURE_REFERENCES. We need to fill reference_pic_flag with pic->is_reference. Signed-off-by: Tong Wu <tong1.wu@intel.com>
* avcodec/vaapi_encode_h264: use is_reference to fill reference_pic_flagTong Wu2024-04-181-1/+1
| | | | | | | | This codec supports FLAG_B_PICTURE_REFERENCES. We need to correctly fill the reference_pic_flag with is_reference variable instead of 0 for B frames. Signed-off-by: Tong Wu <tong1.wu@intel.com>
* lavfi/vaapi_vpp: Use dynamic frame pool in outlink if possibleHaihao Xiang2024-04-181-1/+6
| | | | | | | | | | | | | | | | | This can avoid to exhaust the buffers within outlink when libva2 is available. For example: $ ffmpeg -hwaccel_output_format vaapi -hwaccel vaapi -i input.mp4 \ -vf 'scale_vaapi=w=720:h=480' -c:v hevc_vaapi -f null - ... [vf#0:0 @ 0x55acad91f400] Error while filtering: Cannot allocate memory [vf#0:0 @ 0x55acad91f400] Task finished with error code: -12 (Cannot allocate memory) [vf#0:0 @ 0x55acad91f400] Terminating thread with return code -12 (Cannot allocate memory) Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* lavc/vaapi_decode: Use dynamic frame pool if possibleHaihao Xiang2024-04-181-16/+20
| | | | | | | | | | | | | | | | | libva2 doesn't require a fixed surface-array any more, so we may use dynamic frame pool for decoding when libva2 is available, which allows a downstream element stores more frames from VAAPI decoders and fixes the error below: $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \ -i input.mp4 -c:v hevc_vaapi -f null - ... [h264 @ 0x557a075a1400] get_buffer() failed [h264 @ 0x557a075a1400] thread_get_buffer() failed [h264 @ 0x557a075a1400] decode_slice_header error [h264 @ 0x557a075a1400] no frame! Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avcodec/ac3: Remove unused fixed-point ARMv7 DSPGeoff Hill2024-04-181-63/+0
| | | | | | | | | | | | | This diff removes 4 unused ARMv7 NEON fixed-point DSP functions. The function were originally moved here by 4958f35a2 (Dec 2013). After 9e05421db (Jan 2021), as part of the refactor of the AC3 DSP to consistently use 32-bit sample format in the encoder, these functions were removed from the DSP function table, but the ARMv7 implementations were kept. Signed-off-by: Geoff Hill <geoff@geoffhill.org>
* avfilter/vf_colorspace: use colorspace negotiation APINicolas Gaullier2024-04-171-26/+36
| | | | | | | | | | | | | | | | | | | Fixes a regression due to the fact that the colorspace filter does not use the new API introduced by 8c7934f73ab6c568acaa. The scale filter uses it since 45e09a30419cc2a7251e, and the setparams filter since 3bf80df3ccd32aed23f0. Example: ffprobe -f lavfi yuvtestsrc,setparams=color_primaries=bt470bg:color_trc= bt470bg:colorspace=bt470bg,colorspace=bt709:range=tv,scale,showinfo Before: color_range:unknown color_space:bt470bg ... After: color_range:tv color_space:bt709 ... Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris> Signed-off-by: Niklas Haas <git@haasn.dev>
* avformat/ivfenc: remove unused varGyan Doshi2024-04-171-3/+1
| | | | sum_delta_pts is unused since 3b358f151d
* avformat/lc3: Only allow AV_CODEC_ID_LC3 in muxerAndreas Rheinhardt2024-04-161-11/+3
| | | | | | | | Also check for the number of streams and the AVCodecID generically using FF_OFMT_FLAGs. Reviewed-by: Stefano Sabatini <stefasab@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264dec: Reindent after the previous commitarch1t3cht2024-04-161-23/+23
| | | | | Signed-off-by: arch1t3cht <arch1t3cht@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* avcodec/h264dec: Handle non-recovered frames when drainingarch1t3cht2024-04-161-1/+6
| | | | | | | | | | | | When starting on a SEI recovery point close enough to the end of the stream that draining starts before the recovery point's frame is output, there can be non-recovered frames in the delayed picture buffer that would currently cause the decoder to fail to output a frame. This commit skips such frames and outputs the first recovered frame, if there exists one. Signed-off-by: arch1t3cht <arch1t3cht@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* avcodec/h264dec: Properly mark frames as recovered when drainingarch1t3cht2024-04-161-0/+3
| | | | | | | | | | | | | | When decoding starts at a SEI recovery point very shortly before the end of the video stream, there can be frames which are decoded before the recovery point's frame is output and which will only be output once the draining has started. Previously, these frames would never be set as recovered. This commit copies the logic from h264_select_output_frame to send_next_delayed_frame to properly mark such frames as recovered. Fixes ticket #10936. Signed-off-by: arch1t3cht <arch1t3cht@gmail.com> Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* avformat/iamf_writer: reject duplicated stream ids in a stream groupJames Almer2024-04-161-0/+11
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/lc3: add file format for LC3/LC3plus transportAntoine SOULIER2024-04-155-0/+263
| | | | | A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for test purpose.
* doc/utils/eval: review and extend, clarify ld/st index meaningStefano Sabatini2024-04-151-27/+33
| | | | | Prefer idx in place of id for functions accessing the internal variables, and add a short introduction to mention them.
* doc/utils/eval: clarify meaning of random* seed valueStefano Sabatini2024-04-151-0/+12
| | | | | Possible address trac issue: http://trac.ffmpeg.org/ticket/10763
* lavc/vvc: Increase size of ctb_size_yFrank Plowman2024-04-151-1/+1
| | | | | | | | | | sps_log2_ctu_size_minus5 is between 0 and 2, with 3 reserved for future use. The VVC decoder allows sps_log2_ctu_size_minus5 to be 3, and so ctb_size_y should be at least 16 bits to prevent overflows. An alternative patch would leave sps_log2_ctu_size_minus5 as 8 bits and disallow sps_log2_ctu_size_minus5 = 3. Signed-off-by: Frank Plowman <post@frankplowman.com>
* avfilter/af_channelsplit: fix memory leakLuMingYin2024-04-151-1/+3
| | | | | Signed-off-by: LuMingYin <lumingyindetect@163.com> Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* vulkan_av1: add workaround for NVIDIA drivers tested on broken CTSLynne2024-04-153-4/+28
| | | | | | | | | | | | The first release of the CTS for AV1 decoding had incorrect offsets for the OrderHints values. The CTS will be fixed, and eventually, the drivers will be updated to the proper spec-conforming behaviour, but we still need to add a workaround as this will take months. Only NVIDIA use these values at all, so limit the workaround to only NVIDIA. Also, other vendors don't tend to provide accurate CTS information.
* lavc/vulkan_av1: Use av1dec reference order hint informationMark Thompson2024-04-141-13/+10
|
* lavc/av1: Record reference ordering information for each frameMark Thompson2024-04-142-0/+34
| | | | | | | This is needed by Vulkan. Constructing this can't be delegated to CBS because packets might contain multiple frames (when non-shown frames are present) but we need separate snapshots immediately before each frame for the decoder.
* doc/muxers.texi: Don't use confusing variable nameAndreas Rheinhardt2024-04-141-2/+2
| | | | | | | reserve_index_space is a size, not an index. Also refer to the variable in the description. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/nvenc: Multi NVENC Split Frame Encoding in HEVC and AV1Diego Felix de Souza2024-04-135-1/+28
| | | | | | | | | | When Split frame encoding is enabled, each input frame is partitioned into horizontal strips which are encoded independently and simultaneously by separate NVENCs, usually resulting in increased encoding speed compared to single NVENC encoding. Signed-off-by: Diego Felix de Souza <ddesouza@nvidia.com> Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
* avcodec/h2645_sei: validate Mastering Display Colour Volume SEI valuesKacper Michajłow2024-04-131-16/+39
| | | | | | | | | | | | | | | As we can read in ST 2086: Values outside the specified ranges of luminance and chromaticity values are not reserved by SMPTE, and can be used for purposes outside the scope of this standard. This is further acknowledged by ITU-T H.264 and ITU-T H.265. Which says that values out of range are unknown or unspecified or specified by other means not specified in this Specification. Signed-off-by: Kacper Michajłow <kasper93@gmail.com> Signed-off-by: Niklas Haas <git@haasn.dev>
* avformat/tls_mbedtls: Pass FLAG_NONBLOCK to underlying transportZhao Zhili2024-04-121-0/+4
| | | | | | This fix rtmps failure since rtmps requires nonblocking read. Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-06 16:26:56 +0000