When ret is checked here, it was never assigned anything, making this
check useless, as highlighted by Coverity.
It seems to be a copy paste mistake given that opt_match_per_stream_str
does not return an error code that could be checked and the previous
value assigned to ret is already checked above. So just remove this
check.
Fixes: CID1616292
This is no longer needed, since we now correctly negotiate the required
range from the mjpeg encoder via avcodec_get_supported_config().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The only meaningful difference between choose_pix_fmts and the default
code was the inclusion of an extra branch for `keep_pix_fmt` being true.
However, in this case, we either:
1. Force the specific `ofp->format` that we inherited from
ofilter_bind_ost, or if no format was set:
2. Print an empty format list
Both of these goals can be accomplished by simply moving the decision
logic to ofilter_bind_ost, to avoid setting any format list when
keep_pix_fmt is enabled. This is arguably cleaner as it moves format
selection logic to a single function. In the case of branch 1, nothing
else needs to be done as we already force the format provided in
ofp->format, if any is set. Add an assertion to verify this assumption
just in case.
(Side note: The "choose_*" family of functions are arguably misnomers,
as they should really be called "print_*" - their current behavior is to
print the relevant format lists to the `vf/af_format` filter arguments)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Niklas Haas <git@haasn.dev>
Having macros initialize local variables seems strange to me, and there
are no more current users of these macros. (The one that was commented
out was incorrect anyway, since the macro has changed in the meantime)
While rewriting this macro, I decided to make it a bit more flexible so
it can work for all of the fields (including future fields) in a more
generic way, and to also print the channel layout using an AVBPrint to
avoid hard-coding the assumption that the length is less than 128
characters.
Fix "ost->st->avg_frame_rate = ost->frame_rate" in streamcopy_init()
being reset to input's frame rate a few lines below.
Note that in current code, there are some discrepancies amongst the
muxers. For example, avienc relies on time_base, so it is not affected
by this patch, whereas mxfenc and matroskaenc do use avg_frame_rate,
so this patch fixes -r being honored.
In the updated fate test, the input is (wrongly) probed as 50fps. With
this patch, the correct value (25fps) is successfully forced with -r.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Since ffmpeg 6.1 video stats are accidentally hidden from streamcopy progress output.
This patch re-enables video stats (like frames=) in the progress output.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Makes optional map handling less hacky, fixes combining optional maps
with metadata matching on tags/values containing the '?' character/
Forward errors from stream specifier parsing, previously the code would
ignore them.
This approach has the major advantage that only parsing can fail (due to
a malformed specifier or memory allocation failure). Since parsing is
done generically, while matching is per-option, this will allow to
remove substantial amounts of error checking code in following commits.
The new code also explicitly allows stream specifiers to be followed by
additional characters, which should allow cleaner handling of optional
maps, i.e. -map <stream_specifier>?, which is currently implemented in a
hacky way that breaks when the stream specifier itself contains the '?'
character (this can happen when matching metadata). It will also allow
further extending the syntax, which will be useful in following commits.
This introduces some minor behaviour changes:
* Matching metadata tags now requires the ':' character in keys or
values to be escaped. Previously it could not be present in keys, and
would be used verbatim in values. The change is required in order to
know where the value terminates.
* Multiple stream types in a single specifier are now rejected - such a
specifier makes no sense.
* Non-existent stream group ID or index is now ignored with a warning
rather than causing a failure. This is consistent with program
handling and is required to make matching fail-free.
Stream specifiers were originally designed exclusively for CLI use and
were not intended to be public API. Handling them in avformat places
major restrictions on how they are used. E.g. if ffmpeg CLI wishes to
override some stream parameters, it has to change the demuxer fields
(since avformat_match_stream_specifier() does not have access to
anything else). However, such fields are supposed to be read-only for
the caller.
Furthermore having this code in avformat restricts extending the
specifier syntax. An example of such an extension will be added in
following commits.
This has multiple advantages:
* The macro has multiple parameters that often have similar or identical
values, yet very different meanings (one is the name of the
OptionsContext member where the parsed options are stored, the other
the name of the variable into which the result is written); this
change makes each of these explicit.
* The macro returns on failure, which may cause leaks - this was the
reason for adding MATCH_PER_STREAM_OPT_CLEAN(), also ost_add()
currently leaks encoder_opts. The new function returns failure to its
caller, which decides how to deal with it. While that adds a lot of
error checks/forwards for now, those will be reduced in following
commits.
* new code is type- and const- correct
Invocations of MATCH_PER_STREAM_OPT() with other types will be converted
in following commits.
Fixes an issue in 6.1 when reading a corrupted file with -xerror would
exit with success. This specific issue is not present in master, but
this should generally be a more robust behaviour.
Reported-by: Andrej Peterka
Do not pass an options dictionary to the avcodec_open2() in enc_open().
This is cleaner and more robust, as previously various bits of code
would try to interpret the contents of the options dictionary, with
varying degrees of correctness. Now they can just access the encoder
AVCodecContext directly.
Cf. 372c78dd42 - analogous change for
decoding.
A non-progressive field order is now written on the container level in
interlaced ProRes encoding tests.
Share the code between encoding and decoding. Instead of checking every
stream's options dictionary (which is also used for other purposes),
track all used options in a dedicated dictionary.
Not sure this change makes sense, the code is more robust with ret set
Fixes: CID1559178 Unused value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-while-revieweing: CID1520670 Dereference after null check
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: CID1591932 Ignoring number of bytes read
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The API was committed a few days ago, so changing this field now
is within the realms of acceptable.
ffprobe is meant to generate parseable output, and if a field is present, it
should be printed even if it has a default value.
Signed-off-by: James Almer <jamrial@gmail.com>
Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.
Co-authored-by: Christian Bartnik chris10317h5@gmail.com
Signed-off-by: Thomas Siedel <thomas.ff@spin-digital.com>
Currently it may return an uninitialized value.
Introduced in 840f2bc18e.
Fixes Coverity issue #1603565.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
issue found while reviewing CID1452612 Free of array-typed value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
