aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/h264_picture.c
Commit message (Collapse)AuthorAgeFilesLines
* lavc/refstruct: move to lavu and make publicAnton Khirnov2024-12-151-15/+15
| | | | It is highly versatile and generally useful.
* Revert "avcodec/h2645: allocate film grain metadata dynamically"James Almer2024-11-111-9/+2
| | | | | | | | | | | | | AVFilmGrainAFGS1Params, the offending struct, is using sizeof(AVFilmGrainParams) when it should not. This change also forgot to make the necessary changes to the frame threading sync code. Both of these will be fixed by the following commit. H274FilmGrainDatabase will be handled later. This reverts commit 08b1bffa49715a9615acc025dfbea252d8409e1f. Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/h2645: allocate film grain metadata dynamicallyDale Curtis2024-10-251-2/+9
| | | | | | | | | | | | | Film grain support adds a huge amount of overhead to the H264Context structure for a feature that is rarely used. On low end devices or pages that have lots of media this bloats memory usage rapidly. This changes the static film grain metadata allocations to be dynamic which reduces the H264Context size from 851808 bytes to 53444 bytes. Bug: https://crbug.com/359358875 Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Niklas Haas <git@haasn.dev>
* avcodec/h264: keep track of which frames used gray referencesMichael Niedermayer2023-11-201-0/+1
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/h264dec: Use RefStruct-pool API instead of AVBufferPool APIAndreas Rheinhardt2023-11-011-52/+20
| | | | | | | | | | | | It involves less allocations and therefore has the nice property that deriving a reference from a reference can't fail. This allows for considerable simplifications in ff_h264_(ref|replace)_picture(). Switching to the RefStruct API also allows to make H264Picture smaller, because some AVBufferRef* pointers could be removed without replacement. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/pthread_frame: Remove ff_thread_release_buffer()Andreas Rheinhardt2023-10-221-10/+10
| | | | | | | | | | | | | | It is unnecessary since the removal of non-thread-safe callbacks in e0786a8eeb9e7c8feb057e83f284491f0a87e463. Since then, the AVCodecContext has only been used as logcontext. Removing ff_thread_release_buffer() allowed to remove AVCodecContext* parameters from several other functions (not only unref functions, but also e.g. ff_h264_ref_picture() which calls ff_h264_unref_picture() on error). Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264dec: Constify H.264 decoderAndreas Rheinhardt2023-10-131-3/+3
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/decode: Use RefStruct API for hwaccel_picture_privateAndreas Rheinhardt2023-10-071-14/+5
| | | | | | | | | | | | Avoids allocations and therefore error checks: Syncing hwaccel_picture_private across threads can't fail any more. Also gets rid of an unnecessary pointer in structures and in the parameter list of ff_hwaccel_frame_priv_alloc(). Reviewed-by: Anton Khirnov <anton@khirnov.net> Reviewed-by: Lynne <dev@lynne.ee> Tested-by: Lynne <dev@lynne.ee> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264_ps: Use RefStruct API for SPS/PPSAndreas Rheinhardt2023-10-071-5/+5
| | | | | | | | | | | | | | Avoids allocations and error checks for these allocations; e.g. syncing buffers across threads can't fail any more and needn't be checked. It also avoids having to keep H264ParamSets.pps and H264ParamSets.pps_ref and PPS.sps and PPS.sps_ref in sync and gets rid of casts and indirections. (The removal of these checks and the syncing code even more than offset the additional code for RefStruct.) Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264dec: Fix data race when updating decode_error_flagsAndreas Rheinhardt2023-09-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using multi-threaded decoding, every decoding thread has its own DBP consisting of H264Pictures and each of these points to its own AVFrames. They are synced during update_thread_context via av_frame_ref() and therefore the threads actually decoding (as well as all the others) must not modify any field that is copied by av_frame_ref() after ff_thread_finish_setup(). Yet this is exactly what happens when an error occurs during decoding and the AVFrame's decode_error_flags are updated. Given that these errors only become apparent during decoding, this can't be set before ff_thread_finish_setup() without defeating the point of frame-threading; in practice, this meant that the decoder did not set these flags correctly in case frame-threading was in use. (This means that e.g. the ffmpeg cli tool fails to output its "corrupt decoded frame" message in a nondeterministic fashion.) This commit fixes this by adding a new H264Picture field that is actually propagated across threads; the field is an AVBufferRef* whose data is an atomic_int; it is atomic in order to allow multiple threads to update it concurrently and not to provide synchronization between the threads setting the field and the thread ultimately returning the AVFrame. This unfortunately has the overhead of one allocation per H264Picture (both the original one as well as creating a reference to an existing one), even in case of no errors. In order to mitigate this, an AVBufferPool has been used and only if frame-threading is actually in use. This expense will be removed as soon as a proper API for refcounted objects (not based upon AVBuffer) is in place. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/internal: Don't auto-include emms.hAndreas Rheinhardt2023-09-041-0/+1
| | | | | | Instead include emms.h wherever it is needed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/avcodec: Add FFHWAccel, hide internals of AVHWAccelAndreas Rheinhardt2023-08-071-1/+2
| | | | | | | | | This commit is the AVHWAccel analogue of commit 20f972701806be20a77f808db332d9489343bb78: It moves the private fields of AVHWAccel to a new struct FFHWAccel extending AVHWAccel in an internal header (namely hwaccel_internal.h). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264_picture: use ff_thread_replace_frame()James Almer2023-05-181-2/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/thread: Don't use ThreadFrame when unnecessaryAndreas Rheinhardt2022-02-091-9/+6
| | | | | | | | | | | | | | | | | | | | | | | The majority of frame-threaded decoders (mainly the intra-only) need exactly one part of ThreadFrame: The AVFrame. They don't need the owners nor the progress, yet they had to use it because ff_thread_(get|release)_buffer() requires it. This commit changes this and makes these functions work with ordinary AVFrames; the decoders that need the extra fields for progress use ff_thread_(get|release)_ext_buffer() which work exactly as ff_thread_(get|release)_buffer() used to do. This also avoids some unnecessary allocations of progress AVBuffers, namely for H.264 and HEVC film grain frames: These frames are not used for synchronization and therefore don't need a ThreadFrame. Also move the ThreadFrame structure as well as ff_thread_ref_frame() to threadframe.h, the header for frame-threaded decoders with inter-frame dependencies. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/threadframe: Add ff_thread_(get|release)_ext_buffer()Andreas Rheinhardt2022-02-091-2/+2
| | | | | | | | | These will be used by the codecs that need allocated progress and is in preparation for no longer using ThreadFrame by the codecs that don't. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/thread: Move ff_thread_(await|report)_progress to new headerAndreas Rheinhardt2022-02-091-1/+1
| | | | | | | | | | This is in preparation for further commits that will stop using ThreadFrame for frame-threaded codecs that don't use ff_thread_(await|report)_progress(); the API for those codecs having inter-frame depdendencies will live in threadframe.h. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264*: Remove unnecessary h264_mvpred.h inclusionsAndreas Rheinhardt2022-01-261-9/+0
| | | | | | | This is only needed by h264_cabac.c and h264_cavlc.c. Also fix up the other headers while at it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/h264_picture: don't assume Film Grain Params side data will be presentJames Almer2021-10-181-3/+5
| | | | | | | | | | | If a decoding error happens before frame side data is allocated, this assert may be triggered. And since applying film grain is not enforced (we just warn it wasn't applied and move on), we can just do that in such scenarios. Fixes: Assertion failure Fixes: clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5528650032742400 Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/h264_picture: wait for the second slice to apply film grain on ↵James Almer2021-09-141-1/+1
| | | | | | | | | | interlaced content Fixes: Assertion failure Fixes: clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6581961297100800 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/h264dec: apply H.274 film grainNiklas Haas2021-08-241-2/+33
| | | | | | | | | | | | | | | | | | | | | | | Because we need access to ref frames without film grain applied, we have to add an extra AVFrame to H264Picture to avoid messing with the original. This requires some amount of overhead to make the reference moves work out, but it allows us to benefit from frame multithreading for film grain application "for free". Unfortunately, this approach requires twice as much RAM to be constantly allocated for ref frames, due to the need for an extra buffer per H264Picture. In theory, we could get away with freeing up this memory as soon as it's no longer needed (since ref frames do not need film grain buffers any longer), but trying to call ff_thread_release_buffer() from output_frame() conflicts with possible later accesses to that same frame and I'm not sure how to synchronize that well. Tested on all three cases of (no fg), (fg present but exported) and (fg present and not exported), with and without threading. Co-authored-by: James Almer <jamrial@gmail.com> Signed-off-by: Niklas Haas <git@haasn.dev> Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/h264_picture: add ff_h264_replace_picture()James Almer2021-08-101-0/+44
| | | | | | | Will remove unnecessary allocations when both src and dst picture contain references to the same buffers. Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/h264_picture: split copying H264Picture some fields into a separate ↵James Almer2021-08-101-24/+33
| | | | | | function Signed-off-by: James Almer <jamrial@gmail.com>
* h264dec: support exporting QP tables through the AVVideoEncParams APIAnton Khirnov2020-05-251-1/+7
|
* libavcodec, libpostproc: Remove outcommented START/STOP_TIMERAndreas Rheinhardt2020-03-141-1/+0
| | | | | | | as well as includes of libavutil/timer.h. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* h264_picture: Actually return error during alloc failureDerek Buitenhuis2017-11-261-3/+9
| | | | | | Fixes NULL dereference during alloc failure. Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* Merge commit 'dd343fd986459f467a2d1d70c26101dff1d47d68'James Almer2017-10-231-1/+0
|\ | | | | | | | | | | | | * commit 'dd343fd986459f467a2d1d70c26101dff1d47d68': lavu: Drop deprecated VDPAU pixel formats Merged-by: James Almer <jamrial@gmail.com>
* | Merge commit '7b917041184874e7d7cba4450813de7e0bb28a33'James Almer2017-10-211-12/+0
|\| | | | | | | | | | | | | * commit '7b917041184874e7d7cba4450813de7e0bb28a33': lavc: Drop deprecated VDPAU codec capability Merged-by: James Almer <jamrial@gmail.com>
| * h264dec: make sure to only end a field if it has been startedAnton Khirnov2016-12-191-0/+1
| | | | | | | | | | | | | | | | Calling ff_h264_field_end() when the per-field state is not properly initialized leads to all kinds of undefined behaviour. CC: libav-stable@libav.org Bug-Id: 977 978 992
* | avcodec/h264dec: export cropping information instead of handling it internallyJames Almer2017-05-261-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | This merges commit c3e84820d67cb1d8cfb4196f9b43971308a81571 from libav, originally written by Anton Khirnov and skipped in fc63d5ceb357c4b760cb02772de0b50d0557140f. libavcodec/h264_picture.c | 3 --- libavcodec/h264_ps.c | 9 --------- libavcodec/h264_slice.c | 25 +++++++++++++++++++------ libavcodec/h264dec.c | 13 +------------ libavcodec/h264dec.h | 9 +++++---- 5 files changed, 25 insertions(+), 34 deletions(-)
* | h264: don't sync pic_id between threads.Ronald S. Bultje2017-04-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | h264: don't write to source picture object in ff_h264_ref_picture().Ronald S. Bultje2017-03-311-1/+1
| | | | | | | | | | Doing so is analogous to writing to source data in memcpy(), and causes (harmless) tsan warnings in fate-h264.
* | Merge commit '9df889a5f116c1ee78c2f239e0ba599c492431aa'Clément Bœsch2016-07-291-1/+1
|\| | | | | | | | | | | | | * commit '9df889a5f116c1ee78c2f239e0ba599c492431aa': h264: rename h264.[ch] to h264dec.[ch] Merged-by: Clément Bœsch <u@pkh.me>
| * h264: rename h264.[ch] to h264dec.[ch]Anton Khirnov2016-06-211-1/+1
| | | | | | | | This is more consistent with the naming of other decoders.
* | Merge commit 'bec993381cfec72051b0d9f12ac9d9bb9c750983'Clément Bœsch2016-06-301-1/+1
|\| | | | | | | | | | | | | * commit 'bec993381cfec72051b0d9f12ac9d9bb9c750983': h264: postpone generating the implicit MMCOs Merged-by: Clément Bœsch <clement@stupeflix.com>
| * h264: postpone generating the implicit MMCOsAnton Khirnov2016-06-121-1/+1
| | | | | | | | | | | | Do it right before the MMCOs are applied to the DPB. This will allow moving the frame_start() call out of the slice header parsing, since generating the implicit MMCOs needs to be done after frame_start().
* | Merge commit '39ab2ea53121b9976a619cd545fbd3464b908696'Clément Bœsch2016-06-291-1/+1
|\| | | | | | | | | | | | | * commit '39ab2ea53121b9976a619cd545fbd3464b908696': h264: rename mmco_index to nb_mmco Merged-by: Clément Bœsch <u@pkh.me>
| * h264: rename mmco_index to nb_mmcoAnton Khirnov2016-06-121-1/+1
| | | | | | | | | | The variable stores the number of mmco entries, so the current name is misleading.
* | Merge commit '4f81f8dba735c212efae077c4fec8ad4fe53b352'Clément Bœsch2016-06-291-1/+0
|\| | | | | | | | | | | | | * commit '4f81f8dba735c212efae077c4fec8ad4fe53b352': Drop unnecessary golomb.h #includes Merged-by: Clément Bœsch <clement@stupeflix.com>
| * Drop unnecessary golomb.h #includesDiego Biurrun2016-06-081-1/+0
| |
* | Merge commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb'Clément Bœsch2016-06-211-1/+1
|\| | | | | | | | | | | | | * commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb': cosmetics: Fix spelling mistakes Merged-by: Clément Bœsch <u@pkh.me>
| * cosmetics: Fix spelling mistakesVittorio Giovara2016-05-041-1/+1
| | | | | | | | Signed-off-by: Diego Biurrun <diego@biurrun.de>
* | Merge commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8'Clément Bœsch2016-06-121-4/+4
|\| | | | | | | | | | | | | * commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8': h264: factor out calculating the POC count into a separate file Merged-by: Clément Bœsch <u@pkh.me>
| * h264: factor out calculating the POC count into a separate fileAnton Khirnov2016-04-241-4/+4
| | | | | | | | This will allow decoupling the parser from the decoder.
* | avcodec/h264: Execute error concealment before marking the frame as done.Michael Niedermayer2016-02-191-41/+0
| | | | | | | | | | | | | | Fixes race condition causing artifacts Fixes Ticket4122 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* | lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU.Ronald S. Bultje2015-08-181-0/+4
| |
* | lavc: propagate hwaccel errorswm42015-08-061-1/+2
| | | | | | | | | | | | | | | | At least the new videotoolbox decoder does not actually set a frame if end_frame fails. This causes the API to return success and signals that a picture was decoded, even though AVFrame->data[0] is NULL. Fix this by propagating end_frame errors.
* | Merge commit 'def97856de6021965db86c25a732d78689bd6bb0'Michael Niedermayer2015-07-271-2/+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>
* | avcodec/vdpau: Re-factor pre-hwaccel helper functions into separate headerPhilip Langdale2015-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | h264.h and hevc.h are mutually exclusive due to defining some of the same names. As such, we need to avoid forcing h264.h to be included if we want hevc decode acceleration to be possible. However, some of the pre-hwaccel helper functions need h264.h. To avoid messy collisions, let's move the declaration of all those helpers to a separate header which we will exclude for the hevc support (which will be hwaccel-only). Signed-off-by: Philip Langdale <philipl@overt.org>
* | Merge commit 'a0f2946068c62e18cb05ac25c0df3d86077251a6'Michael Niedermayer2015-04-291-9/+9
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'a0f2946068c62e18cb05ac25c0df3d86077251a6': h264: use properly allocated AVFrames Conflicts: libavcodec/h264.c libavcodec/h264.h libavcodec/h264_refs.c libavcodec/h264_slice.c libavcodec/svq3.c libavcodec/vda_h264.c Merged-by: Michael Niedermayer <michaelni@gmx.at>
| * h264: use properly allocated AVFramesAnton Khirnov2015-04-291-6/+6
| |
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-13 14:34:33 +0000