* commit '7b50d60442af8d9527e9da46818011fe15a5265a':
h264: call ff_h264_fill_mbaff_ref_list() when constructing the normal ref list
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '77a1e2c5f8f8250dfacff24b993eb473260ed13e':
h264: move direct mode inits out of h264_slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
This should not be needed anymore and simplifies the next merge
Requested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should not be needed anymore and simplifies the next merge
Requested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a more appropriate place for this. H264Context.recovery_frame is
shared between frame threads, so modifying it where it is right now is
invalid.
Move the NAL unit types into it. This will allow to stop including the
whole decoder-specific h264dec.h in some code that is unrelated to the
decoder and only needs some enum values.
Right now this code is mixed with selecting the next output frame. Move
it to a separate function called from h264_field_start(), which is a
more appropriate place for this.
While the value of those variables will be constant for the whole frame,
they are only used in two functions called from slice header decoding.
Moving them to the per-slice context allows us to make the H264Context
passed to slice_header_parse() constant.
There is no bitstream parsing in that block and messing with
decoder-global state is not something that belongs into header parsing.
Nothing else in this function depends on the value of current_slice,
except for two validity checks. Those checks are also moved out of
slice_header_parse().
Replace the decoder-global nal_unit_type/nal_ref_idc variables with the
per-NAL ones. The decoder-global ones still cannot be removed because
they are used by hwaccels.
* commit 'e0652795292223f8bc8e5bac019c1fca7323d23c':
h264: remove an artificial restriction on the number of slice threads
Tested with multiple runs of fate-h264 THREADS=50 THREAD_TYPE=slice
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit 'b77fffa127663028169c5ed543956af4b9496c29':
h264: make slice threading work with deblocking_filter=1
again label, and SLICE_SINGLETHREAD error handling are preserved as that
SLICE_SINGLETHREAD can be raised on a remaining case.
slice_context_count is also kept since it's still in use.
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '99c554efc8b09c3f1bb2fb41c3da5431085f7470':
h264: eliminate low_delay
ff_print_debug_info2() is adjusted to allow a NULL pointer as low_delay.
It's only useful for MPEG codecs with the exception of H264.
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '0ba471d7d864c712f45d7ac6aca4829aba025adc':
h264: eliminate copy_fields
Added a copy of default_ref which isn't present in Libav.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '728d90a0c1973661a9e73da697bf4f90c9d19577':
h264: decouple h264_sei from the h264 decoder
Main changes:
- SEI decoding doesn't have access to the debug flag in the codec context so a
few logging are dropped.
- naming of quincunx_sampling_flag and frame_packing_arrangement_type are kept
as they are in FFmpeg instead of respectively quincunx_subsampling and
arrangement_type used in Libav because the former match the specifications.
- don't reset the x264 build info once read in order to fix
fate-h264-lossless (change by Hendrik)
- H264Context.has_recovery_point and deprecated
AVCodecContext.dtg_active_format are set after ff_h264_sei_decode()
based on the SEI state since ff_h264_sei_decode() doesn't have access
to H264Context anymore.
- frame_packing_arrangement_type is not checked against <= 0 in
decode_postinit() since it is always read as a positive value with
get_bits(). This fixes a -Wtype-limits warning by GCC spotted by
Michael.
Side Notes:
- tested that ffprobe on the file from ticket #3652 still returns 4
keyframes
- tested that playback from ticket #3063 still works
Merged-by: Clément Bœsch <clement@stupeflix.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
The only difference is that the first of them contains a
ff_h264_flush_change() call. While that is not necessary in the second
block, it should cause no problems either.
Reduce the verbosity of the reinit log message from info to verbose,
since now it will be displayed during every decode session.
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().
They are stored in the slice header, so technically they are per-slice
(though they must be the same in every slice). This will simplify the
following commits.
