This is a more appropriate place for it.

Doing this after ff_thread_finish_setup() is called is invalid and can
conflict with reads from the other thread.

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.

Copy them into the decoder-global context in field_start(). This avoids
modifying the decoder-global context during bitstream parsing.

Avoid unnecessary modification of the decoder-global state in per-slice
code.

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.

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Transparency is supported only by YUV and within specific bit depths.

The tests are inspired by similar tests for vp9 by
Ronald Bultje.
Signed-off-by: Martin Storsjö <martin@martin.st>

This function needs to return false, or data in the additional tables
will be skipped, and the decoder will not be able to decode frames
associated with them.

Store data from each stsd in a separate extradata buffer, keep track of
the stsc index for read and seek operations, switch buffers when the
index differs. Decoder is notified with an AV_PKT_DATA_NEW_EXTRADATA
packet side data.

Since H264 supports this notification, and can be reset midstream, enable
this feature only for multiple avcC's. All other stsd types (such as
hvc1 and hev1) need decoder-side changes, so they are left disabled for
now.

This is implemented only in non-fragmented MOVs.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Martin Storsjö <martin@martin.st>

This mimics the behaviour of other av_*_new_side_data().
This is not caught by the malloc check, since padding
is always added to the allocated size.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

It does not need the whole context. This will simplify the following
commit.

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.

The variable stores the number of mmco entries, so the current name is
misleading.

This function does not do any bitstream parsing and it depends on the
current frame being allocated, so this will allow the frame_start() to
be moved out eventually.

This does not do any bitstream parsing and will allow moving out other
code in later commits.

It depends on the reference list, so this will allow moving out the
reference list construction and consequently other code it depends on.

This will allow postponing the reference list construction (and by
consequence some other functions, like frame_start) until the whole
slice header has been parsed.

Do it where the normal implicit table is initialised.

There is no real reason to call it separately.