| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Will remove unnecessary allocations when both src and dst picture contain
references to the same buffers.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
function
Signed-off-by: James Almer <jamrial@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Fixes NULL dereference during alloc failure.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|\
| |
| |
| |
| |
| |
| | |
* commit 'dd343fd986459f467a2d1d70c26101dff1d47d68':
lavu: Drop deprecated VDPAU pixel formats
Merged-by: James Almer <jamrial@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '7b917041184874e7d7cba4450813de7e0bb28a33':
lavc: Drop deprecated VDPAU codec capability
Merged-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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(-)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| |
| |
| |
| |
| | |
Doing so is analogous to writing to source data in memcpy(), and causes
(harmless) tsan warnings in fate-h264.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '9df889a5f116c1ee78c2f239e0ba599c492431aa':
h264: rename h264.[ch] to h264dec.[ch]
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| | |
This is more consistent with the naming of other decoders.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'bec993381cfec72051b0d9f12ac9d9bb9c750983':
h264: postpone generating the implicit MMCOs
Merged-by: Clément Bœsch <clement@stupeflix.com>
|
| |
| |
| |
| |
| |
| | |
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().
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '39ab2ea53121b9976a619cd545fbd3464b908696':
h264: rename mmco_index to nb_mmco
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| |
| | |
The variable stores the number of mmco entries, so the current name is
misleading.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '4f81f8dba735c212efae077c4fec8ad4fe53b352':
Drop unnecessary golomb.h #includes
Merged-by: Clément Bœsch <clement@stupeflix.com>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '41ed7ab45fc693f7d7fc35664c0233f4c32d69bb':
cosmetics: Fix spelling mistakes
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| | |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8':
h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>
|
| |
| |
| |
| | |
This will allow decoupling the parser from the decoder.
|
| |
| |
| |
| |
| |
| |
| | |
Fixes race condition causing artifacts
Fixes Ticket4122
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '9d33bab583a82cf12286c65258a29c6888e1ff98':
h264: drop H264Context.ouputed_poc
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
It is only set, but never used for anything.
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '27b0e6ebfd47b0c11156c18b90fa8c571f0f60c3':
h264: drop needs_realloc
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
It is not needed anymore since switching to refcounted frames.
|
| |
| |
| |
| |
| |
| | |
This fixes slice threads with error concealment
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'a4d34e218f548d381e09c483e8dc6ad18a8d571c':
h264: disable ER by default
Conflicts:
libavcodec/h264.c
libavcodec/h264_picture.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
The way it is currently designed is fundamentally unsafe and cannot be
reasonably fixed without completely rewriting it.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'a12d3188cbec15e22070e139fa5cc541da07e2c3':
h264: use a smaller struct for the ref lists
Conflicts:
libavcodec/h264_direct.c
libavcodec/h264_mb.c
libavcodec/h264_picture.c
libavcodec/h264_refs.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| | |
There is no need to store a whole H264Picture, with a full AVFrame
embedded in it. This should allow getting rid of the embedded AVFrame
later.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '582683b6ac798ed2a004a4e2121b7bd47892bbfd':
h264: move remaining ER stuff into the per-slice context
Conflicts:
libavcodec/h264.h
libavcodec/h264_picture.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '95eb35f30513e335990ad0d5dca6ddc318477291':
h264: move the ref lists variables into the per-slice context
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_direct.c
libavcodec/h264_mb.c
libavcodec/h264_picture.c
libavcodec/h264_refs.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also move EC ref initialization to where the EC code is called.
Fixes out of array read
Fixes: asan_heap-uaf_143f420_142_20110805_112659_ch0.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'ca1e36a8e4cd416142487071dbca734567bdaddf':
h264: fix build when error resilience is disabled
Conflicts:
libavcodec/h264_picture.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '888dcd86755d37e55fd74166f6d38ad66d41db58':
h264_picture: Remove pointless dsputil.h #include
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|