suppose
a. You have 3 frames, 0, 1, 4096.
b. The ltMask is 0xfff and use_msb is 0.
c. The 0, 1 are lt refs for 4096.
d. you are decoding frame 4096, and get the 0 frame.
Since 4096 & ltMask is 0 too, even you want get 0, find_ref_idx may give you 4096.
add_candidate_ref will report an error for this
Tested-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
We will generate a new frame for a missed reference. The frame can only
be used for reference. We assign an invalid decode sequence to it, so
it will not be involved in any dpb process.
Tested-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
According to C.5.2.2, item 2. When we got an IRAP, and the
NoOutputOfPriorPicsFlag = 0, we need bump all outputable frames.
Tested-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
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>
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>
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>
Similar in spirit and design to 66845cffc3, but slightly simpler due
to the lack of interlaced frames in HEVC. See that commit for more
details.
For the seed value, since no specification for this appears to exist, I
semi-arbitrarily decided to base it off the POC id alone, since there's
no analog of the idr_pic_id in HEVC's I-frames. This design is stable
across remuxes and seeks, but changes for adjacent frames with a period
that's typically long enough not to be noticeable, which makes it
satisfy all of the requirements that a film grain seed should have.
Tested with and without threading, using a patch to insert film grain
metadata artificially (for lack of real files containing film grain).
Currently find_ref_idx() would trigger 2 scans in DPB to find the
requested POC:
1. Firstly, ignore MSB of ref->poc and search for the requested POC;
2. Secondly, compare the entire ref->poc with requested POC;
For long term reference, we are able to only check LSB if MSB is not
presented(e.g. delta_poc_msb_present_flag == 0). However, for short
term reference, we should never ignore poc's MSB and it should be
kind of bit-exact. (Details in 8.3.2)
Otherwise this leads to decoding failures like:
[hevc @ 0x5638f4328600] Error constructing the frame RPS.
[hevc @ 0x5638f4328600] Error parsing NAL unit #2.
[hevc @ 0x5638f4338a80] Could not find ref with POC 21
Error while decoding stream #0:0: Invalid data found when processing input
Search the requested POC based on whether MSB is used, and avoid
the 2-times scan for DPB buffer. This benefits both native HEVC
decoder and integrated HW decoders.
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
No longer required since 63d875772d. The equivalent hack
for h264 was removed in that commit, but this one was missed.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Fixes: runtime error: index 16 out of bounds for type 'int [16]'
Fixes: 2209/clusterfuzz-testcase-minimized-5012343912136704
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Move it to hevc_ps as well. This is in preparation for a following patch.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Based on the H264 SEI implementation.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'f6e2f8a9ffda2247bffba991450990d075ea68e3':
hevcdec: move parameter set parsing into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c359d624d3efc3fd1d83210d78c4152bd329b765':
hevcdec: move decoder-independent declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.
* commit '2268db2cd052674fde55c7d48b7a5098ce89b4ba':
lavu: Drop the {minus,plus}1 suffix from AVComponentDescriptor fields
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd82e1adc2019135a2fc45372e0ed0b5ef107cdd0':
hevc: move splitting the packet into NALUs into a separate function
Conflicts:
libavcodec/hevc.c
libavcodec/hevc.h
libavcodec/hevc_parse.c
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
