We queried the decoder whether it was able to decode sucessfully, but
since we operated asynchronously, we weren't able to do anything with
this information but let the user know decoding failed for the previous
frame(s).
Since we parse the slice headers ourselves and we're reasonably sure we
can decode before actually starting to decode, this was rarely triggered
on corrupt data, and hardware's understanding of whether there was an error
or not is vague.
There's also a semantic problem with our use of the queries - if there's
a seek, we flush, but what happens to the queries is vague according to
the spec. Most hardware dealt fine, since queries are nothing more than
GPU memory with integers stored. But with Intel, they seem to be more of
a register to which a driver must keep track of, leading to issues if there's
been a reset (seek) and we query the previous submission before the seek.
Just get rid of them. The query code is still used in encoding.
This fixes seeking with HEVC and AV1 on Intel.
The issue is that some compilers complain if a struct or array
is empty.
This extension does nothing by default, and can be useful, so just add it
to keep the array non-empty.
Adds a decoder for the SMUSH codec48 video encoding, as is used by
the LucasArts game "Mysteries of the Sith".
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The string type is a remnant of the old channel layout API implementation.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
In some MSYS environments it can happen that the 3 argument syntax
for pkg-config library specifications fails because somehow the
expansion of pkg_version ends up with a redirection we guess.
To avoid failures like in the referenced build[2], we quote it
so the whole module including operators will be expanded into
a single shell word and the single argument syntax for specifying
the library for pkg-config will be used.
The single argument syntax seems to be supported by the original
pkg-config from the beginning more than 20 years[3].
In the pkgconf implementation single argument syntax was supported
pretty much from the beginning as well. The multiple argument syntax
we used until this change, was not supported until a change[4] more
than 10 years ago.
References
----------
1. Build passing with quotes:
https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12358403929
2. Build failing without quotes:
https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12360472377
3. Earliest commit of the current pkg-config Git repo already mentions the single argument syntax:
2ac96cbcc7 (124c0becfe68b1ef671f49ed2b9d24779ace126f_0_162)
4. pkgconf gets support for 3 argument syntax (pkgconf --exists liba = 1.2.3):
793de6a06c
Commit-message-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Joe Schiffler <joeschiffler3@gmail.com>
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Fixes: signed integer overflow: 24320 + 9223372036854775573 cannot be represented in type 'long'
Fixes: 71001/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5644785744936960
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninintialized value
Fixes: 70993/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6378949754552320
Fixes: 71104/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5001538727116800
For the AAC/USAC/SBR code which reads uninitialized memory, it would be good, if it did not
a fix for that is welcome!
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70992/clusterfuzz-testcase-minimized-ffmpeg_dem_IMAGE2_fuzzer-5735819170611200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70988/clusterfuzz-testcase-minimized-ffmpeg_dem_IVR_fuzzer-5298245077630976
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This occurs on a 32x32 input
Fixes: use of uninitialized value
Fixes: 70897/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5960860961406976
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code following makes no attempt to initialize all of the buffer
Fixes: use of uninitialized value
Fixes: 70980/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5329909059223552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70932/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4870202133643264
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A sample rate <= 0 is invalid.
Fixes an assert in ffmpeg_enc.c that assumed a valid sample rate would be set.
Fixes ticket #11385.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: use-of-uninitialized-value
Fixes: 383170476/clusterfuzz-testcase-minimized-ffmpeg_dem_MLV_fuzzer-4696002884337664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Fixes: 377971441/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4966030696316928
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should ensure avcodec_send_packet() doesn't return EAGAIN in scenarios where it's not
meant to (e.g., ffmpeg_dec.c where avcodec_receive_frame() is called in a loop to drain
all produced frames before trying to submit more packets).
Fixes ticket #11377.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
This implementation maintains some backwards compatibility by only
writing the track information for track indices > 0. This means that
older FFmpeg versions - and possibly other software - can still read the
first video track properly and skip over unsupported packets.
Signed-off-by: Dennis Sädtler <dennis@obsproject.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This has the downside of requiring these tables to be recomputed on every
init, but saves ~270 kB of static data.
Signed-off-by: Niklas Haas <git@haasn.dev>
The current logic uses 12-bit linear light math, which is woefully insufficient
and leads to nasty postarization artifacts. This patch simply switches the
internal logic to 16-bit precision.
This raises the memory requirement of these tables from 32 kB to 272 kB.
All relevant FATE tests updated for improved accuracy.
Fixes: #4829
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
It makes no difference when the input has an alpha plane, and may end up in
crashes or undefined behavior if it doesn't.
Signed-off-by: James Almer <jamrial@gmail.com>
Lynne
Manuel Lauss
James Almer
Joe Schiffler
Michael Niedermayer
Timo Rothenpieler
Dennis Sädtler
Niklas Haas