It's not an error since bba6df9a.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The MIME type field is required per the FLAC standard, but it's
not an error just because ffmpeg doesn't recognize it.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Depending on the filters used, the filtergraph may produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergraph.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>

Depending on the filters used, the filtergraph may produce trailing data
after feeding it the last input frame. Update the example to include the
necessary loop for draining the filtergraph.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>

The "RIFF" identifier and chunk size fields should not be included
within the size value.

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 5ff0eb34 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_INITSigned-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is no longer accessed outside of ffmpeg_demux.

All side data should be propagated through the trancoding pipeline.

This way it can be automagically propagated through the encoder to
muxing.

It will be shared with encoding code.

It is highly unsafe, as AVCodecContext contains many allocated fields.
Almost everything needed by worker threads should be covered by
routing through AVCodecParameters and av_opt_copy(), except for a few
fields that are copied manually.

avcodec_free_context() can now be used for per-thread contexts.

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.

Avoids abusing AV_DICT_MULTIKEY and relying on undocumented AVDictionary
ordering behaviour.

Do not pass an options dictionary to avcodec_open2().

This should be equivalent to current behaviour, but will allow
overriding caller-supplied options in a cleaner and more robust manner.

We can now set the COPY_OPAQUE flag directly rather going through
dec_opts.

There is only a single caller of filter_codec_opts() that passes
a NULL codec to it, which is streamcopy in ffmpeg CLI. In that case we
only want generic AVCodecContext options, not private options of any
specific encoder.

It is pointless otherwise, as decoder options will not be used.

Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

A pointer conversion is UB if the resulting pointer is not
correctly aligned for the resultant type, even if no
load/store is ever performed through that pointer (C11 6.3.2.3 (7)).

This may happen in opt_copy_elem(), because the pointers are
converted even when they belong to a type that does not guarantee
sufficient alignment.

Fix this by deferring the cast after having checked the type.
Also make the casts -Wcast-qual safe and avoid an indirection
for src.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is not documented to be safe and in any case it is nonsense:
Currently av_strdup(NULL) returns NULL and in order to distinguish
this from a genuine allocation failure, opt_copy_elem()
checked afterwards whether src was actually NULL. But then one
can simply check in advance whether one should call av_strdup()
at all.
set_string() was even worse and returned ENOMEM in case the value
to be duplicated is NULL; this only worked because
av_opt_set_defaults2() does not check the return value at all
(given that it can't propagate it).

These two places account for 389114 of 390356 av_strdup(NULL)
calls during one FATE run.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Forgotten in 8238bc0b.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is undefined behaviour to call a function with a different
signature for the call than the actual function signature;
there are no exceptions for void* and RateControlEntry*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Do not return the return value of the last enc_send_to_dst()
call, as this would treat the last call differently from the
earlier calls; furthermore, sch_enc_send() explicitly documents
to always return 0 on success.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Doing this with REDUCE_FORMATS() instead of swap_color_*() is not only
shorter, but more importantly comes with the benefit of being done
inside a loop, allowing us to correctly propagate complex graphs
involving multiple conversion filters (e.g. -vf scale,zscale).

The latter family of swapping functions is only used to settle the
best *remaining* entry if no exact match was found, and as such was
never the correct solution to YUV colorspaces, which only care about
exact matches.

The VP9 spec defines a SmDm box for this information, and the ISOBMFF spec defines a
mdvc one. If both are present, just ignore one of them.
This is in line with clli and CoLL boxes.

Fixes ticket #10711.
Signed-off-by: James Almer <jamrial@gmail.com>

Forgotten in 41058992,
4c92fc02.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Fixes: out of array write
Fixes: 64407/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-4966763443650560

mp4toannexb_filter counts the number of bytes needed in the first
pass and allocate the memory, then do memcpy in the second pass.
Update sps/pps size in the loop makes the count invalid in the
case of SPS/PPS occur after IDR slice. This patch process in-band
SPS/PPS before the two pass loops.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

The test depends on the compile option of x265. It failed when
HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled
because of memory issue inside of x265, which I don't think can
be fixed within FFmpeg.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

There is no need to free the already-added items, they will be freed
alongside the codec context. There is also little point in an error
message, as the only reason this can fail is malloc failure.

Nothing about this code is video-specific.

Skip those side data types that do not make sense as global side data.

They allow exporting extended information about side data types.