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>
h264.h and hevc.h are mutually exclusive due to defining some of the same
names. As such, we need to avoid forcing h264.h to be included if we want
hevc decode acceleration to be possible.
However, some of the pre-hwaccel helper functions need h264.h. To avoid
messy collisions, let's move the declaration of all those helpers to
a separate header which we will exclude for the hevc support (which will
be hwaccel-only).
Signed-off-by: Philip Langdale <philipl@overt.org>
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.
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.
ER with slice threads is buggy and since the merge of the libav cleanup broken
as the ER context which is supposed to be per frame has been placed in
the slice context, so there are multiple per frame which does not work as is.
Theres no bug report about ER with frame threads. If someone knows of a
case where it crashes / fails without slice threads please mail me and
open a ticket on trac.
Signed-off-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.
Kieran Kunhya
Carl Eugen Hoyos
Vittorio Giovara
Anton Khirnov
Kieran Kunhya
Andreas Cadhalpun
Philip Langdale
Michael Niedermayer
James Almer
Rainer Hochecker