The external library is called libsvtav1, so use this name everywhere.

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

Value was incorrectly changed in 3bf1be21.
Signed-off-by: NZane van Iperen <zane@zanevaniperen.com>

This change makes it possible for child encoders to define custom level
option names which can be used for setting the AVCodecContext->level.

Based on 337fe4bc

Reviewed-by: jkqxz
Signed-off-by: NJames Almer <jamrial@gmail.com>

This patch makes the pgx decoder select the correct
byte order instead of selecting big endian format for
16 bit images.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

This patch allows the JPEG2000 encoder to
encode images to up to 16 bits.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

'li.s' is a synthesized instruction, it does not work properly
when compiled with clang on mips, and A segfault occurred.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Failed fate case: fate-h264-conformance-caba2_sony_e
Clang is more strict in the use of register constraint.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

GCC support these two synthesized instruction, but clang does not yet.
Use machine instruction instead to adapt clang compiler.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Clang report following error in aacsbr_mips.c,ac3dsp_mips.c and aacdec_mips.c:
"couldn't allocate output register for constraint 'r'"

Use 'f' constraint for float variable.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Also query time only once, not for every variant stream, otherwise variant
streams might get a slightly different initial program date time. And we can
set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
elsewhere.
Signed-off-by: NMarton Balint <cus@passwd.hu>

Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Signed-off-by: NMarton Balint <cus@passwd.hu>

This option is directly copy-pasted from the SVT1-HEVC wrapper and has
no place in the options for an AV1 encoder.

AV1 has no H.264/5 IDR frames nor anything like them.
All this option does is change all real keyframes to an intra-only
AV1 frame, which is not seekable. Hence, any streams encoded with
this option enabled will not be seekable.

Signed-off-by: NDaryl Seah <daryl.seah@intel.com>
Signed-off-by: NJing SUN <jing.a.sun@intel.com>
Signed-off-by: NZhiZhen Tang <zhizhen.tang@intel.com>
Signed-off-by: NZhong Li <zhong.li@intel.com>
Signed-off-by: NXu Guangxin <guangxin.xu@intel.com>
Signed-off-by: NJames Almer <jamrial@gmail.com>

instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long,
leading to more code.
Reviewed-by: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

get_ue_golomb_31() reads nine bits and an array with 512 entries to
parse golomb codes. The longest golomb codes that fit into 9 bits use
four leading zeroes and five value bits and can encode numbers in the
0..30 range. 31 meanwhile is encoded on 11 bits and if the nine bits
read coincide with the first nine bits of the encoding of 31,
get_ue_golomb_31() returns 31 (and skips 11 bits).

But looking at the first nine bits only makes it impossible to distinguish
31 from 32..34. Therefore the documentation of get_ue_golomb_31() simply
states that the return value is undefined if the value of the encountered
exp golomb code was outside the 0..31 range.

But actually get_ue_golomb_31() does not behave that bad: If the returned
value is in the range of 0..30, then this is the actually encountered value,
so that this function can be used without any problems to parse and validate
parameters whose legal values are a subset of the 0..30 range.

This commit documents this fact.
Reviewed-by: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the supported range.
For consistency with the uncached bitstream reader and for compliance
with the documentation, every value not in the 0-8190 range is treated as
error although the cached bitstream reader could actually read values in
the range 0..65534 without problems.
Reviewed-by: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Fixes: division by zero
Fixes: 24201/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5665813827420160
Fixes: 24245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6285831682392064

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: NGautam Ramakrishnan <gautamramk@gmail.com>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Nhwren <hwrenx@126.com>
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Said error message is not very informative and lacked a proper logging
context; furthermore, many callers already provided more descriptive
error messages of their own. So just drop this one.
Suggested-by: NJames Almer <jamrial@gmail.com>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

For non-PCM audio, a Smacker frame contains the size of the decoded
audio in the first four bytes of the audio packet data; for PCM data,
said information would be redundant and according to [1] this field does
not exist. Therefore this commit sets the duration and timestamps
properly for PCM audio.

