Instead of handling the problem inside NAL decoding code, add a higher
level wrapper function. This should be more robust against future
changes (and easier to read).

It is shared with svq3.

This will allow decoupling the parser from the decoder.

The profiles are a property of the codec, so it makes sense to export
them through AVCodecDescriptors, not just the codec implementations.

Fall back to maximum DPB size if the level is unknown.

This should be more spec-compliant and does not depend on the caller
setting has_b_frames before opening the decoder.

The old behaviour, when the delay is supplied by the caller setting
has_b_frames, can still be obtained by setting strict_std_compliance
below normal.

This makes the h.264 decoder threadsafe to initialize.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

There is not much reason to generate such a small table at runtime.

Signed-off-by: Derek Buitenhuis <derekb@vimeo.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Partially amends 9469370fb3

And report why it fails.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

When skip_frame is set to _NONKEY the decoder skips everything except intra
slices, which breaks frames that consist of an intra field together with any
other field type; half the frame becomes garbage. This patch fixes the issue by
letting non-intra slices through if they're part of a keyframe.

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

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Express bitfields more simply.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Convert doxygen to multiline and express bitfields more simply.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Partially based on code by Marton Balint and Kieran Kunhya.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Should fix a large number of possible races with frame threading.

It now has a fixed size and is initialized only once, so there is no
point in allocating it separately.

It does not logically belong in free_tables(), since it's not allocated
in alloc_tables() and its size has nothing to do with the frame size.

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.

It is only set, but never used for anything.

It is not needed anymore since switching to refcounted frames.

The generic code copies the main context's private data to all the
others. However that is quite dangerous, as it might end up copying some
pointers that are or will become invalid.

Since everything we actually need will be copied later in
update_thread_context(), it's safest to zero the private data in
init_thread_copy(), so it works the same way as init for the main
context.

It will always be initialized when actually parsing the PPS.

There is no real advantage to initializing any of those in init,
assuming yuv420, before the real stream parameters are known.

This makes sure the various DSP contexts get properly initialized in
ff_h264_set_parameter_from_sps() whatever the value of
raw_bits_per_sample.

The way it is currently designed is fundamentally unsafe and cannot be
reasonably fixed without completely rewriting it.

This code makes no sense for h.264.

There is now no need to have per-slice copies of the H264Context.

h264dec does not use them at all and only allocates them for ER.

Also change the method for allocating to the same one as used by
edge_emu_buffer.

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.

All the variables modified by this code are either per-MB arrays or have
been moved to the per-slice context

Use a local variable instead.