The code only set the channel layout of the AVFormatContext, so the user could
not override the channel layout if the demuxer did not have such parameter.
This used to work via the respective AVCodecContext option, but since
639c2f0049 it no longer gets passed to the
decoders. It is actually better if we set it manually, instead of using the
codec option because that way we can also override it on the stream level, so
it will also work for stream copy or bitstream filtering.
We don't allow changing the number of channels, because that can cause
unexpected results. We disable layout guessing, if a channel layout is
specified.
Fixes ticket #11016.
Signed-off-by: Marton Balint <cus@passwd.hu>
Do this by attaching the FilterGraph directly to more permanent
storage from which it will be automatically freed.
Fixes Coverity issue #1596533.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This probably makes no difference but its more correct
Fixes: CID1503080 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Both the codecpar's width and height, and the SAR num and den are
ints, which can overflow. Cast to int64_t, which is what av_reduce
takes.
Without this, occasionally, display_aspect_ratio can be negative in
ffprobe's -show_stream output.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This allows one complex filtergraph's output to be sent as input to
another one, which is useful in certain situations (one is described in
the docs).
Chaining filtergraphs was already effectively possible by using a
wrapped_avframe encoder connected to a loopback decoder, but it is ugly,
non-obvious and inefficient.
The decision whether -apad actually does anything is made based on muxer
properties, and so more properly belongs there. Filtering code only
receives the result.
Instead pass the encoder through a newly-added output options struct,
analogous to previously added input options.
Will allow decoupling filtering from encoding in future commits.
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>
C11 required to use ATOMIC_VAR_INIT to statically initialize
atomic objects with static storage duration. Yet this macro
was unsuitable for initializing structures [1] and was actually
unneeded for all known implementations (this includes our
compatibility fallback implementations which simply wrap the value
in parentheses: #define ATOMIC_VAR_INIT(value) (value)).
Therefore C17 deprecated the macro and C23 actually removed it [2].
Since commit 5ff0eb34d2 we default
to C17 if the compiler supports it; Clang warns about ATOMIC_VAR_INIT
in this mode. Given that no implementation ever needed this macro,
this commit stops using it to avoid this warning.
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_485
[2]: https://en.cppreference.com/w/c/atomic/ATOMIC_VAR_INIT
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
lavfi does not require aligned buffers, so we can safely apply top/left
cropping by any amount, without passing any special flags to lavc.
Longer term, an even better solution would probably be auto-inserting
the crop filter (or its hwaccel versions) as needed.
Multiple FATE tests no longer need -flags unaligned.
Marton Balint
Andreas Rheinhardt
Michael Niedermayer
Derek Buitenhuis
James Almer
Zhao Zhili
Anton Khirnov