[1]: https://wiki.multimedia.cx/index.php/Smacker#Audio_Track_ChunkSigned-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Add .read_seek function to the smacker demuxer for the special case of
seeking to ts=0. This is useful because smacker – like bink, with a
similar implementation – was mostly used to encode clips in video
games, where random seeks are rare but looping media are common.
Signed-off-by: NTimotej Lazar <timotej.lazar@araneo.si>

libsrt changed the:
SRTO_SMOOTHER   -> SRTO_CONGESTION
SRTO_STRICTENC  -> SRTO_ENFORCEDENCRYPTION
and removed the front of deprecated options (SRTO_SMOOTHER/SRTO_STRICTENC)
in the header, it's lead to build fail

fix #8760
Signed-off-by: NJun Zhao <barryjzhao@tencent.com>

This reverts commit 489c5db0.

Treating EQUAL_MULTI_ROWS in the same way as the arbitrary-size cases is
just wrong.  Consider 9 rows, 4 slices - we pick 4 slices with sizes
{ 3, 2, 2, 2 }, which EQUAL_MULTI_ROWS does not allow.  It isn't possible
to split the frame into 4 slices at all with the EQUAL_MULTI_ROWS
structure - the closest options are 3 slices with sizes { 3, 3, 3 } or 5
slices with sizes { 2, 2, 2, 2, 1 }.

hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
plane swap cases, however duplicate formats are not expected in sw_format
list when merging formats.

For example:
ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \
-f lavfi -i smptebars -vf \
"hwupload=derive_device=vaapi,scale_vaapi,hwdownload,format=yuv420p" \
-vframes 1 -f null -

Without this fix, an auto scaler is required for the above command
   Duplicate formats in ff_merge_formats detected
   [auto_scaler_0 @ 0x560df58f4550] Setting 'flags' to value 'bicubic'
   [auto_scaler_0 @ 0x560df58f4550] w:iw h:ih flags:'bicubic' interl:0
   [Parsed_hwupload_0 @ 0x560df58f0ec0] auto-inserting filter
   'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
   the filter 'Parsed_hwupload_0'
Signed-off-by: NHaihao Xiang <haihao.xiang@intel.com>

This restores the relevant behavior of the function as it was before
3a8e9271.
Signed-off-by: NJames Almer <jamrial@gmail.com>

The size for a previous plane doesn't signal the presence of another after it.
If the plane is present, av_image_fill_plane_sizes() will have returned a size
for it.

Fixes a regression since 3a8e9271.
Reported-by: NImad R. Faiad <irfaiad@gmail.com>
Signed-off-by: NJames Almer <jamrial@gmail.com>

Fixes: OOM
Fixes: 24375/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6216862443241472

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

Up until now, the Sega FILM muxer would first write all the packet data,
then shift the data (in the muxer's write_trailer function) by the amount
necessary to write the header at the front (which entails a seek to the
front), then seek back to the beginning and actually write the header.

This commit changes this: The dynamic buffer that is used to write the
sample table (containing information about each sample in the file) is
now used to write the complete header. This is possible because the size
of everything in the header except the sample table is known in advance.
Said buffer can then be used as one of the two temporary buffers used
for shifting which also reduces the amount one has to allocate for this.
Thereby the header will be written when shifting, so that the second
seek to the beginning is unnecessary.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Up until now, the Sega FILM muxer would store some information about
each packet in a linked list. When writing the trailer, the information
in said linked list would be used to write a table in the file header.
Each entry in said table is 16 bytes long, but each entry of the linked
list is 32 bytes long (assuming 64 bit pointer and no padding).
Therefore it makes sense to remove the linked list and write the array
entries directly into a dynamic buffer while writing the packet (this is
possible because the table entries don't depend on any information not
available when writing the packet (the offset is not relative to the
beginning of the file, but to the end of the table). This also
simplifies writing the array at the end (there is no need to traverse a
linked list).
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Use avio_wb16() instead of avio_write() to write two zero bytes.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>