Otherwise the extradata used would be ISOBMFF if the input is
even though we use the *_mp4toannexb BSFs to convert it to
annex B to feed it to the actual decoder.
(The mediacodec decoders also use said BSFs, yet they process
the extradata in a way that works even when using the ISOBMFF
extradata; in fact, using the converted extradata would break
their check for whether to warn for missing extradata for
the ISOBMFF without-in-band-header profiles.
Furthermore, there are several users of the *_mp4toannexb BSFs
that don't ever touch extradata. They have not been touched.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 1c17061397.
The commit intended to provide certain codecs using *_mp4toannexb
bitstream filters with updated (annex B) extradata (even when
the user-supplied one was ISOBMFF), yet BSFs are allowed to change
way more. The media100_to_mjpegb BSF used by the media100 decoder
changes the codec id; the commit being reverted therefore changed
AVCodecContext.codec_id which is an API violation and broke
media100 decoding with the FFmpeg cli tool.
This commit also made changes from the internal BSF externally
visible. extradata is documented to be "owned by the codec and
freed in avcodec_free_context()" which does not include replacing
it with something else in avcodec_open2() and may surprise users
who think that AVCodecContext.extradata is immutable before
avcodec_free_context(). It also incurred a memdup which is completely
unnecessary for most decoders.
Therefore this commit is reverted. The problem it tried to solve
will be solved differently in the next commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While the current code iterated over the messages, it always returned
in the first iteration. Instead keep iterating and warn for failure to
parse. At time of writing, none of the parsing functions seems to
actually return an error, ever.
Fix CID 1648348
When checking for filmgrain here, needs_fg can be true even when
film_grain_characteristics is NULL (when aom_film_grain.enable is true),
therefore this check could end up dereferencing film_grain_characteristics
even though it is NULL.
Fix CID 1648347
The GetBitContext API requires the buffer to be padded, and the documentation for
av_ac3_parse_header() does not specify it, so use a temporary local buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents potential null pointer dereference when querying
MaxL1ReferencesForB from codec-specific support structures
during GOP structure initialization.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
codec31/32 are similar to codec1/3 (RLE coding) but with two 4-bit pixels
per byte; they are only used in the Sega-CD release of Rebel Assault 1.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some of the calculated values were wrong and/or assigned
to the wrong pixel of the 4x4 block.
Found during testing with Rebel Assault Sega-CD release.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
it has a bug and its effects aren't that noticeable, esp. with
the smoothing applied to the whole picture by modern video display
engines.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The iirfilter is only used in its test tool since
01ecb7172b which
stopped using it in AAC, its only user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also "fixes" the inverted order of arguments in the av_malloc_array()
calls and therefore part of ticket #11620.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(Some more options could be set via this method
if the order in which the options are applied doesn't matter.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We were using a mix of pointers to local variables read via AV_RL32/64 and
pointers directly to the texture buffer as keys to interact with the lookback
hashtables. On big-endian systems, these produced different values. This change
makes all hashtable interactions use direct pointers to the texture buffer and
only invokves AV_RL32 in the event of a lookback hashtable miss.
Signed-off-by: Emma Worley <emma@emma.gg>
It is unnecessary to align both key and val, as they are only accessed
via memcpy()/memcmp(), which has no alignment requirements.
We only need to ensure that that the entries as a whole
are suitable aligned for the probe sequence length.
Reviewed-by: Emma Worley <emma@emma.gg>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise ff_hashtable_freep() would try to free uninitialized
pointers upon allocation error (which happens in the corresponding
test tool).
Reviewed-by: Emma Worley <emma@emma.gg>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Improves compatibility with Resolume products by adding an additional
hashtable for DXT color+LUT combinations, and padding the DXT texture
dimensions to the next largest multiple of 16. Produces identical
packets to Resolume Alley in manual tests.
Signed-off-by: Emma Worley <emma@emma.gg>
Since a51279bbde,
hpeldsp_rnd_template.c was only included once and
one of the two functions in rnd_template.c was
only enabled once.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code to initialize the ungrouped bap mantissa tables
(bap 3 or 5) takes more bytes of .text than the tables itself;
they have therefore been hardcoded.
For GCC (14, -O3, albeit in an av_cold function), the initialization
code takes 99B each for the fixed and floating point decoders
(the code is currently duplicated), whereas the hardcoded tables
only take 96B. For Clang 19 it were 374B each (I don't now what
Clang was doing there).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
