Make sure it's not zero, and equal or bigger than number of channels
Fixes: Timeout / DOS
Fixes: 67143/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-4858720481771520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Also make the iso_channel_position table consistent with what the AAC decoder
uses in avcodec/aac/aacdec_usac.c.
Fate changes are caused by the change of how 7.1 layout is mapped, previously
it included Side Surround channels, now it includes the Surround channels.
Signed-off-by: Marton Balint <cus@passwd.hu>
Previously we always assumed that the channels are in native order, even if
they were not. The new channel layout API allows us to signal the proper
channel order, so let's do so.
Signed-off-by: Marton Balint <cus@passwd.hu>
We can do this by using an X-macro for channel map declaration and doing a
static_assert() in one pass for the check. Thanks for Andreas Rheinhardt for
the suggestion.
Signed-off-by: Marton Balint <cus@passwd.hu>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Previously we always assumed that the channels are in native order, even if
they were not. The new channel layout API allows us to signal the proper
channel order, so let's do so.
Fixes ticket #98.
A lot of changes and fixes to channel layout parsing, notably
- get rid of dynamic allocation of channel positions
- signal unimplemented speaker positions as unknown instead of failure, but
warn the user about it
- native order, and that a single channel only appears once was always assumed
for less than 64 channels, obviously this was incorrect
Signed-off-by: Marton Balint <cus@passwd.hu>
The channel designation metadata should not override the number of channels.
Let's warn the user if it is inconsistent, and keep the channel layout
unspecified.
Before the conversion to the channel layout API the code only set the mask, but
never overridden the channel count, so this restores the old behaviour.
Signed-off-by: Marton Balint <cus@passwd.hu>
Existing code could have caused wrong channel order signalling or reduced
channel count if a channel designation appeared multiple times. This is
actually an old bug, but the conversion to the new channel layout API made it
visible, because now the code overrides the proper channel count with the one
calculated from the mask.
Signed-off-by: Marton Balint <cus@passwd.hu>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
ISO C restricts enumerator values to the range of int. Thus (for instance) 0x80000000
unfortunately does not work, and throws a warning with -Wpedantic on
clang 3.7.
This fixes it by using alternative expressions that result in identical
values but do not have this issue.
Tested with FATE.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Otherwise the loop can take a lot of time if num_descr is very large.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Problem found using ASAN.
In some case, the ff_mov_get_channel_layout_tag function will not find 0
as termination for lookup in the array mov_ch_layouts_wav.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If regularly parsing new chan atoms (as in rtpdec_qt), but the
chan atoms don't actually contain any channel layout, don't reset
the value that the caller has filled in (by guessing).
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes crashes when called from rtpdec_qt, where
AVFormatContext->pb is null, a crash present since 3bab7cd128.
Signed-off-by: Martin Storsjö <martin@martin.st>
This implements reading the tag in the demuxer and adds support for writing it
in the muxer. Some example channel layout tables for muxing are included for
ac3, aac, and alac, but they are not utilized yet.
James Almer
Marton Balint
Andreas Rheinhardt
Tong Wu
Zhao Zhili
Vittorio Giovara
Anton Khirnov
Clément Bœsch
Diego Biurrun
Ganesh Ajjanagadde
Andreas Cadhalpun
Reimar Döffinger
Thilo Borgmann
Thierry Foucu
Justin Ruggles
Martin Storsjö
Samuel Pitoiset
Carl Eugen Hoyos
Alex Converse