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>
* qatar/master:
mov_chan: Only set the channel_layout if setting it to a nonzero value
mov_chan: Reindent an incorrectly indented line
mp2 muxer: mark as AVFMT_NOTIMESTAMPS.
x86: float_dsp: fix ff_vector_fmac_scalar_avx() on Win64
x86: more specific checks for availability of required assembly capabilities
x86: avcodec: Drop silly "_mmx" suffix from dsputil template names
fate: Drop redundant setting of FUZZ to 1
cavsdsp: set idct permutation independently of dsputil
x86: allow using add_hfyu_median_prediction_cmov on any cpu with cmov
Conflicts:
libavcodec/x86/dsputil_mmx.c
libavformat/mp3enc.c
Merged-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>
* qatar/master:
mov_chan: Pass a separate AVIOContext for reading
af_asyncts: check return value from lavr when flushing.
mss2: simplify loop in decode_rle()
mss12: avoid unnecessary division in arith*_get_bit()
mss2: do not try to read too many palette entries
mpegvideo: set AVFrame fields to NULL after freeing the base memory
configure: Set the right cc_e flags for msvc
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
Marton Balint