That function is currently very long and entangles bitstream parsing and
decoder configuration. This makes the code much harder to read than
necessary.
Begin splitting the code that configures the decoder state based on the
slice header information from the parsing of the slice header.
* commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8':
h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3176217c60ca7828712985092d9102d331ea4f3d':
h264: decouple h264_ps from the h264 decoder
Main changes:
- a local GetBitContext is created for the various
ff_h264_decode_seq_parameter_set() attempts
- just like the old code, remove_sps() is adjusted so it doesn't remove
the pps.
Fixes decode with Ticket #631http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
but see next point as well.
- ff_h264_update_thread_context() is updated to work even when SPS
isn't set as it breaks current skip_frame code. This makes sure we
can still decode the sample from ticket #631 without the need for
-flags2 +chunks. (Thanks to Michael)
- keep {sps,pps}_ref pointers that stay alive even when the active
pps/sps get removed from the available lists (patch by michaelni with
additionnal frees in ff_h264_free_context() from mateo)
- added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
crashes with mpegts_with_dvbsubs.ts from Ticket #4074http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
- in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
called, the pps and sps from the local parser context are updated with
the pps and sps from the used h264context. This fixes fate-flv-demux.
- in h264_slice.c, "PPS changed between slices" error is not triggered
anymore in one condition as it makes fate-h264-xavc-4389 fails with
THREADS=N (Thanks to Michael)
Merged-by: Clément Bœsch <clement@stupeflix.com>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
* commit 'a6e27f7add2698fdd89911632b570c3d0c3f2aaa':
h264: factor out parsing the reference count into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'e481458bc308ee838deaeacac51929514762e7a7':
h264: factor out pred weight table parsing into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'a7da517f6a5c472f46f67dd33bb6b95ccc919923':
h264data: Move all data tables from a header to a .c file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In such a case, decode the MBs in parallel without the loop filter, then
execute the filter serially.
The ref2frm array was previously moved to H264SliceContext. That was
incorrect, since it applies to all the slices and should properly be in
H264Context (it did not actually break decoding, since this distinction
only becomes relevant with slice threading and deblocking_filter=1,
which was not implemented before this commit). The ref2frm array is thus
moved back to H264Context.
It is always unconditionally initialized in decode_postinit() and then
immediately used in one place further below. All the other places where
it is accessed are just useless fluff.
Make the SPS/PPS parsing independent of the H264Context, to allow
decoupling the parser from the decoder. The change is modelled after the
one done earlier for HEVC.
Move the dequant buffers to the PPS to avoid complex checks whether they
changed and an expensive copy for frame threads.
Libav, for some reason, merged this as a public API function. This will
aid in future merges.
A define is left for backwards compat, just in case some person
used it, since it is in a public header.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
get_ue_golomb() cannot decode values larger than 8190 (the maximum
value that can be golomb encoded in 25 bits) and produces the error
"Invalid UE golomb code" if a larger value is encountered. Use
get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
when valid h264/hevc values can exceed 8190.
This updates decoding of the following values: (maximum)
first_mb_in_slice 36863* for level 5.2
abs_diff_pic_num_minus1 131071
difference_of_pic_nums_minus1 131071
idr_pic_id 65535
recovery_frame_cnt 65535
frame_packing_arrangement_id 4294967294
frame_packing_arrangement_repetition_period 16384
display_orientation_repetition_period 16384
An alternative would be to modify get_ue_golomb() to handle encoded
values of up to 49 bits as was done for get_se_golomb() in a92816c.
In that case get_ue_golomb() could continue to be used for all of
these except frame_packing_arrangement_id.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '792b9c9dfcf44b657d7854368d975b5ca3bc22ca':
h264: set frame_num in start_frame(), not decode_slice_header()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
According to the spec, the reference list for a slice should be
constructed by first generating an initial (what we now call "default")
reference list and then optionally applying modifications to it.
Our code has an optimization where the initial reference list is
constructed for the first inter slice and then rebuilt for other slices
if needed. This, however, adds complexity to the code, requires an extra
2.5kB array in the codec context and there is no reason to think that it
has any positive effect on performance. Therefore, simplify the code by
generating the reference list from scratch for each slice.
Fixes out of array access
Fixes: 1430e9c43fae47a24c179c7c54f94918/signal_sigsegv_421427_2049_f2192b6829ab6e0eefcb035329c03c60.264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In case of bitstream errors the deblock filter and slices can access uninitialized
top_borders from previous slices which did not fill them as they stoped halfway due
to error or where entirely missing.
This also makes code using these tables deterministic in case of missing or damaged
slices
Found-by: Tyson Smith
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is only used inside libavcodec.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The AVCodecContext.get_format callback is not only used for pixel format
negotiation with the API user, but also for hwaccel init. For the
latter, it's required that some codec parameters, in particular the
codec profile, are set when the callback is invoked.
This patch removes a get_format invocation where this is not guaranteed.
The codec parameters, including the profile, are really set further
below. (The same code path that sets the profile also calls get_format
properly too.)
This just happened to work by coincidence in most cases. For example, if
the API user just copied or reused the AVStream's AVCodecContext when
decoding, the profile would be set properly. But in some cases it
fails., such as with the sample WolfensteinTwitch.mp4 on the samples
server.
Remove the redundant get_format call. Apparently it serves no purpose
anymore, although it is possible that this was different at the time it
was added in commit ffd77f94a2.
This fixes hwaccel usage for API users which do not set the profile
when setting up the AVCodecContext (which is allowed).
Deprecate older VA pixel formats (MOCO, IDCT) as it is now very unlikely
to ever be useful in the future. Only keep plain AV_PIX_FMT_VAAPI format
that is aliased to the older VLD variant.
This is an API change.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
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.
Fixes out of array read
Fixes: asan_heap-oob_394322e_138_cov_4265020547_CVPCMNL1_SVA_C.264
Found-by: Samuel Groß, Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3e3056f2a020dd77efdf379dbd4c06a65b4a499a':
h264: Allow stream and container cropping at the same time
Conflicts:
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The container cropping is applied only when difference is within 16
pixels, and the smallest value between the two is chosen.
Bug-Id: 383
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes out of array access
Fixes: asan_heap-oob_4d5bb0_682_cov_3124593265_Fraunhofer__a_driving_force_in_innovation__small.mp4
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5ec0bdf2c524224f30ba4786f47324970aed4aaa':
h264: do not update the context fields copied between threads after finish_setup()
Conflicts:
libavcodec/h264.h
libavcodec/h264_slice.c
See: f111831ed6 and others
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e49e0f58e273237f83b4486f3536931ed1943d18':
h264: make sure the slices do not overlap during slice threading
Conflicts:
libavcodec/h264.h
libavcodec/h264_slice.c
See: 43b434210e
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also use the frame pixel format instead of the one from the codec
context, which is more robust.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also use the frame pixel format instead of the one from the codec
context, which is more robust.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Inconsistencies between the dimensions/pixel format of avctx and the
frame can confuse API users.
For example this can crash the demuxing_decoding example.
Back up the previous values and restore them, when decoding the next
frame. This is necessary, because these can be different between the
returned frame and the last decoded frame.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The AVFrame values are closer to the AVFrame bitmap changed instead of
the AVCodecContext values, so this should be more robust
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0181ae9af2de1526464d23209b82e6674d362f5d':
h264: Make sure reinit failures mark the context as not initialized
Conflicts:
libavcodec/h264_slice.c
See: e8714f6f93
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7a4f74eed51f914e9bbfebaffd4a92ac6791f819':
h264: embed the DPB in the context
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '88c612e3a4d5b584e2d9f6e2541de78d67bdfb9f':
h264: merge the init and reinit paths in update_thread_context()
Conflicts:
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8a66fd40260b7aae6226d68c4dbad43b05a8e524':
h264: drop the reinit parameter from init_slice_header()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c9ccbc7333eddd025ebbde5cc4f27d68a950c623':
h264: update the current bit depth/chroma type in init_slice_header()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It does not make sense to copy is_avc without copying this as well. This
patch should not change anything for now, but will have an effect in
later commits.
That function currently does two things -- reinitializing the DSP
contexts and setting low_delay based on the SPS values.
The former more appropriately belongs in h264_slice_header_init(), while
the latter only really makes sense in decode_slice_header().
The third call to ff_h264_set_parameter_from_sps(), done immediately
after parsing a new SPS, appears to serve no useful purpose, so it is
just dropped.
Also, drop now unneeded H264Context.cur_chroma_format_idc.
Currently, the DPB is initialized in alloc_tables() and uninitialized in
free_tables(), but those functions manage frame size-dependent
variables, so DPB management does not logically belong in there.
Since we want the init/uninit to happen exactly once per the context
lifetime, init_context()/free_context() are the proper place for this
code.
YCgCo decoding works just fine. It depends on the API user what is done
with the output. Some API users might support it, some not. Some users
might support it under certain circumstances only.
It is not the job of the decoder to print this message. If the API user
supports it, this message is extremely unhelpful.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
previously they where only updated when decoding started and would thus have
been inconsistent for a longer period of time leaving more chances for
problems
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* 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>
* commit '5bf3c0fa49afd5bbf43aa841ff78007d72c80736':
h264: drop the now unused per-slice H264Contexts
Conflicts:
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '51d8725a6e4c7f989d6f0f38b59cb54a2d72846c':
h264: use the main H264Context as the parent for all slice contexts
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '92e0b7342c0490894cbcea4461380321e0569de2':
h264_slice: constify all the uses of H264Context during slice decoding
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* 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 '36d04801ba9d8622c2d759c172aea18561bac74d':
h264: move the scratch buffers into the per-slice context
Conflicts:
libavcodec/h264.h
libavcodec/h264_slice.c
libavcodec/svq3.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f42485dbce614b3f63182845da43db690b427b7c':
h264: use a separate GetBitContext for slice data
Conflicts:
libavcodec/h264.c
libavcodec/h264_cavlc.c
libavcodec/h264_parser.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '404a416d4b1fcbf9db5569481d8181f296c01ea9':
h264: remove some remnants of data partitioning
Conflicts:
libavcodec/h264.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a9b201cacf85d710b102010cb4baef97f00ea39b':
h264: move cabac_init_idc into the per-slice context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e6c90ce94f1b07f50cea2babf7471af455cca0ff':
h264: move loopfilter parameters into the per-slice context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5c8280c3075dd54f26752c3a1185647578421703':
h264: move last_qscale_diff into the per-slice context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e7226984ac13aacb84eae77a372df8ff7685848f':
h264: move [{top,left}_]cbp into the per-slice context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ee0d774dfa94655e44707ff3e02f4a4d282c1963':
h264: move dist_scale_factor[_field] into the per-slice context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '56febc993b928ccc039a32158ca60b234c311875':
h264: move the slice type variables into the per-slice context
Conflicts:
libavcodec/h264.c
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8b00f4df20f4a8ab0656fdaf7d00233a6515a052':
h264: move some neighbour information into the per-slice context
Conflicts:
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd231e84b06a9964c840cff4e228509f706165fb6':
h264: move the quantizers into the per-slice context
Conflicts:
libavcodec/dxva2_h264.c
libavcodec/h264_cavlc.c
libavcodec/h264_loopfilter.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd40ae0e595fe90b5583b9269f8bb000402bde5a6':
h264: do not copy qscale when updating per-thread contexts
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also change the method for allocating them. Instead of two possible
alloc calls from different places, just ensure they are allocated at the
start of each slice. This should be simpler and less bug-prone than the
previous method.
