Fixes: NULL pointer dereference
Fixes: 45955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-4842044192849920

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

So I can merge my own changes to this filter after they pass peer
review, as well as keeping it in sync with upstream API changes / new
features.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: division by zero
Fixes: 45811/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-6412592581574656
Fixes: 45979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-5362043060879360

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

av_channel_layout_index_from_channel() takes an AVChannel value, not a mask.
Signed-off-by: James Almer <jamrial@gmail.com>

av_buffersrc_parameters_set() can be called to set paramenters after the filter
was initialized with for example avfilter_graph_create_filter().
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: signed integer overflow: -5 - 9223372036854775807 cannot be represented in type 'long'
Fixes: 45665/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-475618463934054

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: division by 0
Fixes: 45643/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4957777905188864.fuzz

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout
Fixes: 45543/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5684953164152832

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

This search takes alot of time especially when compared with small packets

46631 decicycles -> 15719 decicycles in read_frame_internal() for amr-nb in 3gp
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: division by 0
Fixes: 45615/clusterfuzz-testcase-minimized-ffmpeg_dem_ALP_fuzzer-582660348405350
Fixes: 45625/clusterfuzz-testcase-minimized-ffmpeg_dem_ALP_fuzzer-4821437943250944
Fixes: 45839/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5857286998851584.fuzz
Fixes: 45844/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6552705772945408

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Similar to how a frame is considered for referencing for the RefPicList array.
This will do the same for RefPicSetStCurrBefore, RefPicSetStCurrAfter and
RefPicSetLtCurr.

Fixes playback of http://www.gbbsoft.pl/!download/!/Film1.mp4
Ref. VLC issue https://code.videolan.org/videolan/vlc/-/issues/26738Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>

7-bit PictureIDs are not supported by WebRTC:
https://groups.google.com/g/discuss-webrtc/c/333-L02vuWA

In practice, 15-bit PictureIDs offer better compatibility.
Signed-off-by: Kevin Wang <kevin@muxable.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Since mkvmerge 19 has fonts types from RFC 8081 and mkvmerge 58 on windows use new file/magic library.
Signed-off-by: SomeRGuy <wwakabot@gmail.com>

No point running all 64 iterations in the loop to never write anything to ret.
Also make ambisonic layouts check its mask too while at it.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

This comment only applies to the scenario in which one uses
the AVCodecContexts embedded in AVStreams. Yet this code sample
stopped doing so in 9897d9f4;
and the last major version bump even removed the public
AVCodecContexts in AVStreams. So just remove this comment.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Modifying the main context by a slice thread is racy;
so constify the pointer to it in H264SliceContext.
The code itself was already compatible with this change.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Since 7be2d2a7 only one context
is used. Moving it to H264Context from H264SliceContext is natural.

One could access the ERContext from H264SliceContext
via H264SliceContext.h264->er; yet H264SliceContext.h264 should
naturally be const-qualified, because slice threads should not
modify the main context. The ERContext is an exception
to this, as ff_er_add_slice() is intended to be called simultaneously
by multiple threads. And for this one needs a pointer whose
pointed-to-type is not const-qualified.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

ff_er_frame_start() initializes ERContext.error_count
to three times the number of macroblocks to decode.
Later ff_er_add_slice() reduces this number by the amount
of macroblocks whose AC resp. DC resp. MV have been finished
(so every correctly decoded MB counts three times).
So the frame has been decoded correctly if error_count is zero
at the end.

The H.264 decoder uses multiple ERContexts when using
slice threading and therefore combines these error counts:
The first slice's ERContext is intended to be initialized
by ff_er_frame_start(), error_count of all the other
slice contexts is intended to be zeroed initially and
all afterwards all the error_counts are summed.

Yet commit 43b43421
(probably unintentionally) changed the code to set
the first slice's error_count to zero as well.
This leads to bogus error messages in case one decodes
an input video using multiple slices with slice threading
with error concealment enabled (which is not the default)
("concealing 0 DC, 0 AC, 0 MV errors in [IPB] frame");
furthermore the returned frame is marked as corrupt as well
(ffmpeg reports "corrupt decoded frame in stream %d" for this).

This can be fixed easily given that only the first ERContext
is really used since 7be2d2a7:
Don't reset the error_count; and don't sum the error counts as well.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Should increase test coverage
Signed-off-by: James Almer <jamrial@gmail.com>

Should increase test coverage a bit
Signed-off-by: James Almer <jamrial@gmail.com>

Should increase test coverage.
Signed-off-by: James Almer <jamrial@gmail.com>

avutil/tests/channel_layout: test generating a custom layout using ambisonic channels and a non diegetic channel with a custom name

Should increase test coverage a bit
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Prevents printing "user -1" on invalid channel ids.
Signed-off-by: James Almer <jamrial@gmail.com>

Look for the generic "USR" labels instead of "?" to skip channels with no
known names, and actually print the decomposition of standard channel layouts.
Signed-off-by: James Almer <jamrial@gmail.com>

Instead fallback to print USR%d for channels id < 64 without a known name.
Signed-off-by: James Almer <jamrial@gmail.com>

A private encoder option 'quality' was added in 716674b1, making
the doc entry obsolete.