The DOS/Windows decoder precomputes a table of linear offsets of
all motion vectors given the current image width.
For larger widths (>=762), the pairs starting at indices 1 and 254
of motion_vectors[] will overflow the int16_t, changing the sign.
Playing back the 800x600 "jonesopn_8.snm" video of "Indiana Jones and
the Infernal Machine" reveals a lot of artifacts and a lot of
"Ignoring invalid motion vector (149, -41)->(136, 0), block size = 8"
messages, hinting at the wrong direction of the motion vectors.
Fix this by doing the calculation that the DOS/Windows players do,
let the value overflow and reextract the "new" mvec x/y components.
avio_seek() never supported SEEK_END and returned AVERROR(EINVAL) when
specified, so the later check "(whence != SEEK_END || force)" was always true.
This also means that AVSEEK_FORCE had no effect since 7a6fe01f99, that is 15
years ago. Rather than changing behaviour, let's document instead that the flag
has no effect.
Also fixed other commit 41ed7ab45f which confused ORing / passing AVSEEK_FORCE
and AVSEEK_SIZE in the docs.
Signed-off-by: Valerii Zapodovnikov <val.zapod.vz@gmail.com>
The setup code fow w,h,left,top is complex, the code using it also falls in
at least 2 different classes, one using left/top the other not.
To ensure no out of array access happens we add this clear check.
Fixes: out of array access
Fixes: 439261995/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5383455572819968
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The array is only ever needed for streams where each sample entry may have a
different value. Given that for non animated HEIF there's a single value that
applies to the image, use the field defined for that.
Fixes: NULL pointer dereference
Fixes: 437528618/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6537287645331456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Add myself to JPEG XL and PNG decoders/encoders/parsers/etc. as a
suggested reviewer. I'm the maintainer of the JXL files and I know the
PNG code very well.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This patch aims to simplify the dtls handshake process
since dtls handshake use force block mode
We can just use the return code instead of DTLSState enum
Signed-off-by: Jack Lau <jacklau1222@qq.com>
pu_info is read uninitialized on damaged input and at that point the following codepath is dependant
on the uninitialized data. In one of these pathes out of array accesses happen.
None of this is replicatable
Less uninitialized data also should result in more reproducable reports
Fixes: Use of uninitialized memory
Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5103986067963904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It was unnecessary convoluted, remove not needed memory allocations,
snprintf.
Also fixes posibility to call snprinft with NULL as %s input.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f256487cd8 bumped requirement to
1.1.0 for OPENSSL_init_ssl.
Bump this again to 1.1.1, because it was an LTS version. Although it has
no mainline support anymore, it still has paid/premium support. 1.1.0 has
no support at all.
Motivated for use of BIO_read_ex() for next commits.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
in pack mode the array is passed into decode_plane() without being initialized or used
Fixes: use of uninitialized memory
Fixes: 438780119/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-5464037027807232
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When dimensions differ from context, those were updated using
ff_set_dimensions, however this overwrote the aligned coded_width and
coded_height that were set before, leading to a buffer overflow when
writing the frame data.
Fixes: OssFuzz 438771336
Fixes: Heap-buffer-overflow
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
One of the design goals of this macro is the ability to support static
inline predicate functions. Which is emitting warning in clang that a
function may have side-effects and the condition will be ignored. MSVC
doesn't emit warning, but also ignore predicate in such cases.
Instead of using assume builtins, implement it using unreachable. Which
solves this case for MSVC and Clang.
This reverts ea56fe60ac, but also extends
it to MSVC, which is affected in the similar way.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: signed integer overflow: 10 * 1952737655 cannot be represented in type 'int'
Fixes: PoC_avi_demux
Found-by: 2ourc3 (Salim LARGO)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x86/vc1dsp_init.c already includes asm.h before, so this is mostly
cosmetic change and only to clean checkheaders warning.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
cbs.mak is meant to contain tests strictly for the CBS framework, not for any
bsf that happens to use it under the hood.
Signed-off-by: James Almer <jamrial@gmail.com>
On Windows, static libraries are typically named with a .lib extension.
An exception to this is MinGW targets, which are treated as a distinct
target-os.
Using Windows-style naming allows `clang` to be used as the linker
driver, instead of invoking link or lld-link directly. The latter
approach requires manually specifying standard libraries when compiling
with `clang` rather than `clang-cl`, and manually specifying standard
libraries may be error-prone or incomplete.
Using Windows-style naming allows Clang to be used as the linker driver,
instead of invoking link or lld-link directly. The latter approach
requires manually specifying standard libraries, which may be
error-prone or incomplete.
This change also improves support for LTO and sanitizer builds, where
it's significantly easier to let the compiler driver manage the
necessary linker flags.
It fixes issues where Clang is asked to link `-lavcodec`, which gets
passed to the linker as avcodec.lib, resulting in an error like:
lld-link: error: could not open 'avcodec.lib': no such file or directory
This happens because `libavcodec.a` was unexpectedly generated, not
`avcodec.lib` expected by tooling.
Additionally, using `clang` (not `clang-cl`) is simplified, as it does
not use autolinking like MSVC/clang-cl does. Now `--ld=clang` can be
used to add all the required libraries. Previously, building with
`clang` was only possible by using `--ld=lld-link` and manually
specifying system dependencies in `extra-ldflags`.
Note that those changes doesn't affect mingw build. MSVC builds will
produce .lib static libraries now, but the linking process itself is not
affected, because filenames are passed directly.
To summarize in Windows non-mingw builds:
Static builds now produce `lib/avcodec.lib` instead of `lib/libavcodec.a`.
Shared builds remain unchanged, producing `bin/avcodec.lib` together with
`bin/avcodec-62.dll`.
This also removes setting LD_LIB from Win32/64 target as there is one
type of .lib in practice. We cannot build both shared and static at the
same time as noted by the next line.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Remove redundant av_freep() to avoid double free since task will be freed in dnn_free_model_tf() after the success of ff_queue_push_back().
Fixes: af052f9066 ("lavfi/dnn: fix mem leak in TF backend error handle")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
same issue as with tex
Fixes: 431665305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-5339599339847680
Fixes: use of uninitialized memory
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 431665305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-5339599339847680
Fixes: use of uninitialized memory
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 writing in the buffer has a wide range of error checks
which simply leave it partly uninitialized.
Initializing it on allocation ensures no sensitive data leaks and that
bugs are more reliably reproduceable
Fixes: use of uninitialized memory
Fixes: 435225510/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-4521918634196992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 436943287/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5011037029203968
This issue did oddly enough, not replicate
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Dithering relies on a 8 line dithering table and the code always uses it from
the beginning. So in order to make dithering independent from height of the
slices used we must enforce a 8 line alignment.
Fixes issue #20071.
Signed-off-by: Marton Balint <cus@passwd.hu>
You can technically feed the decoder a single packet with more than one AU in
it, even if a demuxer is unlikely to ever export such a thing.
Given the parser does no packetization to ensure we get a single AU, in order
to not discard any frame beyond the first, the decoupled input/output API
should be used.
Signed-off-by: James Almer <jamrial@gmail.com>
If a single fragment contains more than one frame unit, the tile information stored
in the private context will only correspond to one of them.
Fixes: crash (out of array access)
Fixes: 435489659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-6194885205229568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: BIGSLEEP-436511754/testcase.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If we use the private BlackDetectContext for logging, the filter ID does
not get printed alongside the filter name. Using the parent AVFilterContext
makes this consistent with other filters.
When called from avformat_find_stream_info(), we are only interested in
decoding SOF fields.
This patch makes the decoder skip all other fields (including SOI, SOS,
and EOI). This also prevents the decoder from incorrectly printing the
warning "EOI missing, emulating" (which is the case since 2ae82788).
Fixes: #20119
pl_frame_mix_current() will return NULL if all frames are in the future,
but when libplacebo is using a frame mixer with a radius greater than 1,
future frames are expected to already be partially renderered. Instead, use
pl_frame_mix_nearest(), which is guaranteed to give us a valid frame for any
nonempty frame mix.
Fixes: 3091bca3ed
Previously, these tests failed when running on Windows, if the
system is configured with a time zone east of Greenwich, i.e.
with a positive GMT offset.
The muxer converts the creation_date given by the user using
av_parse_time to unix time, as a time_t. The creation_date is
interpreted as a local time, i.e. according to the current time
zone. (This time_t value is then converted back to a broken out
local time form with localtime_r.)
The given reference date/time, "1970-01-01T00:00:00", is the
origin point for unix time, corresponding to time_t zero. However
when interpreted as local time, this doesn't map to exactly zero.
Time zones east of Greenwich reached this time a number of hours
before the point of zero time_t - so the corresponding time_t
value essentially is minus the GMT offset, in seconds.
Windows mktime returns an error, returning (time_t)-1, when given
such a "struct tm", while e.g. glibc mktime happily returns a
negative time_t. av_parse_time doesn't check the return value of
mktime for potential errors.
This is observable with the following test snippet:
struct tm tm = { 0 };
tm.tm_year = 70;
tm.tm_isdst = -1;
tm.tm_mday = 1;
tm.tm_hour = 0;
time_t t = mktime(&tm);
printf("%d-%02d-%02d %02d:%02d:%02d\n", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
printf("t %d\n", (int)t);
By varying the value of tm_hour and the system time zone, one
can observe that Windows mktime returns -1 for all time_t values
that would have been negative.
This range limit is also documented by Microsoft in detail at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64.
To avoid the issue, pick a different, arbitrary reference time,
which should have a nonnegative time_t for all time zones.
clr is passing into decode_run_p() its not used when not set
but this possibly triggers msan (it doesnt locally)
Fixes?: use of uninintialized memory
Fixes?: 436997807/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-6253316466606080
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 memory
Fixes: 42538134/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-6322020827070464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This code always ignored the user-provided enc_ctx->chroma_sample_location
in favor of the location tagged on the frame. This leads to a very (IMHO)
unexpected outcome where -chroma_sample_location works differently from the
related options like -colorspace and -color_range, the latter of which
override the frame properties as a consequence of being configured on the
filter graph output.
The discrepancy comes from the fact that the chroma sample location does not
itself participate in filter graph negotiation.
Solve the situation by only overriding the enc_ctx option if it was left
unspecified by the user, and otherwise printing a warning if the requested
parameter does not match the frame parameter.
heif_items are reused and to avoid leaking memory or using stale name,
clear it first.
Fixes: 432505829/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6654363487764480
Found-by: OSS-Fuzz
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When this function returns, the fragment is never reset, so
current_frag->data_ref is never unref-ed, which ends up leaking it.
We call ff_cbs_fragment_reset to release the reference on its buffer.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
opt_codec() is mostly copied over from ffplay.c.
This is useful when different decoders have different capabilities,
or to test a specific decoder.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Fixes: writing in a null pointer
Fixes: 435278398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-4566392923029504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Accept up to 13 ULP difference.
This fixes running "checkasm --test=ac3dsp 3044836819" on ARM.
Depending on how the SIMD implementations aggregate numbers,
larger/smaller values might not end up accumulated in exactly
the same way; the current NEON implementation for ARM aggregates
into vectors of 2 elements. If it would aggregate into vectors
of 4 elements instead, like the AArch64 version does, this particular
case would end up with a smaller difference.
AV_CLASS_CATEGORY_HWDEVICE was introduced in the past but
no corresponding colors were added for non-Win32 platforms.
Fixes bf1579c ("avutil/log,hwcontext: Add AV_CLASS_CATEGORY_HWDEVICE")
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
they use tests/ref/fate/sub-mcc-remux as input,
so prefix them with $(SRC_PATH) so building works
when not in the source directory.
Fixes: #20183
Reported-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Jacob Lifshay <programmerjake@gmail.com>
Don't overwrite the bitstream values when updating the top-level loop
filter and segmentation state, instead do the update separately at the
end of the frame parsing.
This also reverts the change to the passthrough tests which made them
have output not matching the input.
The SRTP profile string "SRTP_AES128_CM_SHA1_80" is only used when
use_srtp is enabled. Move its declaration inside the "if (s->use_srtp)"
block to limit scope
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Pure cleanup, no functional changes
Unify local pointer names to `TLSContext *c` and `TLSShared *s` to
reduce confusion from inconsistent names (e.g. p, ctx, s, c)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Fixes: use of uninitialized memory
Fixes: 429130590/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_DEC_fuzzer-5736930522497024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The issue is that a race condition exists between threads locking
frames, which results in cyclic loops and deadlocks.
Compute-based implementations are not affected.
Fixes#20169
The original cleanup of frame_id_alloc_mask was done in free_frame_priv
which may be called after the start_frame for the next few frames,
causing the frame_id slots to be exhausted. Instead, decide the in-use
frame_id slots by checking the frame_id present in the DPB as we need it.
We always use two slots, even when only one L0 reference is supported
by the driver. However we still need to set the correct value for the
ref_order_hint of the second slot.
Fixes regression from bf9f921ef7 ("avcodec/hw_base_encode: restrict size of next_prev")
vaapi_get_image_format() will be called in vaapi_map_frame().
So it's a double check, drop it to avoid redundancy.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
There's a race condition for YUV420P when mapping from pix_fmt
to VA fourcc, both I420 and YV12 could be found by pix_fmt.
Currently, vaapi_get_image_format() iterates over the query results
of pix_fmt and returns the first matching result in the order
declared in the driver. This may result in an incorrect image_format.
Now use fourcc to find the image_format.
Fixes:
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i INPUT \
-vf scale_vaapi=format=yuv420p,hwmap,format=yuv420p \
-vframes 1 -f rawvideo -y yuv420p.yuv
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Fixes: out of array read
Fixes: 397731127/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5577772965101568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: index 50 out of bounds for type 'INTFLOAT [40][2]'
Fixes: 401661737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4866055713652736
Someone knowing AAC well should review this, there is likely a nicer fix
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead of undconditionally using the first input. This covers the case of
one layer fully obscuring another layer, in which case that should become
the new "base" layer.
This prevents leaking stale metadata from previous frames, for example if
an overlay temporarily obscures this input and then un-obscures it again. It
is worth pointing out that this does change the semantics subtly, because of
the smoothing period on detected HDR metadata, but I argue that the new
behavior is an improvement, as it will avoid leaking past metadata that is
definitely no longer relevant after an image is unobscured.
Sometimes, one input fully obscures another. In this case, we can skip
actually rendering any input below the obscuring one.
The reason I don't simply start the main render loop at `idx_start` will
become apparent in the following commit.
We can't use pl_frame_is_cropped() on this dummy frame, but we need to
determine the reference frame before we can map the real output, so to
resolve this conflict, we just reimplement the crop detection logic using
the output link dimensions.
It is possible for pl_queue_update() to return PL_QUEUE_OK, but to generate
an empty frame mix. This happens if the first frame of that input is in the
future.
In this case, we should skip an input as not active, similar to inputs that
have already reached EOF.
Instead of copying over the entire target and changing a few fields,
set the entire struct to a whitelist of safe properties that we want to
persist on the intermediate texture.
In particular, this avoids leaking irrelevant state related to the
acquire/release callbacks, e.g., which can otherwise cause deadlocks
when the same vulkan frame is attempted to be acquired twice.
This creates a new codec id for mxf vbi_vanc_smpte_436M streams.
This makes it easier to use from other [de]muxers and bitstream filters.
It's just the data in Table 7 (starts on page 13) of:
https://pub.smpte.org/latest/st436/s436m-2006.pdf
Signed-off-by: Jacob Lifshay <programmerjake@gmail.com>
They were not sorted before, sort using: LC_ALL=C sort --ignore-case
since that's what file-contents-sorter (added in next commit) supports.
Signed-off-by: Jacob Lifshay <programmerjake@gmail.com>
This commit adds a ProRes RAW hardware implementation written in Vulkan.
Both version 0 and version 1 streams are supported.
The implementation is highly parallelized, with 512 invocations dispatched
per every tile, with generally 4k tiles on a 5.8k stream.
Thanks to unlord for the 8-point iDCT.
Benchmark for a generic 5.8k RAW HQ file:
6900XT: 63fps
7900XTX: 84fps
6000 Ada: 120fps
Intel: 9fps
Fixes: use of uninitialized memory
Fixes: 428969823/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_DEC_fuzzer-5909681623334912
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 meory
Fixes: 428034093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-6195630160805888
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 memory
Fixes: 428969823/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_DEC_fuzzer-5909681623334912
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 meory
Fixes: 428034093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-6195630160805888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Simple parser that only parses frame information.
This helps avoid requiring the software decoder on init to decode a
single frame, since the decoder can be quite slow.
Fixes: out of array access
Fixes: BIGSLEEP-436510316/dwa_uncompress_write.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: BIGSLEEP-436510153/dwa_uncompress_read.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: utils.c:524:9: runtime error: call to function
handle_init_section_args through pointer to incorrect function type
'void (*)(void *, const char *, int, char **, int *)'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add check for the return value of av_packet_alloc() to avoid potential NULL pointer dereference.
Moreover, replace redundant av_free() with fprintf().
Fixes: 9a38184a14 ("examples/decode_audio: allocate the packet dynamically")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add av_free() to free s.temp_dwt_buffer and s.temp_idwt_buffer at the end of the function to avoid memory leak.
Fixes: 5d48e4eafa ("Merge commit 'a6a750c7ef240b72ce01e9653343a0ddf247d196'")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add check for the return value of av_malloc_array() to avoid potential NULL pointer dereference.
Fixes: d3be186ed1 ("avfilter/firequalizer: add dumpfile and dumpscale option")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Move av_malloc() after the check for subsampling to avoid memory leak if subsampling < 0 and av_malloc() succeeds.
Fixes: a41a2efc85 ("lavc/videotoolbox: add VP9 hardware acceleration")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In general, a provider code corresponds to a company/organization, and
the name should be that of the company, not of a given feature.
The feature is signalled in the "provider oriented code".
The exception is HDR Vivid, where the code 0x0004 indicates the HDR Vivid
feature itself rather than CUVA (China UHD Video Industry Alliance),
according to the UHD World Associations 'HDR Video Technology Part 2-1
Application Guide to System Integration' document.
ITU_T_T35_PROVIDER_CODE_CUVA -> ITU_T_T35_PROVIDER_CODE_HDR_VIVID
ITU_T_T35_PROVIDER_CODE_LCEVC-> ITU_T_T35_PROVIDER_CODE_VNOVA
ITU_T_T35_PROVIDER_CODE_SMTPE -> ITU_T_T35_PROVIDER_CODE_SAMSUNG
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ITU-T T.35 provider codes are attributed by national bodies and it's
possible to have collisions across countries. This is why the country code
must always be checked as well.
Use if statements rather than nested switches which would be unreadable.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is in preparation to change the switch statement to if/else.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should be done by fate.
This script already blocks security fixes (https://code.ffmpeg.org/FFmpeg/FFmpeg/actions/runs/1046/jobs/0)
IMHO its not good
1. to add commit message formating rules, never discussed or agreed
2. to expect developers to push commits trial and error style, make fate
can test this already and tell the devlopers before pushing, saving him
time
This reverts commit cc6ad703b4.
current->num_tile_columns is not updated in the loop, so the existing
check was not working. Check current index instead and break. This also
simplifies duplicated log.
Fixes: 435225531/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-6639684232216576
Found-by: OSS-Fuzz
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
ff_vvc_palette_escape_val() can return AVERROR in which case the
coeff*scale will overflow.
Fixes: runtime error: signed integer overflow: -1094995529 * 6528 cannot
be represented in type 'int'
Fixes: 435225406/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5118570024730624
Found-by: OSS-Fuzz
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Introduced by 307983b292
Use the following command line to reproduce the issue:
./configure --toolchain=msvc --disable-asm --enable-ffmpeg \
--disable-everything --enable-decoder=vvc --enable-parser=vvc \
--enable-demuxer='vvc,mpegts' --enable-protocol='file,pipe' \
--enable-encoder='rawvideo,wrapped_avframe' \
--enable-muxer='rawvideo,md5,null'
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
This changes configure to stop disabling -ftree-vectorize on
GCC versions 13 and newer, on major architectures.
Background:
- Original `-fno-tree-vectorize` was added in 2009 in commit
973859f523 to avoid compiler errors.
- Re-enabled in 2016 in commit cb8646af24 but caused failures due
to inline CABAC assembly issues and was disabled again in
fd6dbc5385.
- Commit 182663a58a in 2023 fixed the inline CABAC assembly issues.
- Recent versions of GCC, in particular 13 and newer, seem to
generally work reliably with respect to vectorization, although bugs
have been observed on Loongarch.
Cautiously allow the GCC default of having vectorization enabled,
on major architectures where we expect to see enough testing. If
further issues are observed, they should be reported and noted here in
configure, so the workarounds can be scoped and version limited.
This is important for feature checking to work correctly.
It can happen that an unrecognized flag passes the compile test with
only a warning, while failing in preprocessor-only check with an error.
This causes all test_cpp calls to fail and silently produces arguably
broken MSVC builds. Also, all check_* functions don't work as expected,
because they assume the check passed, even though there was a warning.
Additionally, this brings the behavior in line with GCC/Clang based
builds, failing early on unrecognized flags instead of silently
continuing with warnings in the log.
The /options:strict option is available starting in Visual Studio 2022
version 17.0. Because of that, we cannot use check_cflags alone, as it
would add this flag for older MSVC versions and produce warnings. So, we
need to manually perform a version check. A bit of a chicken and egg
problem.
Perform the version check before adding extra flags from the user to
ensure we don't silently fail the preprocessor check due to invalid
flags on older MSVC versions. Note that behavior differs depending on
whether we are compiling or only preprocessing.
This fixes silent different between handling:
`cl.exe -P foo c.c`
c1: fatal error C1083: Cannot open source file: 'foo': No such file
or directory
`cl.exe -c foo c.c`
cl : Command line warning D9024 : unrecognized source file type
'foo', object file assumed
Where -P fails, while -c throws warnings only. Of course `foo` is
completely bogus here, but depends on the flags or configuration this
may be unsupported argument. Or even some converted path from MSYS when
run inside it. The objective is to always error out instead of silently
hiding this.
Use check_cflags even after the _MSC_FULL_VER check, for non-MSVC
compilers. For example Clang-CL impersonate MSVC, but does not support
-options:strict flag currently.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This avoids adding flags that cl.exe doesn't understand.
Fixes cases where external libraries pkg-config file adds `-L` to the
cflags, strip it before passing to cl.exe.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
There was implicit assumption that the $TMPC file is empty when doing
--cpu=host checks. This breaks if any check is done before that.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Previously, it was assumed that `drmFormatModifierPlaneCount` was one
for all modifiers when exporting, which is not always the case, in
particular for AMD GPUs and maybe others.
Fetch the number of memory planes and fill the structs appropriately in this situation.
The encoded stream is still bad in the case whre modifers are involved,
but I think this patch still stands on its own and I suspect that may be a driver bug.
A potential improvement that could be make is to cache the format
information, so we can avoid the two GetPhysicalDeviceFormatProperties2
calls for each export, as well as the allocation. I doubt this is very
expensive, but seemed worth noting.
v2 changes: query the format properties with the test image created in
`vulkan_frames_init` to avoid allocating space for the query during
export
Signed-off-by: Russell Greene <russellgreene8@gmail.com>
The check to return on EOF should not be inside a block that will not be entered after reaching EOF.
Should fix "libavcodec/bytestream.h:144:27: runtime error: applying zero offset to null pointer".
Signed-off-by: James Almer <jamrial@gmail.com>
Printing dummy logs during fuzzing can significantly slow the process
and blow the size of logs, making them both unredable and huge.
Keep the loggging commented-out for easy local restore if needed.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f566032bfd added frame validation.
Since then this decoder has been failing validation of sample rate
value.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f566032bfd added frame validation.
Since then this decoder has been failing validation of sample rate
value.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f566032bfd added frame validation.
Since then this decoder has been failing validation of sample rate
value.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f566032bfd added frame validation.
Since then this decoder has been failing validation of sample rate
value.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
- proper pts for packets. leaving it blank leaves it up for guessing,
but the guess doesn't take seeking into account, causing weirdness.
- clamp to 0 when seeking to negative ts. libopenmpt docs are unclear on
this but not doing this causes an immediate EOF when seeking backwards
to the beginning in mpv.
- only set song duration and packet pts when they are non-negative and
in int64 range. NaNs count as out of range. this isn't a fix for any
specific issue but might be helpful still, and shouldn't break
anything.
As noted in the code in several places, some DVB subtitle decoders
don't handle 2bpp color. This patch adds a min_bpp option which
sets a lower bound on the number of bits-per-pixel in the color
tables. It defaults to 4 to avoid the problematic 2bpp decoders.
Signed-off-by: Ronan Waide <waider@waider.ie>
This is based on the previously used, simple TRAC form
with new description language.
We can iterate on it to improve as needed.
Signed-off-by: Yalda <marth64@proxyid.net>
If a supported tag has a class, e.g "<i.bold>" it is ignored entirely;
so for example "<i.bold>Hello</i>" would be converted to "Hello{\i0}"
instead of the intended "{\i1}Hello{\i0}".
Signed-off-by: Leon Grutters <gruttersleonbot2@gmail.com>
Allows to output LRC with more precision than standard centiseconds.
Time base is determined by number of requested digits.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Apparently files with milliseconds exist in the wild. And since it cost
nothing to support arbitrary number of digits, extend format to support
that.
Depending on number of digits, the time base of fractional part is
changing. Most LRCs use 2 digits and centiseconds base, but subs with 3
digits and miliseconds exist too.
Set internal time base to AV_TIME_BASE, which in parcitice allows to
hold microseconds with 6 digits. Totally artificial, but who knows maybe
someone wants that.
Fixes: #11677
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add check for the return value of avcodec_alloc_context3() to avoid potential NULL pointer dereference.
Fixes: 5d48e4eafa ("Merge commit 'a6a750c7ef240b72ce01e9653343a0ddf247d196'")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add av_packet_free() to free avpkt_clone and avpkt in the error paths to avoid potential memory leak.
Fixes: da3c69a5a9 ("Added test for libavcodec/avpacket.c")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add av_free() to free extra_data if av_packet_add_side_data() fails.
Fixes: da3c69a5a9 ("Added test for libavcodec/avpacket.c")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I also tried replacing some of the instructions by more elaborate ones
using masks, but I found no performance gain significant enough to be worth
maintaining two code paths, so this implementation merely replaces the AVX2
implementation by drop-in AVX512 equivalents.
bwdif8_c: 6362.2 ( 1.00x)
bwdif8_sse2: 1004.9 ( 6.33x)
bwdif8_ssse3: 946.0 ( 6.73x)
bwdif8_avx2: 477.9 (13.31x)
bwdif8_avx512: 273.3 (23.28x)
bwdif10_c: 6341.5 ( 1.00x)
bwdif10_sse2: 872.4 ( 7.27x)
bwdif10_ssse3: 803.4 ( 7.89x)
bwdif10_avx2: 416.7 (15.22x)
bwdif10_avx512: 224.3 (28.27x)
Realtime test at 3840x2160 yuv420p:
avx2: frame=20000 fps=3370 q=-0.0 Lsize=N/A time=00:06:40.00 bitrate=N/A speed=67.4x elapsed=0:00:05.93
avx512: frame=20000 fps=5077 q=-0.0 Lsize=N/A time=00:06:40.00 bitrate=N/A speed= 102x elapsed=0:00:03.93
The use of this function is gated behind avx512icl so that it doesn't
downclock on Skylake.
Based on mpv's script, under LGPL. https://github.com/mpv-player/mpv
Co-authored-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The end of 8-bit/pixel_code_string() is signalled with two zero bytes, so we
should read those from the buffer instead of one. We keep supporting though our
own buggy encoder which only put one zero byte there.
Signed-off-by: Marton Balint <cus@passwd.hu>
Initially, avcodec/srtenc.c was outputting CRLF [1]. Later, a real SRT
muxer was added [2], which outputs LF. The original srtenc.c was
converted to use the muxer [3], changing its output to LF, except for
newline characters within subtitle text.
Fix this to avoid producing SRT files with mixed line endings.
[1] 8e43b6fed9
[2] 9e63c30daa
[3] 55180b3299
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This will ensure it will be stored in the stream's private context, so it can
be fetched and replaced as required.
Fixes a regression since eefa6de7d5.
Fixes avc-intra-panasonic-AG-HPX301E.mov
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: use of uninintilaized memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6235973619351552
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 memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-6651797156724736
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 memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IAC_fuzzer-6685890556788736
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 memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CRI_fuzzer-5910856640823296
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 memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NOTCHLC_fuzzer-5597015691296768
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 memory
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_DEC_fuzzer-5602250833854464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: writing 1 byte over the end of the array
Fixes: BIGSLEEP-433502298/test.xml
Found-by: Google Big Sleep
A prettier solution is welcome!
A testcase exists only for the baseurl case
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ticket11686 hinted at one of these overflows
this fixes them all
Issue in line 1325/1326 found by HAORAN FANG <xfanghaoran@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Consider the following sequence of NALUs (with some PPSs etc. omitted
for brevity):
1. SPS (ID=0, content=A)
2. IDR (SPS=0)
3. IDR (SPS=0)
4. SPS (ID=0, content=B)
5. TRAIL (SPS=0)
When decode_sps is called for NALU 3., ps->sps_id_used is cleared as
IDRs are one way of forming a CLVSS. Then, old_sps is non-NULL
containing the result of calling decode_sps for NALU 2. We haven't
received any SPSs between NALUs 2. and 3., therefore old_sps and rsps
are identical and the function returns. The issue is that, at this
point, ps->sps_id_used is still zero despite the SPS being used for IDR
3. This results in the check for conflicting SPSs not working properly
when decode_sps is called for NALU 5., allowing prediction between
pictures with different SPSs and probably all sorts of other
shenanigans.
Patch addresses the problem outlined above by also setting
ps->sps_id_used in the early return case.
This was introduced in commit 9c43703, to support a codec "extension"
in the prores_aw encoder.
This removes the chroma fill loop, and instead performs the inverse
transform on null coefficients, which achieves the same result and
fixes an off-by-one in the chroma values produced.
Updated test to reflect this change.
Fixes issue #20018.
Note that Codec Descriptors are not written for all these ai** codec tags, and no
considerations were ever made to ensure parameter sets are present in muxed packets.
Their usage may result in unplayable files if parameter sets are only available
in extradata (Default behavior for x264 encoding when combined with this muxer).
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5466731806261248
Fixes: out of array access
Reviewed-by: Manuel Lauss <manuel.lauss@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read in the chroma plane
Fixes: 428034092/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_DEC_fuzzer-5582608941776896.test
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds D3D11 input surface support to the MediaFoundation encoder (mfenc),
allowing direct encoding of GPU frames without readback to system memory.
This improves performance and compatibility when used alongside scale_d3d11.
Signed-off-by: Dash Santosh <dash.sathyanarayanan@multicorewareinc.com>
This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
This fix copies a couple of casts from surrounding functions.
See https://crbug.com/432528781 for stack trace details.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is no convenient way, from the command line, to figure out which
formats a filter actually supports. This commit changes that by adding a
log output, at debug level, to simply print the list of formats each filter
advertises on its links, before any negotiation.
Furthermore, we can use the exact same helper function to also print out the
corresponding filter links when there is an error during format negotiation.
We need to use AV_BRINT_SIZE_UNLIMITED because the default format list for
filters like vf_scale is about 1700 characters long, significantly larger than
the the 1 kB default buffer.
This function overreads the input plane for odd dimensions, because the
chroma plane is always rounded up, which means (xy << subsample) + 1 exceeds
the actual alpha plane size.
To verify:
valgrind ffmpeg -pix_fmt yuva420p -f lavfi -i color -vf \
"scale=1x1,format=yuva420p,scale=alphablend=uniform_color,format=yuv420p \
-vframes 1 -f null -
Fixes: https://trac.ffmpeg.org/ticket/11692
That occurs when H261, H263, and MPEG4 decoders are disabled.
Signed-off-by: zhaozhenghang <15083277223@163.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
If a packet contains new extradata within a side data entry, save for
specific cases it means the coded stream changed. If ignored, upon
demuxing every packet from then onwards may be undecodable.
Signed-off-by: James Almer <jamrial@gmail.com>
The first sample in the stsc box may not refer to the first stsd entry.
This is the case in h264/thezerotheorem-cut.mp4, and as such the
fate-h264_redundant_pps-side_data test is updated accordingly.
Signed-off-by: James Almer <jamrial@gmail.com>
BIO_get_new_index() is static counter meant to get index for custom bio
type definition. As we can read in the documentation:
> Note that BIO_get_new_index() can only be used 127 times before it
> returns an error.
We cannot call it repeatedly, because it will fail eventually.
To my understanding the index is not needed in our use and we could
safely use BIO_TYPE_NONE. Documentation states:
> type can be set to either BIO_TYPE_NONE or via BIO_get_new_index() if
> a unique type is required for searching (See BIO_find_type(3))
We don't use any search related functions.
This reverts commit 816dad231f.
Fixes: https://github.com/mpv-player/mpv/issues/16589
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: writing over the end of the array
Fixes: BIGSLEEP-434637586/payload
Regression since: b22ce90d42
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This change improves pipeline stability and reduces
dynamic GPU surface allocations when using AMF with copy_frame = 1.
This optimization has no negative effect.
The new logic should be easier to follow.
It also uses ff_inlink_consume_frame() for all simple passthrough operations
making custom get_audio_buffer callback unnecessary.
Fate changes are because the new logic does not repacketize input audio up
until the crossfade. Content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
Prior to this patch, kth_order_egk_decode could read arbitrarily
large values which then overflowed and caused various issues.
Patch fixes this by making kth_order_egk_decode falliable,
requiring the caller to specify an upper bound and returning an
error if the read value would exceed that bound.
This patch resolves the same issue as
eb52251c0a, but I think this is the proper
fix as it also addresses issues with syntax elements besides
ff_vvc_num_signalled_palette_entries.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The end_ prefix is confusing and may have contributed the mixup
fixed in the previous commit
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: reading the duration from before the start of the allocated buffer.
Regression since: 36ec9217e6
Fixes: BIGSLEEP-433513232/test
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also ensure that the dst buffers are not too big
(they had the right size for >8 bit depths and were therefore
too big for eight bit, letting potential buffer overflows
in the eight bit version go undetected).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 410609432/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-4935159201988608
Fixes: out of array access
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized memory
Fixes: 427532813/clusterfuzz-testcase-minimized-ffmpeg_dem_MXG_fuzzer-5661938917113856
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 memory
Fixes: 422217206/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-4786889444098048
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 memory
Fixes: 421954767/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SHORTEN_fuzzer-515682786246656
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 memory
Fixes: 412125811/clusterfuzz-testcase-minimized-ffmpeg_dem_VQF_fuzzer-6253774274887680
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 memory
Fixes: 394990189/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6431722199908352
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 memory
Fixes: 378102648/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5896308499480576
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 memory
Fixes: 403675492/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_fuzzer-4754281823797248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The only offical profile i could find (ALS simple profile) has a max of 15 while the bitstream allows 1023
which is very slow.
We do have a fate sample with 1023
Fixes: Timeout
Fixes: 429645375/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5377900448907264
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This linear search has a complexity of O(n). When ffmpeg attempts to parse a playlist containing approximately 100,000 segments, it effectively causes a hang for several minutes.
This patch limits the allowed size for duplicate searches to a reasonable value. Now it takes between 0.5 and a few seconds (tested on different devices) instead of several minutes.
Signed-off-by: Artem Smorodin <artem.smorodin@dacast.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
HEVC fmp4 HLS video produced by ffmpeg is currently unplayable on Apple
software (Safari, QuickTime, AVFoundation).
This is caused by an empty sdtp atom being erroneously written to the
fmp4 init segment. The `has_disposable` flag can be set for a track
with B-frames, but the init segment contains no actual frames
(track->entry == 0). Writing an sdtp atom in this case is incorrect
and causes Apple's parsers to reject the file.
This patch fixes the issue by ensuring the sdtp atom is only written
if track->entry is non-zero.
A similar patch was proposed in November 2023 by Jay Zhang,
but it was never merged.
Link: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/317173.html
Co-authored-by: Jay Zhang <wangyoucao577@gmail.com>
Signed-off-by: David McElroy <david@mcelroy.online>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This gives vastly improved blending results than when blending directly in
the desired output colorspace. Overridable by the existing "disable_linear"
option.
This is functionally similar to combining multiple "libplacebo" filters,
but does not rely on the existence of a Vulkan filter link, so it can be used
without performance penalty in all circumstances. It's also enabled by
default, without requiring special action from the user.
The previous formula was introduced without justification in 6e713841e8,
and the only thing Paul had to say about it over IRC was that it was copied
from an unspecified source on the internet.
I decided to do some testing and came to the conclusion that this term not
only produces "illegal" files, but also lowers PSNR score, over the naive
implementation without this extra term.
Here are the results of a round-trip test, using allrgb/allyuv (respectively)
as the input, and fade=alpha=yes:n=256 to cycle through every possible alpha
value, comparing the round-trip output against the input:
Before patch:
PSNR r:26.677431 g:26.677431 b:26.677431 a:inf average:27.926818 min:6.012093 max:55.400791
PSNR y:26.677431 u:21.101981 v:21.101981 a:inf average:23.548981 min:9.013835 max:53.182303 (full)
PSNR y:27.348055 u:21.101981 v:21.101981 a:inf average:23.625238 min:9.554991 max:45.652221 (limited)
After patch:
PSNR r:27.321996 g:27.321996 b:27.321996 a:inf average:28.571384 min:6.012093 max:52.424553
PSNR y:27.321996 u:23.187879 v:23.187879 a:inf average:25.431773 min:9.013835 max:50.199232 (full)
PSNR y:27.868544 u:23.187879 v:23.187879 a:inf average:25.515660 min:9.554991 max:45.078298 (limited)
It's worth pointing out that previous version sometimes artificially inflates
PSNR by producing values that are too high (i.e. RGB > A), such as for the
input pair (R = 255, A = 2) which should give R = 2, but actually gives R = 3
under the old logic.
As a second evaluation without this shortcoming, here is a comparison against
the reference value computed with a floating point format:
Before patch:
PSNR r:53.600599 g:53.957833 b:53.540948 a:inf average:54.945316 min:50.508901 max:inf (premul only)
PSNR r:30.734183 g:30.734183 b:30.734183 a:inf average:31.983570 min:12.058264 max:inf (round-trip)
After patch:
PSNR r:61.751104 g:65.239091 b:61.339191 a:inf average:63.710714 min:55.441130 max:inf (premul only)
PSNR r:32.611851 g:32.611851 b:32.611851 a:inf average:33.861238 min:12.058264 max:inf (round-trip)
Instead of scanning backwards for the end of RPU payload, parse it and
report if we didn't land at the terminator byte.
Current expectation was that we can have additional zero bytes after RPU
payload, which were skipped to find playload end. That's not always the
case. So loosen this requirement.
This fixes files where there is additional non-zeroed padding after the
end of the RPU in NALU.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: signed integer overflow: 9223372036854737920 + 1649410 cannot be
represented in type 'int64_t'
Fixes OSS-Fuzz: 410100610
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The asumption is that DCE will remove references to those functions.
However some compilers with certain instrumentation enabled doesn't DCE
those at all, resulting in linking failure. Tested with cl.exe -RTCu -RTCs.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The asumption is that DCE will remove references to those functions.
However some compilers with certain instrumentation enabled doesn't DCE
those at all, resulting in linking failure. Tested with cl.exe -RTCu -RTCs.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The asumption is that DCE will remove references to those functions.
However some compilers with certain instrumentation enabled doesn't DCE
those at all, resulting in linking failure. Tested with cl.exe -RTCu -RTCs.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When codec->write_sequence_header is not defined, bit_len was undefined,
and while data bufer was zeroed we could just overread it. Do nothing
when we don't have anything to write.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If a frame size is absolutely massive, this can spin the parser as it
attempts to decode a permuted TOC. We add a sanity check here for eight
times the size of the image for an internal frame to prevent malicious
bitstreams from slowing the parser down to a crawl.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Kacper Michajłow <kasper93@gmail.com>
socklen_t underlying type can be signed or unsigned depending on
platform. This is fine, just cast it to size_t before comparison.
Fixes: warning: result of comparison of unsigned expression < 0 is
always false [-Wtautological-unsigned-zero-compare]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add type removed function wrappers to resolve UB of calling function
through pointer to incorrect function type.
Fixes: FATE-{hmac,srtp}
Fixes: call to function av_md5_init through pointer to incorrect
function type 'void (*)(void *)' and similar for others.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
av_get_token() allocates an output buffer with the same size as the
input. Generally, this is harmless, but when the input string is large
and consists of many small tokens, calling av_get_token() repeatedly to
extract all tokens will significantly amplify memory allocations.
To fix this, after obtaining the return value, simply realloc the buffer
to the actual size needed for output string.
Fixes OOM when parsing filter graph string.
Fixes OSS-Fuzz: 394983446
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It's RGB, so check instead if it's packed or planar.
Fixes: libavcodec/ffv1dec.c:461:43: runtime error: applying zero offset to null pointer
Signed-off-by: James Almer <jamrial@gmail.com>
It's not a value stored in the hvcC structure.
Fixes use of uninitialized variable errors under sanitizer when the input extradata is
already hvcC formatted, given we don't parse parameter sets for those.
Signed-off-by: James Almer <jamrial@gmail.com>
When no explicit CAs file is set, load the default locations,
else there is no way for verification to succeed.
This matches the behavior of other TLS backends.
When verification is enabled (using -tls_verify 1) now
the hostname will be verified properly too, while before
only other aspects of the certificate were checked.
Co-Authored-By: Marvin Scholz <epirat07@gmail.com>
For detect_range, the usage of vpbroadcast{b,w} requires the AVX512BW extension, and for
detect_alpha we don't want ZMM instructions downclocking old CPUs.
Signed-off-by: James Almer <jamrial@gmail.com>
This filter can detect various properties about the image, including
whether or not there are out-of-range values, or whether the input appears
to use straight or premultiplied alpha.
Of course, these can only be heuristics, with "undetermined" as the base
case. While we can definitely prove the existence of full range or
straight alpha colors, we can never infer the opposite.
Fixes: signed integer overflow: 40000 - -9223372036854770000 cannot be represented in type 'long'
Fixes: 427262541/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-4831506940100608
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The true problem happens in several previous get_vlc_symbol()
but checking that is more expensive (involving FFABS())
here its just a simple check between 2 variables we have.
Fixes: Assertion log >= k failed at libavcodec/golomb.h:406
Fixes: 429296194/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_DEC_fuzzer-4691594622337024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add av_freep() to free new_elem to avoid memory leak.
Fixes: 3ca1e31e63 ("fftools/cmdutils: Atomically add elements to list of pointers, fix crash")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't rely on implicit zeroing.
Should fix fate failures on msvc targets.
Found-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
scale was never initialized. av_tx_init() will use default scale if we
pass NULL.
Fixes: b3117f376d
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This was in else branch of `#if 1` since ever. No need to keep dead code
like that, if anyone needs it they can get it from git history.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
In OSS-Fuzz build environment flags are handled by CFLAGS and LDFLAGS.
In local build use --toolchain=clang-fuzz-asan-ubsan or similar
combination depending on requested sanitizers.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Nothing forbids them to be in any order the muxer desires.
Fixes demuxing heif samples generated by S1II.
Tested-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
- Changes in mov_write_video_tag function to handle APV elementary stream
- Provided structure APVDecoderConfigurationRecord that specifies the decoder configuration information for APV video content
Co-Authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Requested by a user. Even with autovectorization enabled, the compiler
performs a quite poor job of optimizing this function, due to not being
able to take advantage of the pmaxub + pcmpeqb trick for counting the number
of pixels less than or equal-to a threshold.
blackdetect8_c: 4625.0 ( 1.00x)
blackdetect8_avx2: 155.1 (29.83x)
blackdetect16_c: 2529.4 ( 1.00x)
blackdetect16_avx2: 163.6 (15.46x)
Can't read alignment from packet, codecpar or decoded frame linesizes, so don't
set it. My test device redmi k60 produces images in 4624x3472, not 32 aligned
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Nikon HEIFs from a camera or NX studio include a small jpeg thumbnail in addition to
the expected HEVC thumbnails; allowing jpegs allows all thumbnails to
have an associated stream for Nikon HEIF files.
With this, Nikon HEIFs can finally be decoded without failing and the
thumbnails can be extracted into their own files.
Signed-off-by: Eric Joyner <erj@erj.cc>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents ffmpeg/ffprobe from erroring out when reading an HEIF that
contains multiple hvcC thumbnails (e.g. from a Nikon Z6III camera).
Before, move_read_iref_thmb() would always override the stored
thmb_item_id in the MOVContext with each new read thumbnail, causing a
stream and item_id mismatch later in mov_parse_heif_items(), resulting
in the "HEIF thumbnail doesn't reference a stream" error message.
To solve this,
- Turn thmb_item_id into an array of IDs because multiple thumbnails can
exist
- Change check in mov_parse_heif_items() to compare against all stored
thumbnail IDs to see if any item missing a stream is in the list of
thumbnail IDs.
Signed-off-by: Eric Joyner <erj@erj.cc>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
We need to ensure rtp sets NONBLOCK since the dtls
handshake has potentially overriden the sockets mode.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This naive hist[p[x]]++ loop suffers badly when there are large regions of
identical values in the image, because of store-to-load forwarding delay.
Splitting up the histogram into four "parallel" histograms and processing
them one at a time speeds things up significantly, about 40% on my end.
Since psadbw only exists for 8-bits, we have to emulate it for 16-bit
inputs. The simplest sequence is to use a normal subtraction, which is safe
as long as the inputs do not exceed 32767 - so limit this implementation
to 15-bit inputs and below.
For 16-bit inputs, we could in theory instead use a pminw / pmaxw to ensure
the resulting difference does not overflow, but this is slower, and also
breaks the subsequent use of pmaddwd, so I opted to skip 16-bit SIMD for
now.
scene_sad10_c: 114175.6 ( 1.00x)
scene_sad10_avx2: 9617.7 (11.87x)
scene_sad10_avx512: 5208.8 (21.92x)
scene_sad12_c: 114537.8 ( 1.00x)
scene_sad12_avx2: 9614.0 (11.91x)
scene_sad12_avx512: 5186.3 (22.08x)
scene_sad14_c: 114113.9 ( 1.00x)
scene_sad14_avx2: 9612.9 (11.87x)
scene_sad14_avx512: 5186.0 (22.00x)
scene_sad15_c: 114108.9 ( 1.00x)
scene_sad15_avx2: 9612.3 (11.87x)
scene_sad15_avx512: 5186.4 (22.00x)
scene_sad16_c: 114136.0 ( 1.00x)
Trivial to add, but a lot faster (on my machine).
scene_sad8_c: 114476.4 ( 1.00x)
scene_sad8_sse2: 8644.3 (13.24x)
scene_sad8_avx2: 4520.1 (25.33x)
scene_sad8_avx512: 3153.0 (36.31x)
the SSL_shutdown in tls_close need call the url_bio_bwrite
so we should keep udp still alive
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
It's possible to call linker indirectly through driver like Clang. In
which cases linker args has to be prefixed with -Wl.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This aligns declared function types in checkasm with real definition.
Fixes FATE: checkasm-{sw_rgb,sw_scale,sw_yuv2rgb,sw_yuv2yuv}
Fixes: runtime error: call to function <func> through pointer to incorrect function type
Fixes: c1a0e65763
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Skipping backwards (and even forwards) resets the EOF flag, and can thus
lead to infinite looping if the conditions are just right.
Fixes: Infinite loop
Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Old Mingw-w64 releases provided by some distros seemingly don't have them, so
check for them and disable the dtls protocol if unavailable.
Signed-off-by: James Almer <jamrial@gmail.com>
If the image data is not at the start of the buffer allocation, such as
when the buffer has padding before the image data, this function maps too
much memory, since src_data + src_buf->size exceeds the buffer size.
Fix this by subtracting the difference between the buffer start and the
provided image data pointer from the size of the memory range to map.
An easy way to reproduce this issue is using the vf_pad filter, which
allocates image data buffers with a nonzero offset whenever padding is
requested before the start of the image data.
The issue is that:
float en[2];
...
tns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;
for (g = 0; g < tns->n_filt[w]; g++) {
tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];
When using the AAC Main profile, n_filt = 3, and slant is by
default 2 (normal long frames), g can go above 1.
en is the evolution of energy in the frequency domain for every
band at the given window. E.g. whether the energy is concentrated
at the top of each band, or the bottom.
For 2-pole filters, its straightforward.
For 3-pole filters, we need more than 2 measurements.
This commit properly implements support for 3-pole filters, by measuring
the band energy across three areas.
Do note that even xHE-AAC caps n_filt to 2, and only AAC Main allows
n_filt == 3.
Fixes https://trac.ffmpeg.org/ticket/11418
Add check for the return value of av_malloc_array() and av_calloc()
to avoid potential NULL pointer dereference.
Fixes: dcfd24b10c ("avcodec/alsdec: Implement floating point sample data decoding")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adds support for high bit depth formats, as well as formats with fewer
than 3 planes. The implementation for HBD is the same as for 8 bit formats,
just right shifted to 8 bits.
It's worth pointing out that this also works for HDR formats (and even DV),
because the underlying implementation is just trying to minimize the histogram
difference. If anything, using a HDR format will result in a *more* accurate
detection, because HDR formats tend to be more perceptually uniform.
Enables timeline editing options for overlay_cuda similar to what overlay allows
Example overlaying an image on a video between 30 to 60 seconds:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i sample-video.mp4 -i sample-image.jpg
-filter_complex "[1:v]hwupload_cuda[image],[0:v]scale_npp=format=yuv420p[video],[video][image]overlay_cuda=enable='between(t,30,60)'"
-c:v h264_nvenc -c:a copy -y overlay-output-gpu.mp4
Signed-off-by: Jorge Estrada <jestrada.list@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Happens since 4fc874ef08
when this code is called via error resilience.
Also do the same for wmv2dec.c.
Fixes the vsynth_{1,2,3,_lena}-mpeg4-error and wmv2-drm-dec FATE-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The parameters here are not only unused, but buf_size's value
is actually wrong when flushing (it comes from the subpacket
of the last packet sent and is therefore outdated).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unused. Furthermore, this automatically fixes the issue
that init_get_bits() failure would lead to NULL + 0 (when
setting buffer_end) which is UB before C23. This happened
in the fic-avi and fic-avi-skip_cursor FATE-tests.
This saved 7296B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead of accessing unintialized data when input is shorter than
expected size.
Fixes use of uninitialized value in MSAN build.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Regardless of the source being an AVFMT_NOTIMESTAMPS format, if the timestamps
are generated like when using the use_wallclock_as_timestamps demuxer option,
then they are reliable.
Fixes ticket #11268
Signed-off-by: James Almer <jamrial@gmail.com>
The minimum valid packet length is 28, given that the length includes
the packet header.
This didn't cause any issues so far as the code did not care about the
last two fields in the SR section, but will be relevant in a future
commit.
Using SSL_CTX_set_options to disallow specific versions is
discouraged by the documentation, which recommends to use
SSL_CTX_set_min_proto_version instead.
As noted in the OpenSSL documentation, BIO_get_new_index must be
used to get a new BIO index. This is ORd with the proper type flag
BIO_TYPE_SOURCE_SINK.
Add TLS options to RTSP for when TLS is used for the lower protocol.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Co-authored-by: Marvin Scholz <epirat07@gmail.com>
Fixes: index 107 out of bounds for type 'uint16_t const[63]'
Fixes: 421336912/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-6436225806565376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -132524 * 16525 cannot be represented in type 'int'
Fixes: 414862270/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4869083202125824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 33632416 * 64 cannot be represented in type 'int'
Fixes: 421817631/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-4957386534354944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reduces allocations on random input
Fixes: 421650030/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMACKAUD_fuzzer-6144441767493632
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In aac/aac-fixed, also remove unnecessary aac demuxer dependency.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When CMD is crc/framecrc, always use the macros CRC/FRAMECRC, even if it
includes unnecessary requirements for rawvideo/pcm_s16le encoders (as
actually noticed in a comment of the Makefile).
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
First, always require file protocol when FATE suite is used.
Then, add missing dependencies while removing duplicates.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In config_input(), fir_to_phase() allocates memory in h[longer], which
would leak if av_calloc() to s->coeffs failed. lpf() allocates memory
in h[0] and h[1], which would leak if fir_to_phase() failed. To fix
this leak, add av_free(h[longer]) in as cleanup code, and replace
return AVERROR* with goto cleanup to prevent from leaks.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CLI option parser checks if argument exists when needed, but in this
case only OPT_TYPE_BOOL where checked, so OPT_TYPE_FUNC without argument
where trying to load a file from `arg` which is NULL in this case.
Fixes crash on `ffmpeg -/version`
Fixes: 6d17991b7e
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Integer writing is impossible here as the first branch was dead code,
so remove it completely.
Fix CID 1646948
Reviewed-by: softworkz <softworkz@hotmail.com>
This patch adds the pad_cuda video filter. A filter similar to the existing pad filter but accelerated by CUDA.
The filter shares the same options as the software pad filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf "pad_cuda=w=iw+100:h=ih+100:x=-1:y=-1:color=red" out.mp4
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes: signed integer overflow: 30 + 2147483647 cannot be represented in type 'int'
Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-6568264620900352
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In ff_wms_parse_sdp_a_line(), it allocates memory in buf, but doesn't
free buf when avformat_alloc_context() failed. Add av_free(buf) before
return to prevent from leak.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In sunrast_decode_frame(), we use av_malloc_array() allocates memory
to ptr and ptr2. However if buf_end - buf < 1, this function returns
error code without freeing this memory thus cause a leak. Add av_freep()
before return.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_mallocz() allocates memory in config, but we forget to free it
if init_get_bits() failed. Replace return ret with goto end.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
alfilter_graph_request_oldest() might return EAGAIN and produce a frame on not
the oldest sink.
Fixes ticket #11597.
Fixes excessive frame buffering in #10959.
Fixes excessive frame buffering in #11366.
Signed-off-by: Marton Balint <cus@passwd.hu>
A frame graph activation might not produce a frame in the requested sink, so
keep on requesting a frame there unless we encounter a filter activation with
buffersrc empty error.
This makes av_buffersink_get_frame(_flags) work according to its documentation
which claims that EAGAIN is only returned if additional frames must be inserted
into the graph.
Fate changes are because audio frames will have different sizes at segment
boundaries, but content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
Sinks without an activate callback have no means to request frames in their
input, therefore the default activate callback should do it for them.
Fixes ticket #11624.
Fixes ticket #10988.
Fixes ticket #10990.
Signed-off-by: Marton Balint <cus@passwd.hu>
Even if all inputs are blocked an activate callback should request a frame on
some if its inputs if a frame is requested on any of its outputs.
Signed-off-by: Marton Balint <cus@passwd.hu>
EOF only need to be forwarded back if all outputs have reached EOF.
Fixes infinte loop with ffprobe -f lavfi -i "smptebars=d=1,select=n=2:e=1[out0][out1]"
Regression since d9e41ead82.
Fixes ticket #10959.
Fixes ticket #11366.
Signed-off-by: Marton Balint <cus@passwd.hu>
The status check is unneeded because an outlink with a nonzero status should
always return 0 for ff_outlink_frame_wanted(). Also use unsigned for index
because nb_outputs is unsigned as well.
Signed-off-by: Marton Balint <cus@passwd.hu>
Instead of setting these unconditionally (they are always zero
for H.261, MPEG-1/2, RV30/40, VC-1), add a variant of
ff_mpeg_er_frame_start() that sets them and remove setting them
from ff_mpeg_er_frame_start(). Also pass these values via parameters
instead of reading them from the MPVContext itself.
This will allow to move them from MPVContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It used to be a tri-state encoding both whether to use FLV picture
headers and whether to use the FLV way of encoding escape values,
but the former is now unnecessary due to the switch to a function
pointer for reading the header. So binarize h263_flv.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead add the necessary blocks directly into Mpeg12SliceContext.
This allows to completely remove MPVContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These files currently rely on implicit inclusions of avassert.h
and/or mathops.h via get_bits.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a GetBitContext to H263DecContext instead. This is in preparation
for removing MpegEncContext.gb.
Also move last_resync_gb to H263DecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead add the necessary blocks directly to H263DecContext
(only six are needed, not 12 as ff_mpv_common_init()
currently allocates).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With the exception of mpeg4_decode_studio_mb(), all decode_mb
functions implicitly presumed that the block provided as
argument coincides with MpegEncContext.block (they zeroed the latter
and then used the former to decode the block); mpeg4_decode_studio_mb()
meanwhile did not use the provided block at all (it uses blocks of
int32_t). So remove said parameter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for moving the fields only used
by H.263-based decoders from MPVContext to H263DecContext.
For now only the decode_mb function pointer has been moved
(to be able to switch said callback to use an H263DecContext*).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code in h263dec.c is not supposed to know that the MPEG-4
decoder uses an Mpeg4DecContext as private context at all
(said context is only exposed in a header so that hardware
accelerations can access it and for the parser to use).
Passing an MPVContext* directly also allows to remove
the indirection via AVCodecContext.priv_data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This basically reverts d4967c04e0.
Said commit was based on the false premise that it would
be an aliasing violation to upcast a pointer to structure
to a pointer to a bigger structure containing the original
structure as its first element, but this is just not true.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead add the necessary blocks directly to VC1Context
(only six are needed, not 12 as ff_mpv_common_init()
currently allocates).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a GetBitContext to VC1Context instead. This is in preparation
for removing MpegEncContext.gb.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These decoders only need a single 4x4 block; put it in RV34DecContext.
This is in preparation for removing MpegEncContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead put it into H261DecContext. This is in preparation
for removing MpegEncContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In the common case of decoding 420 content, only six blocks are used
and it makes perfect sense for the caller to only have that many.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unused (because unquantizing/the idct has been disabled)
apart from FF_DEBUG_DCT_COEFF debug code which makes no sense
when this function is called via error resilience. So pass a NULL
as block when calling ff_mpv_reconstruct_mb() from mpeg_er_decode_mb()
and disable the debug code in this scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to hint to the compiler that the branch is likely
not taken by marking the factored out function as av_cold.
It is also in preparation for further commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MpegEncContext is also used for decoding, so it is a misnomer.
This commit therefore adds MPVContext as typedef for it in order
to gradually switch the code to the new name (in line with
MPVEncContext).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids mpegvideo.c having to deal with the fact that
the encoders use two sets of blocks and is in preparation
for not allocating blocks at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The H.263 decoder itself does not need max_run/max_level
of this RLTable, only the MPEG-4 decoder does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only very few combinations (2x102) of 16384 correspond to
valid codes; so just initialize all codes via memset
and then set the few valid codes explicitly instead of initializing
everything in the same way.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Already checked generically as none of the codecs here
have the AV_CODEC_CAP_CHANNEL_CONF set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
None of the codecs used here has the AV_CODEC_CAP_CHANNEL_CONF
cap set, so the sample rate is checked generically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check that all audio codecs except decoders with the
AV_CODEC_CAP_CHANNEL_CONF flag have a positive sample rate set.
Fixes: AVERROR_BUG return
Fixes: 413997604/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-5188382613635072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch, the DFPWM1a encoder was marked as supporting
variable frame sizes. The DFPWM1a format converts eight bytes
of input into one output byte and so it simply padded the number
of data output by
frame->nb_samples * frame->ch_layout.nb_channels / 8 +
(frame->nb_samples % 8 > 0 ? 1 : 0)
This has several bugs:
a) The additional byte leads to eight additional input byte being
read; this can read into the frame's padding, i.e. the data can
be uninitialized.
b) The criterion for whether one should pad is wrong:
nb_samples * nb_channels should be tested for divisibility by eight.
c) The created frames can be undecodable (at least with our decoder):
Our decoder requires the number of bits per frame to divisible by
the number of channels, yet the above approach does not guarantee this.
d) The padding will be added in the middle of the stream (potentially
for every packet).
This commit fixes all of this by removing the variable frame size cap
and using AVCodecInternal.pad_samples to pad the last frame so that
nb_samples * nb_channels is always a multiple of eight.
The lavf-dfpwm FATE-test was affected by a). The frames originated from
lavfi and were part of an audio frame pool, so that the padding
contained data from an earlier (bigger) frame. Now the last frame is
properly filled with silence.
Reported-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use av_frame_replace() instead. Also remove the error message:
It was highly misleading (as if av_frame_clone() duplicated
the AVFrame data buffers instead of just creating a new reference).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calling a function via a different function pointer type is
undefined behavior (C11, 6.3.2.3 8); two pointer parameters
of different type are not equivalent in this regard, although
it happens to work in practice; the current code relies on this.
This patch brings the code in line with the spec. This fixes the
following FATE-tests when run with Clang-UBSan:
ac3-fixed-encode-2 audiomatch-afconvert-{16000,44100}-mono-he-{adts,m4a}
audiomatch-dolby-44100-mono-he-mp4 filter-metadata-avf-aphase-meter-mono
filter-pan-{downmix1,downmix2,mono2,stereo2,stereo3,stereo4,upmix1,upmix2}
lavf-dv_{pal,ntsc} matroska-encoding-delay
The error was something like
src/libswresample/rematrix.c:621:17: runtime error: call to function sum2_float through pointer to incorrect function type 'void (*)(void *, const void *, const void *, void *, int, int, int)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes the following FATE-tests when run under Clang-UBSan:
ffmpeg-loopback-decoding, lavf-mxf_ffv1,
vsynth{1,2,3,_lena}-ffv1-v{0,2}, vsynth1-ffv{1,2,3,_lena},
vsynth{1,2,3,_lena}-ffv1-v3-yuv{420p,422p10,444p16}
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes the following error when running with Clang-UBSan:
src/libavcodec/indeo3.c:556:26: runtime error: applying non-zero offset 2560 to null pointer
This fixes the indeo3-2 FATE test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added support for MV-HEVC encoding for stereoscopic videos (2 views
only). Compatible with the framepack filter when using the
AV_STEREO3D_FRAMESEQUENCE format.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
In parse_cinespace(), memory allocated in in_prelut[] and out_prelut[]
would leak if allocate_3dlut() failed. Replace return ret with goto end
to free memory before return error code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In put_main_header(), av_mallocz() allocates memory to local variable
buffer, buffer leaks if av_mallocz() to *out failed. Add av_free(buffer)
before return error code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ret value is checked later on again, so this check
is redundant and would cause the frame to not be unrefd on
failure as well.
So remove this check and add one before av_frame_remove_side_data
to ensure it is not called with an invalid frame.
Fix CID 1648350
Reviewed-by: Frank Plowman <post@frankplowman.com>
Regression in ffprobe since textformat introduction
in d7a3f68fea.
Fixes#11638
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Reviewed-by: softworkz <softworkz@hotmail.com>
This would make the goto dead code and also would not properly
call avtext_context_close.
Fix CID 1646939
Reviewed-by: softworkz <softworkz@hotmail.com>
Add handling here for
sps_scaling_matrix_for_alternative_colour_space_disabled_flag.
Also add parentheses to make behaviour a little more explicit,
where &&'s precedence over || was relied on previously.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Frank Plowman <post@frankplowman.com>
Make sure the WHIP protocol performs the SDP offer/answer
exchange with the WebRTC peer over HTTP.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Jack Lau <jacklau1222@qq.com>
h264_annexb_insert_sps_pps (called after write_packet)
reorganizes PPS, SPS, and IDR packets in H.264 streams.
Since write_packet already validates pkt,
redundant null checks in h264_annexb_insert_sps_pps can be removed.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Since 155508c6e9 specifying multiple
bsfs for different streams was broken:
"[bsfs/a=h264_metadata:bsfs/v=h264_metadata]out.mp4|..."
This incorrectly only parsed the first bsfs specification. The reason
for this is that the dictionary is modified in the iterator, hence
invalidating the iterator. The simplest fix for this is to simply
iterate from the beginning in each loop given that the previous entry
is removed.
The way streams are coded in an IAMF struct follows a scalable model where the
channel layouts for each layer may not match the channel order our API can
represent in a Native order layout.
For example, an audio element may have six coded streams in the form of two
stereo streams, followed by two mono streams, and then by another two stereo
streams, for a total of 10 channels, and define for them four scalable layers
with loudspeaker_layout values "Stereo", "5.1ch", "5.1.2ch", and "5.1.4ch".
The first layer references the first stream, and each following layer will
reference all previous streams plus extra ones.
In this case, the "5.1ch" layer will reference four streams (the first two
stereo and the two mono) to encompass six channels, which does not match out
native layout 5.1(side) given that FC and LFE come after FL+FR but before
SL+SR, and here, they are at the end.
For this reason, we need to build Custom order layouts that properly represent
what we're exporting.
----
Before:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 5.1(side)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 5.1.2
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 5.1.4
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
----
AFter:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 6 channels (FL+FR+SL+SR+FC+LFE)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 8 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 10 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR+TBL+TBR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Signed-off-by: James Almer <jamrial@gmail.com>
Follows the proper order defined by the spec, even if mostly cosmetic, and is
also preparation for a following change.
Signed-off-by: James Almer <jamrial@gmail.com>
In most cases, the channel ids will match the standard Ambisonic Order, saving us the
need to use a custom order layout.
Signed-off-by: James Almer <jamrial@gmail.com>
After 3b26b782ee, `ebur128->true_peak` was only set to the maximum of the
current "true peak per frame" values, when it should report the true peak for
the entire stream.
Fixes: 3b26b782ee
It is unnecessary for decoders (they just set
AVCodecContext.sample_fmt). This also fixes a warning
with Clang (because sample_fmts is set directly,
not via CODEC_SAMPLEFMTS).
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The issue is that vulkan_device_create_internal() is only called for
devices that lavu creates by itself.
For external devices, this was never done.
This also solves some mid-function declaration warnings.
Fixes: division by 0
Fixes: 418396712/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-6104388018176000
Fixes: 418478219/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4569544410857472
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>
We have been contacted by Monet du Plessis of the etherium foundation and
Natascha Buck (Grants at the Better Internet Foundation)
"The Ethereum Foundation is thrilled to inform you that your contribution to
open-source software development through your work on ffmpeg
https://github.com/FFmpeg/FFmpeg has been recognized and rewarded by the
Devcon team! Your project played a fundamental role in the success of Devcon
<http://devcon.org/>, helping to create a more meaningful experience for
the Ethereum community. In collaboration with Drips Network
<https://www.drips.network/>, we are pleased to award you $2,240.00 in
appreciation of your efforts and to support your continued efforts in
open-source development."
To be able to claim donations through the drips network we need to
specify a wallet to do so in FUNDING.json
This will also allow FFmpeg to receive future funding and donations
through the drips network.
The specified wallet is a safe wallet backed by a ledger hw wallet.
We can later change who controls the safe wallet. (For example it
could be passed on to the SPI treasurer)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This returns to code closer to prior 56c334d732
The prior fixes should limit the sum and avoid the need for double argument log2()
Fixes: Assertion n>=0 && n<=32 failed at libavcodec/get_bits.h:406
Fixes: 410109093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6550900028276736
No testcases except fuzzers
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 410109093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6550900028276736
Note, none of the available osq files uses update_stats(), this change may fix or break
files using coding_mode == 2. The code prior looks wrong though
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Need to skip 2 more bytes because comp sections are 12 bytes long.
Fixes decryption since ciph_type is now being set.
Signed-off-by: Pavel Roslyy <roslypav@gmail.com>
The codecviewfilter, when used with qp=1, did not display quantization parameter values for H.264 streams because the QP table extraction was restricted to MPEG-2 video.
This patch enables H.264 support by updating ff_qp_table_extractto accept AV_VIDEO_ENC_PARAMS_H264. This allows for correct QP overlay on H.264 video
Signed-off-by: Timothee <timothee.informatique@regaud-chapuy.fr>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the apperture window is bigger than the canvas, then the clap box is invalid
and there's no point calculating cropping values.
Fixes: libavformat/mov.c:1295:14: runtime error: -256 is outside the range of representable values of type 'unsigned long'
Signed-off-by: James Almer <jamrial@gmail.com>
This feature fundamentally relies on host-visible VRAM, which restricts the
set of available memory types to (typically) host-visible device-local ones.
When resizable BAR is disabled, this memory type is usually limited to
e.g. 256 MiB in size, which is just plain insufficient for allocation of
general purpose GPU images, causing OOM errors on even the simplest of
commands.
The easiest solution is to disable host transfers entirely on machines
without host-addressable VRAM. In theory, we could try and recover the use
of host transfers for images which are *not* restricted to device-local
memory types, but this is rarely the case in practice, and the effort
required would exceed the benefit, especially since ReBAR is a standard
feature on all platforms recent enough to have Vulkan drivers, and only
occasionally disabled in the UEFI for by default for some hare-brained
notion of "backwards compatibiility" with ancient software.
acelp_kelvin, g729, qcelp, sipr and wmavoice decoders all depend upon
mips/{acelp_filters_mips,celp_filters_mips,acelp_vectors_mips}.o when
arch is mips.
g723_1 depends on mips/{celp_filters_mips,acelp_vectors_mips}.o.
comfortnoise, evrc, ra144 and ra288 depend on mips/celp_filters_mips.o.
The check for whether we can use the fast path to process
AC coefficients used the qscale value belonging to a different
slice; this worked in practice, because the predicted AC values
are zero in this case, so it does not matter whether we use
the fast or the slow path.
Fix this by checking for first_slice_line instead. This fixes all
the races in the encoding part of the vsynth*-mpeg4-thread tests
(and fixes them if no frame threading is in use for the decoding part).
(The left prediction check may use data from a different slice, too,
but said slice is always processed by the same thread, so that no race
can happen. Given that out-of-slice AC values are zero, it does not
matter whether we use the fast path or the slow path either.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only used by the decoder now that the encoder solves
out-of-slice predictions by setting the out-of-slice
values appropriately.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Now that every slice (and therefore every thread) uses its own
DC array, one can simply set the out-of-slice DC values to its
expected values (this is not possible for the decoders due
to error resilience).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes data races (which are UB) in the MPEG-4 and H.263+
encoder when predicting DC values; these encoders unconditionally
read values from the line above the current line and only check
lateron (via first_slice_line) whether said prediction can be used
at all. It will also allow to remove said checks (by setting the
entries to 1024 upon opening a new slice).
The vsynth{1,2,3,_lena}-mpeg4-thread FATE tests were affected by this:
https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-tsan-slices&time=20250613002615
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The chroma dc_val pointers are mostly unused (accesses use
dc_val[0] and block_index), so remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, they are marked as dirty (filled with 1), meaning that
the entries are in need of a reset via ff_clean_intra_table_entries();
but actually, the entries are initialized to the state that
ff_clean_intra_table_entries() produces, so they can be marked
as non-dirty (i.e. filled with 0).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are currently allocated separately per slice; allocating them
jointly allows to avoid saving them in ff_update_duplicate_context().
The way it is done also avoids allocating ac_val for encoders that
don't need it (e.g. H.263 or H.263+ with AIC).
This entailed moving setting nb_slices to ff_mpv_init_context_frame()
which is called from ff_mpv_common_frame_size_change(). The resultant
nb_slices will always be one when called from a decoder using
ff_mpv_common_frame_size_change().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for removing removing ac_val[1]
and ac_val[2]. ff_mpeg4_clean_buffers() was the last user of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said block will only be referenced by blocks from the same macroblock,
which will read the new AC values instead of the reset values
from this function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The underlying element type has always a size of 32B,
so that the pointer is always at least 16B aligned.
Clang uses this to upgrade the (inlined) memset to
aligned stores. GCC doesn't (it does it only when
the alignment hint is provided via __builtin_assume_aligned).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are already mostly unused; not using them here is in
preparation for removing them altogether. Use block_index[4..5]
instead for addressing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All callers check the corresponding entry of MpegEncContext.mbintra_table
and if set (indicating that the intra tables might have been written to
when decodeing a intra MB, so that they are "dirty"), call
ff_clean_intra_table_entries(), which resets them to default values
and resets the mbintra_table entry. Move resetting to the callers
(via an inline function that also performs the checks). This currently
has the advantage that the additional load of the mbintra_table ptr
can be avoided. It will also allow to simplify
ff_clean_intra_table_entries() (by using block_index[4] and [5]).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Allocate them before the slice contexts, so that they are automatically
copied to the slice contexts. This avoids having to set them in a loop.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow to perform initializations between ff_mpv_common_init()
and ff_mpv_init_duplicate_contexts() that will be automatically
copied to the slice contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The motion estimation code only uses block_index[0..3],
so only initialize that (just like estimate_motion_thread()
in mpegvideo_enc.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really needed, as none of the buffers allocated
in ff_mpv_common_init() are used lateron; in fact, ff_mpv_common_init()
is called with MpegEncContext.width and height equal to zero
(as well as encoding equal to zero, so that the error resilience
parts are initialized...), so that all the buffers are too small
anyway.
The call to ff_mpv_common_init() has been added in commit
f6774f905f in order to allocate
{current,last,new}_picture.f (an AVFrame). Yet this is unnecessary
since 7814dd77aa.
The only task that ff_mpv_common_init() does that may be used
is initializing the HpelDSPContext embedded in the MpegEncContext.
In fact, it was not initialized before
f6774f905f and not initializing
it passes FATE, yet I can't prove that it is indeed unnecessary.
Therefore it is still initialized and used instead of
SVQ1EncContext.hdsp.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 65015003f5;
after said commit, freeing scratchbuf on error in svq1_encode_frame()
could lead to segfaults lateron, because the buffer will not
be allocated again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the MPEG-1/2 decoders unquantize the blocks
on their own, block_last_index is only used to signal
to ff_mpv_reconstruct_mb() whether a block is skipped
or not; but this is only checked for inter macroblocks,
so it is unnecessary to set block_last_index for intra
macroblocks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Overriding the number of coefficients is only necessary if
ac_pred is in used, not for h263_aic alone (for which only
the DC coefficient is predicted) as it is done here.
And since d50635cd24
the H.263 unquantize-intra functions override the number of
coefficients in case of ac_pred, so we don't have to do this here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
This caused configure to hang for some configurations and by
extension some FATE clients. You might want to check if you run
affected configurations automated in FATE clients or similar setups.
Fixes: 45a30e0361
Signed-off-by: Martin Storsjö <martin@martin.st>
This should prevent the possibility of audio data accumulating.
The commit also cleans up and simplifies the code a bit so all frame producers
(filter_frame(), flush_frame()) functions follow similar logic as
ff_inlink_consume_frame() for the return code.
Signed-off-by: Marton Balint <cus@passwd.hu>
Easier to read, less convoluted, and ~30% faster. Most importantly, this
avoids repeating the redundant recalculation of the true peak on every
single sample, by moving the FIND_PEAK() loop out of the main loop. (Note
that FIND_PEAK() does not depend on the current sample index at all, so
there is no reason for it to ever be recomputed here)
Processes two channels in parallel, using 128-bit XMM registers.
In theory, we could go up to YMM registers to process 4 channels, but this is
not a gain except for relatively high channel counts (e.g. 7.1), and also
complicates the sample load/store operations considerably.
I decided to only add an AVX variant, since the C code is not substantially
slower enough to justify a separate function just for ancient CPUs.
Instead of having a planar array for each channel, use a single packed array.
This will help processing multiple channels in parallel, as we can directly
load all channels' data in a single load instruction.
Also improves memory locality of data, as the loop order is:
for (samples) {
for (channels) {
process sample
}
}
This patch doesn't effect WHIP usage via command, as WHIP always
needs to be explicitly specified
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
In higher versions (openssl 1.0.2 and higher),
the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
so passing a const string doesn't cause an warnings.
However, in lower versions of OpenSSL,
the function signature becomes BIO *BIO_new_mem_buf(void *buf, int len),
which leads to warnings.
OpenSSL guarantees that it will not modify the string,
so it's safe to cast the pem_str to (void *) to avoid this warning.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This was requested by users of `vf_libplacebo`, to mirror the existing
option on the other `vf_scale_*` family of filters. While we have
`vf_normalize`, it was not as useful in the event that the content
stretching was actually desired.
Bridges an important usability gap between `vf_scale` and `vf_libplacebo`
that made mixing and matching the filters needlessly difficult.
This aligns the behavior of vf_libplacebo with other filters in the
vf_scale family, that forward any change in the SAR as a result of
changing the output resolution to the output frame / link, and updates
the ff_scale_adjust_dimensions() call to continue working as intended.
The new behavior reflects the documentation of vf_libplacebo, which
described this behavior despite that not being the way the filter worked
up to this point.
As an aside, also fixes a bug where the AVFrame SAR was inconsistent
with the AVFilterLink SAR when the s->nb_inputs > 1 condition was met.
Under normal circumstances, this change does not affect anything, as the vast
majority of filters either support only vulkan or only software formats.
However, when a filter supports both (such as vf_libplacebo itself, and
possibly vf_scale in the future), linking together two such filter instances
without an explicit format will default matching the input format, resulting
in a redundant round trip through host RAM.
This change bumps up AV_PIX_FMT_VULKAN to the first entry in the format list,
ensuring that it gets preferred whenever possible.
When running plain "cl", to get the MSVC version, it prints the
version header on stderr, while the usage instructions are printed
on stdout. Usually, the version on stderr gets flushed first,
so "head -n1" gets the line it expects, but some times (in particular
when running MSVC wrapped in wine), it can get the usage line
first.
Redirect stdout to /dev/null, so we only grab the version among
the lines printed to stderr. This should make the version number
grabbing more robust.
At least all relevant versions of MSVC seem to print this specifically
to stderr, not stdout (so we don't risk to miss it); checked down
to MSVC 2010.
Signed-off-by: Martin Storsjö <martin@martin.st>
In sbg_read_header(), if avformat_new_stream() failed, it returns
without cleanup, which may cause memory leaks. Replace return statement
with goto so that we would first clean up then return.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Changed the minimum required version of liboapv from 0.1.13 to 0.1.13.1
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
LLVM tools print installation path upon execution. If one uses LLVM
tools bundled with Microsoft Visual Studio installation, they would be
incorrectly detected as Microsoft's ones.
Microsoft tools can have localized names, so a more specific string
check is not feasible, but luckily we can test if "Microsoft" is at the
beginning of the line, as it is always the case.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Tests both the Media 100 decoder (using the media100_to_mjpegb BSF
implicitly) as well as using said BSF, followed by the MJPEGB decoder.
(We currently hit a bug when remuxing: The demuxer treats compressorname
as encoded in a Mac character encoding (Mac OS Roman?) and converts
it to UTF-8, yet the muxer just writes it.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise the extradata used would be ISOBMFF if the input is
even though we use the *_mp4toannexb BSFs to convert it to
annex B to feed it to the actual decoder.
(The mediacodec decoders also use said BSFs, yet they process
the extradata in a way that works even when using the ISOBMFF
extradata; in fact, using the converted extradata would break
their check for whether to warn for missing extradata for
the ISOBMFF without-in-band-header profiles.
Furthermore, there are several users of the *_mp4toannexb BSFs
that don't ever touch extradata. They have not been touched.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 1c17061397.
The commit intended to provide certain codecs using *_mp4toannexb
bitstream filters with updated (annex B) extradata (even when
the user-supplied one was ISOBMFF), yet BSFs are allowed to change
way more. The media100_to_mjpegb BSF used by the media100 decoder
changes the codec id; the commit being reverted therefore changed
AVCodecContext.codec_id which is an API violation and broke
media100 decoding with the FFmpeg cli tool.
This commit also made changes from the internal BSF externally
visible. extradata is documented to be "owned by the codec and
freed in avcodec_free_context()" which does not include replacing
it with something else in avcodec_open2() and may surprise users
who think that AVCodecContext.extradata is immutable before
avcodec_free_context(). It also incurred a memdup which is completely
unnecessary for most decoders.
Therefore this commit is reverted. The problem it tried to solve
will be solved differently in the next commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When chroma subsampling is in use, the filter averages
the corresponding (non subsampled) alpha values to get
the actual alpha value. When vertical subsampling is
in use, the next line is accessed via a[src->linesize[3]],
yet a is an uint16_t* for >8 bit formats and linesize
is always in bytes, so that this actually uses the second
line below the current one. This is fixed in this commit.
No FATE test needed updates, because the filter-overlay-yuv420p10
and filter-overlay-yuv444p10 tests use a yuv420p test file
that has constant opacity after conversion to yuva.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just keep the pointers for the beginning of a line uint8_t*
and use uint16_t* to do the actual processing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens when the pixel format of the output does not
have an alpha channel. It leads to FATE failures with
the ffmpeg-filter_colorkey, filter-overlay-dvdsub-2397
filter-overlay,
filter-overlay_{gbrp_gbrap,nv12,nv21,yuv420,yuv420_yuva420,
yuv420p10,yuv422_yuva422,yuv422p10,yuv444_yuva444,yuv444p10}
and sub2video tests when using Clang UBSan.
Fix this by only performing the pointer arithmetic when
it is going to be used. This can be checked via variables
that compile-time constants due to inlining, so that the
checks are free. Given that the pointer is potentially
used as a function argument, the compiler could elide
the calculation, but not it can. The size of .text decreased
by 1632B with GCC 14 and by 1392B with Clang 19 (both -O3).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This otherwise generates an inconsistency between the frame state and the
link state, since the link state is set to 1:1 explicitly when `reset_sar`
is enabled, but this line of code unconditionally overwrote the output
frame SAR with the value that would be computed in the absence of `reset_sar`.
cf. vf_scale_cuda, which does this correctly
The segment_duration must not be set to zero when writing the moov
atom for the second time. This is related to edit lists in standard
MP4 files.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In libavformat/rtmpproto.c:gen_connect(), if check on string length
or check on codec fourcc failed, ff_rtmp_packet_create() allocated
data in pkt would leak. Add ff_rtmp_packet_destory before return error
code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is useful for tests that compare dctcoefs which will be either 2 bytes or
4 bytes, depending on bitdepth.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When seeking on multi-angle titles, libdvdnav does not lock on
to the correct sectors initially as it seeks to find the right NAV packet.
This manifests itself as two bugs:
(1) When seeking on the first angle in a multi-angle segment,
frames from another angle will appear (for example in intro
or credits scenes). This issue is present in VLC also.
(2) When seeking during a segment on angle n+1, the demuxer
cannot deduce the right position from dvdnav and does not allow
seeking within the segment (due to it maintaining a strict state).
Correct the issue by switching to angle 1 before doing the seek
operation, and skipping 3 VOBUs (NAV packet led segments) ahead
where dvdnav will have positioned itself correctly.
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Marth64 <marth64@proxyid.net>
Just applying some UX polish.
This is to match the lowercase trend of attributes in
the dump string (and similar to chapters).
Signed-off-by: Marth64 <marth64@proxyid.net>
Change delta_timestamp to int32_t and add explicit cast to handle
RTP timestamp wraparound correctly. This fixes implementation-defined
behavior when computing negative timestamp differences due to 32-bit
wraparound.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b86996 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly.
Before 57861911a3, there was an
#elif defined(__GNUC__) || defined(__clang__)
case before the
#elif defined(_MSC_VER)
case for defining DECLARE_ASM_CONST, which included av_used.
(This case included the explicit "defined(__clang__)" since
f637046d31.)
After 57861911a3, it used the
generic definition of DECLARE_ASM_CONST that also included
av_used - which also worked for Clang in MSVC mode. But after
6e49b86996, Clang in MSVC mode
ended up using the MSVC specific variant which lacked the
av_used declaration, causing linker errors due to undefined
symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix incorrect enum value used in color primaries check by replacing
AVCOL_SPC_UNSPECIFIED with AVCOL_PRI_UNSPECIFIED.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
While the current code iterated over the messages, it always returned
in the first iteration. Instead keep iterating and warn for failure to
parse. At time of writing, none of the parsing functions seems to
actually return an error, ever.
Fix CID 1648348
When checking for filmgrain here, needs_fg can be true even when
film_grain_characteristics is NULL (when aom_film_grain.enable is true),
therefore this check could end up dereferencing film_grain_characteristics
even though it is NULL.
Fix CID 1648347
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not really valid.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
On NVIDIA, there's a global maximum limit of approximately 112 queues,
which means it takes ONLY 7 total programs using the maximum amount of
queues to cause the driver to error out/*segfault* during initialization.
Also, each queue takes about 30ms to allocate, which quickly adds up.
This reduces the queues allocate to the minimum that we would be happy
with. Its not worth limiting decode/encode queues as they're generally
not a lot, and do help.
Commit 00b64fca55 introduced configure
detection for HAVE_POSIX_IOCTL but unfortunately this conflicts with
v4l-utils version 1.30, which itself checks for #ifdef HAVE_POSIX_IOCTL
in a public header and erroneously determines it to be true because we
define this to be 0.
Since this is only used for avdevice/v4l2, we rename this to something
else, namely ioctl_posix, simply to prevent the name conflict with the
file /usr/include/libv4l2.h at least until they can upstream a fix on
their end.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Based on a patch by nyanmisaka.
Fixes commit #9996.
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The GetBitContext API requires the buffer to be padded, and the documentation for
av_ac3_parse_header() does not specify it, so use a temporary local buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents potential null pointer dereference when querying
MaxL1ReferencesForB from codec-specific support structures
during GOP structure initialization.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
GCC/Clang is smart enough to emit minss/maxss the same way as these functions.
The only theoretical benefit was in x86_32, where x87 floats are used, but the
penalty of making the clipping opaque to the compiler's scheduler plus moving
values from mmx regs to xmm and back will offset any potential speedup.
x86_32 builds targetting anything made in the last two decades and a half
should use -msse -mfp=sse anyway.
Signed-off-by: James Almer <jamrial@gmail.com>
The rtp_set_prft() function incorrectly calculates the timestamp delta
when RTP timestamps wrap around the 32-bit boundary. The current code:
delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
treats both timestamps as large positive values, causing wraparound to
produce a large negative delta instead of the correct small positive delta.
For example, with a 90kHz video clock:
- last_rtcp_timestamp = 0xFFFFFF00 (near wraparound)
- timestamp = 0x00000100 (after wraparound)
- Current result: delta ≈ -4.3 billion ticks ≈ -47,721 seconds
- Expected result: delta ≈ +512 ticks ≈ +0.006 seconds
This causes prft->wallclock to jump backward by approximately:
- 90kHz video: ~47,721 seconds (~13.25 hours)
- 48kHz audio: ~89,478 seconds (~24.9 hours)
- 8kHz audio: ~536,871 seconds (~6.2 days)
Fix by casting the subtraction result to int32_t, which correctly
handles wraparound through modular arithmetic:
delta_timestamp = (int32_t)(timestamp - s->last_rtcp_timestamp);
This ensures the delta is always in the range [-2^31, 2^31-1], making
wraparound produce the correct small positive values.
Fixes timing jumps in applications that rely on Producer Reference Time
for media synchronization.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows detecting changes and regressions in side data related code, same as what
framecrc does for before already for packet data itself.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Code like FFMIN(MAX_DURATION_BUFFER_SIZE, avio_size(s->pb)) is not safe
as FFMIN() is a macro and avio_size() is thus evaluated multiple
times
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
add the missing data structure pkey in the tls_context
properly set this pkey and free it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
codec31/32 are similar to codec1/3 (RLE coding) but with two 4-bit pixels
per byte; they are only used in the Sega-CD release of Rebel Assault 1.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some of the calculated values were wrong and/or assigned
to the wrong pixel of the 4x4 block.
Found during testing with Rebel Assault Sega-CD release.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
it has a bug and its effects aren't that noticeable, esp. with
the smoothing applied to the whole picture by modern video display
engines.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The iirfilter is only used in its test tool since
01ecb7172b which
stopped using it in AAC, its only user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also "fixes" the inverted order of arguments in the av_malloc_array()
calls and therefore part of ticket #11620.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just do it like av_frame_replace().
Also "fixes" the swapped order or arguments to av_malloc_array()
(the first is supposed to be the number of elements, the second
the size of an element) and therefore part of ticket #11620.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(I don't know whether this can be triggered for a file with
nonnegative channel count, given that src's extended data can't
have been allocated in this case.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(Some more options could be set via this method
if the order in which the options are applied doesn't matter.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As described in section F.6.1 from ETSI TS 102 366.
Found-by: nyanmisaka
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We were using a mix of pointers to local variables read via AV_RL32/64 and
pointers directly to the texture buffer as keys to interact with the lookback
hashtables. On big-endian systems, these produced different values. This change
makes all hashtable interactions use direct pointers to the texture buffer and
only invokves AV_RL32 in the event of a lookback hashtable miss.
Signed-off-by: Emma Worley <emma@emma.gg>
It is unnecessary to align both key and val, as they are only accessed
via memcpy()/memcmp(), which has no alignment requirements.
We only need to ensure that that the entries as a whole
are suitable aligned for the probe sequence length.
Reviewed-by: Emma Worley <emma@emma.gg>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise ff_hashtable_freep() would try to free uninitialized
pointers upon allocation error (which happens in the corresponding
test tool).
Reviewed-by: Emma Worley <emma@emma.gg>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
0. WHIP Version 3.
1. The WHIP muxer has been renamed and refined,
with improved logging context and error messages for SSL, DTLS, and RTC.
2. Magic numbers have been replaced with macros and extracted to functions,
and log levels have been altered for better clarity.
3. DTLS curve list has been updated,
and SRTP profile names have been refined for FFmpeg and OpenSSL.
4. ICE STUN magic number has been refined,
and RTP payload types have been updated based on Chrome's definition.
5. Fixed frame size has been refined to rtc->audio_par->frame_size,
and h264_mp4toannexb is now used to convert MP4/ISOM to annexb.
6. OPUS timestamp issue has been addressed,
and marker setting has been corrected after utilizing BSF.
7. DTLS handshake and ICE handling have been optimized for improved performance,
with a single handshake timeout and server role to prevent ARQ.
8. Consolidated ICE request/response handling and DTLS handshake into a single function,
and fixed OpenSSL build errors to work with Pion.
9. Merge TLS & DTLS implementation, shared BIO callbacks, read, write,
print_ssl_error, openssl_init_ca_key_cert,
init_bio_method function and shared same data structure
10. Modify configure that whip is enabled only dtls is
enabled(just support openssl for now) to fix build error
Co-authored-by: winlin <winlinvip@gmail.com>
Co-authored-by: yangrtc <yangrtc@aliyun.com>
Co-authored-by: cloudwebrtc <duanweiwei1982@gmail.com>
Co-authored-by: Haibo Chen <495810242@qq.com>
Co-authored-by: Steven Liu <lq@chinaffmpeg.org>
Co-authored-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Improves compatibility with Resolume products by adding an additional
hashtable for DXT color+LUT combinations, and padding the DXT texture
dimensions to the next largest multiple of 16. Produces identical
packets to Resolume Alley in manual tests.
Signed-off-by: Emma Worley <emma@emma.gg>
Since a51279bbde,
hpeldsp_rnd_template.c was only included once and
one of the two functions in rnd_template.c was
only enabled once.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code to initialize the ungrouped bap mantissa tables
(bap 3 or 5) takes more bytes of .text than the tables itself;
they have therefore been hardcoded.
For GCC (14, -O3, albeit in an av_cold function), the initialization
code takes 99B each for the fixed and floating point decoders
(the code is currently duplicated), whereas the hardcoded tables
only take 96B. For Clang 19 it were 374B each (I don't now what
Clang was doing there).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVIOContext will be automatically flushed upon closure.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The resman_ctx pointer was accessed outside of its guarding
mutex.
Also make the ResourceManager static.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Setting print_graphs_format (in case no -print_graphs_format
option was specified) is racy, as is using av_strtok()
to split it. Both have been removed.
Notice that using av_strtok() was destructive: In the absence
of races the options would only have been applied for the
first initialization.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As the names imply, they are structs meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing structs, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
As the name implies, it's a struct meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing struct, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
The follow cmd output corrupted file before the patch:
ffmpeg -f lavfi -i color=blue,trim=duration=0.04 \
-f lavfi -i anullsrc,atrim=duration=2 \
-movflags +empty_moov+hybrid_fragmented \
-frag_duration 1000000 \
-frag_interleave 1 \
output.mp4
1. first_track is the first track with track->entry != 0. As in the
command above, video track (track index 0) has a single frame. When
flush the second fragment, first_track is 1, the audio track.
2. write_moof = i == first_track, so write_moof is false for i = 0.
3. When mov->frag_interleave != 0, mov->mdat_buf != NULL, because
it contains audio data. So avio_write is called before write_moof,
that is, the data write before moof, and mov_finish_fragment
executed with wrong mdat_start.
4. With normal fmp4 output, the error isn't obvious. With
hybrid_fragmented, ffplay output.mp4 shows a lot of error messages.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The default behavior for VVenC (since v1.10.0) is to create an IDR with
leading pictures for the first picture in decoding order (POC 32). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by vvenc).
Signed-off-by: Gabriel Hege <g+ffmpeg@hege.cc>
The MMX requantize functions have the MMX permutation
(i.e. FF_IDCT_PERM_SIMPLE) hardcoded and therefore
check for the used permutation (namely via a CRC).
Yet this is very ugly and could even lead to misdetection;
furthermore, since d7246ea9f2
the permutation used here is de-facto and since
bfb28b5ce8 definitely
impossible on x64, making this code dead on x64.
So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For certain arches (AARCH64, x86, generic) get_pixels and
get_pixels_unaligned always coincide for 8 bit input.
In these cases it is possible to avoid checks for unaligned
input in asvenc, dvenc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this commit, the input in get_pixels and get_pixels_unaligned
has been treated inconsistenly:
- The generic code treated 9, 10, 12 and 14 bits as 16bit input
(these bits correspond to what FFmpeg's dsputils supported),
everything with <= 8 bits as 8 bit and everything else as 8 bit
when used via AVDCT (which exposes these functions and purports
to support up to 14 bits).
- AARCH64, ARM, PPC and RISC-V, x86 ignore this AVDCT special case.
- RISC-V also ignored the restriction to 9, 10, 12 and 14 for its
16bit check and treated everything > 8 bits as 16bit.
- The mmi MIPS code treats everything as 8 bit when used via
AVDCT (this is certainly broken); otherwise it checks for <= 8 bits.
The msa MIPS code behaves like the generic code.
This commit changes this to treat 9..16 bits as 16 bit input,
everything else as 8 bit (the former because it makes sense,
the latter to preserve the behaviour for external users*).
*: The only internal user of AVDCT (the spp filter) always
uses 8, 9 or 10 bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes segfaults on systems where PixblockDSPContext.get_pixels
really requires to be properly aligned (e.g. ARMv7).
Before this commit input created by
-filter_complex nullsrc=s=740x576:r=25,format=yuv420p,crop=w=720:x=2
led to crashes.
(The unaligned strides are in violation of the AVFrame.linesize
documentation, unaligned pointers itself do not seem to be
prohibited for encoders.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not valid to call avio_close() on context that has not been open
with avio_open().
This fixes use of custom IO. (io_open / io_close2 callbacks)
Note that by default io_close2 is set to io_close2_default() which calls
avio_close(), so default case will work the same as before.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
This limits it to the smallest of the 3.
Alternatively uint16_t can be changed and then a larger limit used.
A Check will still be needed.
Fixes: 391974932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5966648879677440
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 394638693/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-4868142996455424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It invalidates (removes by duplicates) AVCodecContext.extradata
and AVCodecContext.coded_side_data which is quite surprising
and leads to bugs like #11617 where an AVCPBProperties
is used after it has been freed in ff_dovi_configure().
Reported-by: Ayose
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens on systems where get_pixels really needs
to be properly aligned, like ARMV7 or RISC-V. For these
systems, 0401ca714a caused
a bus error for the vsynth3-asv[12] tests, because
the stride in these tests is unaligned. See e.g.
https://fate.ffmpeg.org/report.cgi?slot=armv7-linux-gcc-13&time=20250527020548https://fate.ffmpeg.org/report.cgi?slot=rv64gcvb-linux-gnu-gcc&time=20250527001827
It can also happen (even before said commit) if the pointers
itself are unaligned, e.g. by using the crop filter:
ffmpeg -filter_complex nullsrc=s=740x576:r=25,format=yuv420p,crop=w=720:x=2 \
-c:v asv2 -f null -
The alignment requirements for the frames passed to encoders are
mostly undocumented; the only thing I could find is the documentation
of AVFrame.linesize: "For video the linesizes should be multiples
of the CPUs alignment preference". This means that the FFmpeg cli
violates our API.
Yet as the above command line shows, it can also happen with
unaligned pointers and there does not seem to be a prohibition
of this, so we need to handle this case. This commit does so
by using get_pixels_unaligned when needed.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check the alpha plane for (almost) transparent frames, instead of checking
the luma channel for almost black frames.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Up until now, our muxer wrote FFV1 in video-for-windows
compatibility mode out of concern for old demuxers that
only support that (whereas the demuxer accepts V_FFV1).
This commit switches to using native mode, because
a) V_FFV1 is around long enough so that old demuxers
should not be an issue (support in FFmpeg has been added
in commit 9ae762da7e
in March 2017/FFmpeg 3.3),
b) using native mode uses fewer bytes for the CodecPrivate,
c) the VfW extradata is zero-padded to an even length
if necessary, but our demuxer forgot to undo the padding
until very recently (92e310eb82),
so that there are many versions of our demuxer around that
are buggy wrt VFW, but not V_FFV1.
This affects the FFV1 extradata checksums, specifically
the (experimental) version 4 files with error check version 2*
as created by
ffmpeg -i ../fate-suite/mpeg2/sony-ct3.bs -c:v ffv1 \
-slices 16 -frames 1 -level 4 -strict experimental ffv1.mkv
VFW files like the above created by this muxer before this patch
would not work with an old demuxer.
*: Without error check version 2, the CRC for the whole extradata
is zero, which is not changed by appending a zero byte.
Reviewed-by: compn <ff@hawaiiantel.net>
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Legal since commit 1cd0a9be4b2d1e7c60184ec68404e00e46e3123e
(Jan 4) in the Cellar Matroska specification git repo.
We still hold out on muxing it due to compatibility with
old demuxers.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- merge forgotten uninit from work branch
- add set_str() function to free before overwriting
- fix some other leaks
Signed-off-by: softworkz <softworkz@hotmail.com>
The structure is padded to an even length with an internal
size field to indicate the real size.
The matroska-matroska-display-metadata test (writing FFV1
in VFW mode) was affected by this.
It should also fix ticket #11613.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
crcref needs to be set properly iff ec is two, regardless
of whether it has been explicitly set by the user or set
by default based on level/version.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On msys2, `uname -m` returns the architecture of the base msys2
layer. On Windows on arm64, the base msys2 layer itself is still
x86_64 only, even if running with e.g. the clangarm64 where the
windows native applications are built as aarch64.
If MSYSTEM_CARCH is set, use this instead of `uname -m` for
the default architecture. This gives the correct behaviour
for the clangarm64 environments. It also gives the correct
default for the 32 bit x86 environments such as `mingw32`.
(On `mingw32`, the fact that `uname -m` returned `x86_64`
hasn't been an issue, as both that and `i686` gets normalized
into `x86` internally in ffmpeg's configure.)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It is only used to indicate to ff_h263_show_pict_info()
that we are decoding H.263+; pass this information
via a function parameter instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This means that these buffers won't be allocated any more
for H.263+ with AIC disabled.
Also remove setting h263_plus for the RV20 encoder,
as it has only been done to force allocating dc_val.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just ensure that dct_unquantize_inter is set iff it is used
and check for the function pointer instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove checks from ff_xvid_idct_init()
(and also the AVCodecContext* parameter).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_xvid_idct_init() is now only called from ff_idctdsp_init()
and only if idct_algo is FF_IDCT_XVID.
This also implies that it is unnecessary to initalize
the permutation on our own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary: If the dst context is not already initialized,
then it will be initialized by memcpy(dst, src, sizeof(*dst),
which already initializes the IDCT to the desired one, potentially
followed by ff_mpv_common_init(), which does not touch the IDCT.
(This call has been added in f89d76c103;
the aforementioned copying took place back then, too, but
ff_mpv_common_init() reinitialized the IDCT to a non-xvid one,
therefore the initialization here has been added to fix
multithreaded decoding.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are sufficiently different to warrant their own functions;
in particular, the earlier code had two callsites for the actual
"write block" function, one for intra and one for inter, yet
the "write block" function nevertheless performed a check
(that the compiler can't optimize away) for whether the current
MB is intra or not.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While it offers modest speedups compared to the ordinary code,
removing it completely offers even bigger speedups; and given
that these speedups also exist in the ordinary mode, they are
even more important. The no-output code has a 7.8% performance
improvement (based on benchmarking mpeg4_encode_mb()), yet
removing the no-output code resulted in a 9.4% improvement.
Furthermore, the no-output code was broken for the majority of
its existence (until 9207dc3b0d)
and no one complained, so it is likely not used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-4 decoder can now initialize ff_mpeg4_rl_intra
directly given that the MPEG-4 encoder no longer wants
it performed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There four cases for the LUT entry: An ordinary entry
or one of three escaping methods. Three of these methods
are only rarely possible --they correspond to the 102
codes of the underlying VLC and so only 102 of 16384 entries
are possible.
The earlier code would nevertheless try them all for every
LUT entry and use the best one; the new code meanwhile only
uses one method (the fallback one (i.e. the worst)) for them all
and only processes the 102 valid entries afterwards.
The implementation used also means that index_run, max_level
and max_run of the RLTable are no longer needed; the earlier
code would initialize said static tables although they are only
used for a short time to initialize something else.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Multiple PutBitContexts are used when encoding partitioned
frames. When there are multiple candidates for macroblock types,
multiple states (namely the state before encoding the current MB,
the best state among the ones already tried and the current one)
need to be kept; duplicates of the PutBitContexts are among this
state. The temporary buffers for them are kept on the stack
in encode_thread() and their size is quite generous (MAX_MB_SIZE
- 3000 bytes). This commit uses tighter bounds, bringing the
size of the pb2 buffer down to 15 bytes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The reversible VLC tables use a simpler escaping method
than the ordinary VLCs: It does not use max_run, max_level etc.
and therefore one does not need to initialize these at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is confusing, because the AV_RL32("ASUS") already
returns an endian-independent value, so converting
it via av_le2ne32() makes no real sense: one would need
to transform the native value to le and write it as
a natie endian uint32_t for it to make sense (the current
code only works because le2ne32 and ne2le32 are the same
for both endianness that we care about). Or one can just
use AV_RL32 and create the number via MKTAG().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Removes implicit checks for "do I need to output the buffer now?".
Codesize with Clang 19 with -O3 decreased from 7136B to 6108B
(although asv2_put_level() is now inlined).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the encoder replicated all the border pixels
for incomplete 16x16 macroblocks. In case the available width
or height is <= 8, some of the luma blocks of the MB
do not correspond to actual input, so that we should encode
them using the least amount of bits. Zeroing the block coefficients
(as this commit does) achieves this, replicating the pixels
and performing an FDCT does not.
This commit also removes the frame copying code for insufficiently
aligned dimensions.
The vsynth3-asv[12] FATE tests use a 34x34 input file and are
therefore affected by this. As the ref updates show, the size
and checksum of the encoded changes, yet the decoded output
stays the same.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add three missing requirements on bitstream conformance from 7.4.3.19 of
H.266 (V3). Issue found using fuzzing.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When called for palette-predicted CUs, boundary_strength could cause
undefined behaviour due to accessing uninitialised motion information.
The spec doesn't include this, but in the reference software it seems
the deblock strength is always set to 0 for palette CUs due to some
implementation details: perhaps this is a spec issue?
Signed-off-by: Frank Plowman <post@frankplowman.com>
In d5dbcc00d8, it was hoped that detection
of subpicture overlaps could be performed at the tile level, so as to
avoid introducing per-CTU checks. Unfortunately since that patch,
fuzzing has indicated there are some structures involving
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The issue is that state->cur[] is 8-bits, but a+b+1 can overflow
before being clipped to 0xF in the following line, causing an incorrect
state to be saved for the next symbol.
This solves numerous bitstream desyncs, particularly when coefficients
with magnitude greater than 127 are sent.
Don't use a 7.1 EAC3 input file for which our decoder is not
bitexact; instead just use the asynth-44100-8.wav file
which (as a 7.1 file) exhibits the same issue fixed by
1b3f4842c1.
(Either the encoder or the resampler are still not completely
bitexact, so we limit the number of frames output.)
Also switch to a framecrc test so that the output channel layout
is directly contained in the ref file.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Flipping can already be accomplished by setting the crop_w/h expressions to
their negative values, so together these options can implement any of the
common frame orientations.
io_open and io_close2 callbacks may use opaque pointer stored in the
context. They are already inherited, so opaque should also be passed
through.
Fixes IMF playback in mpv.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Pierre-Anthony Lemieux <pal@sandflow.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The buffer references may not be writable at this point, as the decoder
calls get_buffer2() with the AV_GET_BUFFER_FLAG_REF flag.
Fixes races as reported by tsan, producing correct output regardless of
threading choices.
Signed-off-by: James Almer <jamrial@gmail.com>
Currently, planarRgbToplanarRgbWrapper() always sets the alpha value to 255,
without taking the bit depth into consideration.
This commit restricts the alpha value to the bit depth.
Currently, packed16togbra16() always sets the alpha value to 0xFFFF,
without taking the bit depth into consideration.
This causes a bug on x86, which can be reproduced with:
./libswscale/tests/swscale -unscaled 1 -src xyz12le -dst gbrap12be
The problem arises in ff_hscale14to15_4_ssse3(), in the conversion
from gbrap12be to yuva444p, which comes after the conversion from
xyz12le to gbrap12be.
It has something to do with pmaddwd not working on unsigned values.
There is some code to deal with 0xFFFF if the input has a bit depth of
16, but not for bit depths < 16.
We could fix ff_hscale14to15_4_ssse3() to also work correctly with
0xFFFF on bit depths < 16, or we could just not write 0xFFFF there in
the first place, which is what this commit does.
Currently, packed30togbra10() always sets the alpha value to 0xFFFF,
without taking the bit depth into consideration.
This commit restricts the alpha value to the bit depth.
Currently, planarCopyWrapper() assumes that src[3] must be NULL when
the source format has no alpha plane.
This commit updates the condition for filling the alpha plane based on
the number of components available in the source format as well.
The SLIBOBJS variable was introduced in 56572787ae but is no longer used.
Another variable, SHLIBOBJS, was introduced after SLIBOBJS, in 20b0d24c2f.
The functionality from SLIBOBJS was effectively migrated to SHLIBOBJS in b77fff47d0.
No code has used SLIBOBJS since.
This commit removes all remaining references to SLIBOBJS from the build system.
The issue is that there is an explicit lack of synchronization as only the very
first invocation writes symbols and updates the state, which other invocations
then store.
This commit will properly set the duration field of Opus AVPackets.
Currently, duration is set to 0 on Opus packets from the RTP demuxer.
The Ogg muxer depends on the duration field to properly compute the page granule
value. Without a proper duration, the granule will be wrong, and result in
negative pts values in ogg files.
See oggenc.c:657 (ogg_write_packet_internal)
This commit calculates using the opus_duration function, which was copied
from oggparseopus.c
I moved this functionality and the existing opus extradata functionality
(added by me in 6c24f2b) into a new rtpdec_opus.c file.
Reviewed-by: Tristan Matthews <tmatth@videolan.org>
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The backwards scanning done for incomplete final packets should not
assume a specific alignment at the end of the file. Truncated files
result in hundreds of thousands of seeks if the final packet does not
fall on a specific byte boundary, which can be extremely slow.
For example, with HTTP, each backwards seek results in a separate
HTTP request.
This changes the scanning to check for the end tag 1 byte at a time
and buffers the last 1 MiB to avoid additional seek operations.
Co-authored-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Justin Ruggles <justinr@vimeo.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
ol->frame_rate is 0/0, so we need to calcalute the correct value based on
the il->frame_rate instead. Also adjust the time base, PTS and frame_duration
values accordingly. (Logic taken from vf_tinterlace.c)
- Query GPU caps for B-frame support and warn if unsupported.
- Make `-max_b_frames` optional
- Drop explicit `-pa_lookahead_buffer_depth` requirement in
adaptive mode.
This allows the compiler to remove the implicit "Do I need to output
the PutBitContext buffer here?" checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code allowed callers to use arbitrary values as
symbols_size as long as no symbols were present.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This turned out to be very beneficial: For GCC 13, the codesize
of ac3_output_frame_header went down from 4522B to 1247B and
from 10762B to 9298B for eac3_output_frame_header. For Clang 17,
the numbers went down from 3923B to 2477B and from 8338B to 6548B
(always with -O3).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow the compiler to optimize the "is the cache full?"
branches away from some put_bits().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes a Clang warning when asserts are disabled:
"variable 'quant' is used uninitialized whenever switch default is taken
[-Wsometimes-uninitialized]"
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Useful to let the compiler and static analyzers know that
something is unreachable without adding an av_assert
(which would be either dead for the compiler or add runtime
overhead) for this.
The implementation used here enforces the use of a message
to provide a reason why a particular code is supposed to be
unreachable.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use av_frame_move_ref() instead of av_frame_ref().
This allows to remove the separate variable for whether
we have already returned the delayed last pic. It also
makes stream looping work when looping multiple times;
previously the delayed pic was only output the first time,
because last_frame_output was never reset.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The file has buggy timestamps (it uses B-frames, yet pts==dts)
and therefore the last frame is currently discarded by FFmpeg cli.
Using -fps_mode passthrough avoids this and provides coverage
of the SVQ3 draining logic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reduces indentation and avoids an extra variable for whether
a sequence header has been found.
It also fixes potential undefined behaviour:
NULL + 0 is undefined and happens when no extradata is available.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a 16bit field in the spec, so using a single
put_bits() to write it is more natural.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These have been added in 29644cb504
in 2007 at a time when the MPEG-1/2 parser just set
the AVCodecContext's dimensions when encountering a sequence header,
so that the checks for the coded dimensions didn't trigger.
Yet this is no more and so we can simply remove these redundant checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise the MpegEncContext would be unnecessarily reinitialized
once (this does not affect the output for an intra-only variant
like VCR2) in mpeg_decode_postinit().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is its only user. Also make it static and call it
before ff_mpeg_draw_horiz_band().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We used to create our own buffer, but still used the DR1 flag,
which is not how it's supposed to work.
Instead, use ff_get_encode_buffer, and either host-map the buffer
before copying each slice via GPU transfers, or just copy each
slice manually if that fails or is unavailable.
Use 16-byte alignment (align=4) instead of 4-byte (align=2) in the function and
const macros. This improves instruction fetch and NEON load performance on
modern AArch64 CPUs.
I have several .ts captures where video and audio codec changes even
though the PMT version does not change and the PIDs stay the same.
This happens during transition to/from slate (mpeg2 video and audio)
to network broadcast (hevc video and eac3 audio in private PES).
I've updated fate ts-demux expected results.
The current loop only works if the input and output have the same number
of planes. However, with the new scaling logic, we can also optimize into a
noop the case where the input has extra unneeded planes.
For the memcpy fallback to work in these cases we have to instead check if
the *output* pointer is set, rather than the input pointer.
The old limits were a bit too tightly clustered around 1.0. Make the
value range much more generous, and also introduce a new highlight
for speedups above 10.0 (order of magnitude improvement).
Fixes remaining \r\n is ASS header after 57c545090d.
Fixes AVERROR_BUG error during init as this decoder expected `\r\n` in
default ASS header. strstr(..., "\r\n[Events]\r\n") failed after changes
in 57c545090d.
Fixes ticket #11545.
Fixes: 57c545090d
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Also return an better error code if it is set numerically.
(This option was added in 2862b63783
when an AVCodecContext generic option was moved to
a codec private one without realizing that not every
generic one is valid for every encoder.)
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Buffers are allocated inside some metadata types, so we must ensure
that the object is visible to the free function before a parse failure.
Found by libFuzzer.
Broken in 6e225123d8, because
ff_copy_bits() expects the amount of bits, not bytes to write.
And because it relies on the buffer to be padded, using
side_data->size * 8 is not possible. So partially revert
said commit.
Fixes ticket #11591.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the studio profile uses chroma_inter/intra matrices;
the ordinary profile has only inter/intra matrices.
And our code (namely the MPEG-2 unquantize functions)
only use these two matrices (the MPEG-2 decoder unquantizes
on its own while parsing).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is only one source of dirty MpegEncContexts:
update_mpvctx() (which copies an MpegEncContext
over another one in order to initialize it). So only clear
these contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the destination MpegEncContext in ff_mpeg_update_thread_context()
is not initialized, the source MpegEncContext is simply copied
over it before (potentially) calling ff_mpv_common_init().
This leads to data races when this code is executed which is why
it should be replaced with only copying the necessary fields
(this is for future commits).
Given that the RV30 and RV40 decoders always call said function
with an already initialized MpegEncContext (they use context_reinit
in case of frame size changes), they don't need this ugly
initialization (and are therefore race-free). This means that
this code can be moved to the only decoder that actually needs it:
MPEG-4. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The spec indeed does not allow the aspect ratio to change
within a video sequence, but this does not imply that we
must reinitialize the decoder if only the aspect ratio changes,
as this value does not affect the decoding process at all.
Moreover, our reinitialization is a bit buggy: If there is
frame reordering, then the not yet output next P-frame is
simply discarded upon reinit. With this patch this no longer
happens when only the aspect ratio changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1 decoder has an update_thread_context function set,
yet it was never enabled (missing AV_CODEC_CAP_FRAME_THREADS
flag). So remove it and also the ff_thread_finish_setup() call
as well as the progress reporting.
(Simply setting the flag would not be enough. The main problems
are:
a) The update_thread_context function relies on memcpy'ing
the whole context instead of only copying the necessary fields.
This leads to data races which is undefined behaviour.
(Btw: The check for whether the non-MpegEncContext fields
of Mpeg1Context should be copied has been broken in
7f0efe2324.)
b) Even an AVBufferRef* is simply copied, without creating a new
reference.
c) Copying the whole context happens only during init; when parameters
change lateron, the change is not propagated to the next thread.
This affects at least the quant matrix (for MPEG-1).
d) The MPEG-1/2 decoders are made to decode both MPEG-1 and MPEG-2.
When MPEG-2 is decoded, another complication arises: In case of
coded fields, both fields can be in one AVPacket or they can be
in separate AVPackets. One would need to parse enough of the data
to be able to determine whether the next thread needs to start
a new frame or decode the second field of the current frame;
for this one would need to either postpone calling
ff_thread_finish_setup() for coded slices altogether or implement
some form of ff_h2645_packet_split().
One would also need a second ThreadProgress to signal progress
of each field.
e) One would need to reenable waiting in ff_mpv_reconstruct_mb()
for MPEG-1/2 (and H.261).
f) Probably lots of other stuff for invalid input that I am currently
not thinking about.
If this were done, nothing from the current update_thread_context
would remain, so one can just nuke it altogether.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Call ff_mpeg_update_thread_context() first and
update the RV34 buffers if it indicates a reinitialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely of reinititialization performed by
ff_mpeg_update_thread_context(), so that they can simply
update their own dimension-based buffers accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the MPEG-4 decoder and the encoders.
Notice that this field is a per-frame property and therefore
does not need to by synced in mpeg4_update_thread_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely in ff_mpeg4_get_video_packet_prefix_length().
This will allow to move [fb]_code from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When switching to the XviD IDCT, the IDCT permutation can change.
Given that we already permute the quant matrices when parsing
them, they need to be permuted, too. Up until now this has not been
done; instead the header has been parsed again in the expectation
that the currently active quant matrix is contained in this header.
This expectation is wrong; it is for example wrong when the VOL
header is only available via extradata (such a file can be easily
created from xvid_vlc_trac7411.h263 (in the FATE suite) via the
remove_extra BSF). It could also be wrong if the XviD user data
is only available in a subsequent packet.
This commit therefore switches to permuting the relevant matrices
directly. It also stops parsing the header a second time
when switching to the XviD IDCT.
(I wonder whether ff_mpv_idct_init() should take alternate_scan
into account when initializing permutated_intra_h_scantable
as the decoder does. Does the MPEG-4 encoder use a wrong scantable
in this case?)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not change lateron.
(If we were to add short header support later, it would involve
a branch in mpeg4_decode_block() anyway and we would then
hardcode the dc_scaler value of eight there; the *_scale_tables
would stay the same.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We never set the ThreadFrame*, because mpegvideo uses
ThreadProgress instead of ThreadFrames. Furthermore,
it is unnecessary because the ERPicture has just been zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_xvid_idct_init() already checks in case of high_bit_depth,
lowres or an incompatible idct_algo.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The key benefits are:
- Different to other graph printing methods, this is outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Use the same output implementation as ffprobe, supporting multiple
formats
Signed-off-by: softworkz <softworkz@hotmail.com>
Compression requires zlib to be available, otherwise resources will
be included uncompressed - in either case via BIN2C.
It can also be disabled via
./configure --disable-resource-compression
Size figures:
graph.css 7752
graph.css.min 6655 (css is always minified)
graph.html 2153
No Compression
graph.css.c 40026
graph.css.o 9344 (6688)
graph.html.c 13016
graph.html.o 4848 (2186)
With Compression
graph.css.c 10206
graph.css.o 4368 (1718)
graph.html.c 5725
graph.html.o 3632 (971)
Numbers in brackets: .rodata size from 'size -Ax -d *.o'
Signed-off-by: softworkz <softworkz@hotmail.com>
Also change writer_printf signature in AVTextWriter to use va_list,
so that it can be called by the new function writer_printf()
in tf_internal.h.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
This allows future addition of options without
changes to the signature of avtext_context_open().
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Instead of initializing a new BPrint in case of UTF decode error,
re-use the same BPrint struct and just clear it
for each iteration.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Fixes: signed integer overflow: -293650 * 16525 cannot be represented in type 'int'
Fixes: 408304111/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4762210299871232
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1384566925600903168 * 16 cannot be represented in type 'long'
Fixes: 407069502/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-5159255372267520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 402587670/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-6343867775647744
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The encoder uses max 128 taps, which is quiet a lot already
If work is done to improve sonic, it will be more radical than changing the taps
Fixes: Timeout
Fixes: 402539974/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-6122944271286272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is based on discussion with the GA and its simply the people
who have done or tried to do some uploads recently.
Everyone who has a shell account on ffmpeg.org should have powers to
upload samples.
CC: compn <compn@ffmpeg.org>
CC: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now if avcodec_send_packet() returned an error,
no attempt to receive a frame from the decoder would be made.
Instead the decoder was presumed to be drained, so that more
packets could be sent to it. Yet this need not be so:
It can happen that a packet would decode to multiple frames
and that decoding the first of these (the one that is decoded
during the avcodec_send_packet() call) returns an error,
in which case the decoder is not yet ready to receive more
input as the remaining parts of the packet have not been decoded
yet. In this case, an AERROR_BUG is triggered.
This happens in ticket #11553 with VP9 (which uses a BSF
to split VP9 superframes and is therefore affected by this).
Fix this by always calling avcodec_receive_frame() unless
xerror is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AV1DemuxContext.temporal_unit_size is zero after reading the header,
so the position set when reading the header will not be used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We may write up to 43 bits, so 5 bytes is not enough.
Fixes: Assertion n>=0 && n<=32 failed at ./libavcodec/get_bits.h:406
Fixes: 398527871/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6602025714647040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part_weighted.
If the buffer stride is 32 or 64 (as on x86 platforms),
the U and V pixels can be interleaved row by row without
overlapping, resulting in correct output.
However, on ARM platforms where the stride is 16,
the V component did overwrite part of the U component's pixels,
leading to incorrect predicted pixels.
The bug can be reproduced by the following bitstream.
https://trac.ffmpeg.org/attachment/ticket/11357/inter_weighted_bipred2.264
Fixes: ticket 11357
Commit-msg-mostly-by: Bin Peng <pengbin@visionular.com>
Reviewed-by: Bin Peng <pengbin@visionular.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This differs from libvorbis by
stddev: 2.44 PSNR: 88.58 MAXDIFF: 41 bytes: 834304/ 834304
for the file from the ticket
Fixes: Ticket11427
Regression since: dc89cf804a
This is a similar solution to what james proposed earlier in
[FFmpeg-devel] [PATCH] avcodec/vorbisdec: don't abort on EOD when decoding residuals
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current vvc_probe function checks for SPS, PPS, and IRAP NAL units but does not enforce their detection order. This can lead to false positives when PPS or IRAP appear before SPS, causing malformed or non-compliant bitstreams to be incorrectly identified as valid VVC streams.
This commit modifies the logic to use boolean flags and enforces the correct detection sequence: SPS must be detected before PPS, and PPS before IRAP. This ensures more accurate probing and prevents invalid bitstreams from being misidentified.
For streams with wrong ordering a lower score is returned
This change addresses issues reported in:
- https://trac.ffmpeg.org/ticket/11496
- https://trac.ffmpeg.org/ticket/11087
Signed-off-by: xiongweixiao <xiongweixiaoxxw@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Elapsed time is much less important than the actual progress, and I am guessing
several ffmpeg CLI frontends use the existing status line for showing progress,
so putting a new field in the beginning is less optimal anyway.
Related to ticket #11582.
Signed-off-by: Marton Balint <cus@passwd.hu>
Codec probing was primarily added to the wav demuxer to support DTS-in-wav
files, but DTS probing functions return AVPROBE_SCORE_EXTENSION+1, so we can be
a bit more strict with the required score.
This fixes MP3 misdetections for some wav files.
Fixes ticket #11581.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: shift exponent 49 is too large for 32-bit type 'int'
Fixes: 398060145/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5023082406543360
Reviewed-by: James Almer <jamrial@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read in decode_cu_16x16()
Fixes: 398049430/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5525836849807360
Reviewed-by: Peter Ross <pross@xvid.org>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by 0
Fixes: 395163171/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-542604339373670
Reviewed-by: Peter Ross <pross@xvid.org>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 391935573/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MMVIDEO_fuzzer-4655048979709952
Fixes: out of array access
Reviewed-by: Peter Ross <pross@xvid.org>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Videos of "StarWars - Making Magic" consist of 640x480 codec3 frames
which establish a background, and a 320x240 codec48 video put on top
at random left/top offsets.
To support this, a new default buffer "fbuf", which holds the final
image to be presented, is added, since codec37/47/48 need their 2/3 buffers
to be private to themselves. The decoded result is then copied to the fbuf,
honoring the left/top offsets if required.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Change the size detection a bit to recognize common video sizes,
as the FOBJ codecs>=37 cannot always be trusted, since they can
be embedded in a larger frame.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some videos of "StarWars - Making Magic" have this subcompression
type: data just consists of the 16 byte codec48 header; the DOS player
and the c48 decoder in the "Mysteries of the Sith" game engine ignore it.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
liboapv will seemingly encode correct 4:4:4 output, but report profile_idc 33, which
is specifically the profile value for 4:2:2 10bit.
Signed-off-by: James Almer <jamrial@gmail.com>
In the call to vkGetPhysicalDeviceImageFormatProperties2(), we were
previously requesting the properties of the first fallback format (e.g.
VK_FORMAT_R8_UNORM for VK_FORMAT_G8_B8R8_2PLANE_420_UNORM) instead of
the actual format in use.
We don’t do anything with it afterwards, but there is no reason to keep
querying the wrong format.
Fix chroma_location being cleared by setrange and setfield filters.
This was forgotten in 201f1cba15.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
It was possible for the buffer pointers for the last tile to go over the
end of the unit buffer leading to a read overflow during decode of the
macroblock layer. Check all tile component sizes to prevent this case
and also catch related tile size mismatch errors earlier.
Halt tile component decoding at the first entropy error (this will be a
desync and is not recoverable). If any tile components contain errors
then discard the frame unless the output-corrupt flag is set.
Also fixes CID 1646764, which is the error case where the tile component
is too large for get_bits to handle.
No reason to build the exact same table once per decoding thread.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Abort as soon as we're done reading the slice header instead of running extra checks
that assume slice data may follow.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents printing bogus errors about the value being 0, when in fact we
overread the available slice buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Since GCC 10 and llvm.org Clang 11, -fno-common is the default.
However Apple's Xcode Clang hasn't followed suit yet, and still
defaults to -fcommon.
Compiling with -fcommon causes uninitialized global variables to
be treated as "common" (which allows multiple object files to have
similar definitions).
Common variables seem to have the issue that their intended alignment
isn't signaled, so the linker assumes that they may need alignment
according to their full size.
With large global tables, this can lead to linker warnings like
this, with Xcode 16.3:
ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
This can be reproduced with a small snippet like this:
char table[16385];
int main(int argc, char* argv[]) { return 0; }
Compiling with -fno-common avoids this issue and warning, and
matches the default behaviour of other compilers. (Compiling with
-fno-common also avoids the risk of accidentally accepting
duplicate definitions of global variables, as long as they are
uninitialized.)
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows the user to set only the one that is needed to ALL or a
specific "wrong" extension like html
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
An identical call exists in ffmpeg.c
With POSIX/glibc, stderr is already unbuffered (or line-buffered when
a terminal is connected), but not in case of MSVCRT.
Explicitly calling setvbuf() like in this commit, makes the Windows
runtime behave like POSIX, giving the same “print immediately” behavior.
Signed-off-by: softworkz <softworkz@hotmail.com>
When viewing logs, there are situations where it is not entirely
clear whether ffmpeg CLI has exited gracefully. The two primary cases
are
- A crash/segfault has occured
Windows for example doesn't output any message to the calling shell
- The process has been terminated (e.g. killed externally)
Printing a message on exit provides a reliable indication that the
process has exited normally.
Printing the exit code is useful as it usually remains invisible
and unnoticed by users running FFmpeg from a shell.
Signed-off-by: softworkz <softworkz@hotmail.com>
Commit c8140fe732 had introduced
a check for value_len > UINT16_MAX.
As a consequence, attached images of sizes larger than UINT16_MAX
could no longer be read.
This is a minimal fix of the regression, avoiding the controversies
of my earlier submission regarding int type handling in asfdec.
Signed-off-by: softworkz <softworkz@hotmail.com>
- Change precision to 6 digits to align with other printed times
- Change label to just "Start"
- Add 's' unit to format 'start' value for consistency
Signed-off-by: softworkz <softworkz@hotmail.com>
This is a raw demuxer, it should not read codec level information and export it
as container level information.
The generic demux code will use the recently introduced parser to take care of
that.
Signed-off-by: James Almer <jamrial@gmail.com>
This demuxers reads encapsulation bytes before reading codec data into the
output packets, so take such offset into consideration.
Signed-off-by: James Almer <jamrial@gmail.com>
The output will be a fragment with zero units, which is a lot more user friendly
than making them think something went wrong, as it already happens with cbs_av1.
Signed-off-by: James Almer <jamrial@gmail.com>
Bitstream generated using the reference encoder, then edited to fix the
colour description and an extra metadata block added. FFmpeg decoder
output is identical to the reference decoder output.
The content used is the first three frames of "Waterfall" from the SVT
Open Content Video Test Suite 2022. This is copyright Sveriges
Television AB and is used under the Creative Commons Attribution 4.0
International License.
The init-cleanup flag makes no sense for a demuxer without
a read_close() function.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
pkt->pos pointed to the actual packet data, not to the start
of the access unit.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The signature check would segfault in case the packet could not
be allocated or if nothing could be read.
Furthermore, read_packet callbacks are supposed to return zero
on success, yet the current code returned the size of the packet.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes potential use of uninitialized data.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some loop counters were initialized incorrectly.
This patch enhances the handling of loop iterations and residual parts.
Reviewed-by: 陈昊 <chenhao@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This can happen for HLS with AES-128 at the middle of m3u8, so old
protocol is https while new protocol is crypt+https.
And change the log level from ERROR to INFO when protocol/host/port
don't match. User should prepared for this function to fail and
retry with new connection.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This bsf converts AV_PKT_DATA_NEW_EXTRADATA side data in avcc format
to in-band annexb format. However, the side data wasn't been removed
and copied from input packet to output packet. So the output packet
has mixed bitstream format. We don't support mixed bitstream format.
For example, h264_metadata report error in the following case:
ffmpeg -i foo.flv \
-bsf:v "h264_mp4toannexb,h264_metadata" \
-c copy -f null
This patch removed NEW_EXTRADATA side data after process.
This patch also add a check so only NEW_EXTRADATA in avcc format is
processed. NEW_EXTRADATA in annexb format is copied to output as is.
Reported-by: jiangjie <jiangjie618@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ff_thread_get_buffer() already emits its own logmessage.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: warning: using floating point absolute value function 'fabs' when argument is of integer type
No change in output
Changing variables to float worsens compression significantly
Found-by: ePirat
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The earlier code would traverse over the code lengths
mutliple times (namely max_length + 1 times - once to get
the maximum length and once for each max_length to assign
codes) before calling ff_vlc_init_sparse() (which may traverse
them twice and sort them). The new code only traverses them once
(+ the one time in ff_vlc_init_from_lengths()).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't rely on invalid codes leading to get_vlc2() returning
-1, which then gets converted to an uint8_t, i.e. to 255
and runs afoul of a length check later. After all, get_vlc2()
could be changed to return something else which may
be valid when cast to uint8_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is better when BUF_BITS == 64 (i.e. on x64), because
the underlying put_bits can then handle 0..63 bits naturally.
It does not worsen the code when BUF_BITS != 64, because
the compiler can optimize this to the same code as now
(due to the assert).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that these trees have only nine elements and are complete,
their depth is <= eight.
Also remove the now unused FF_HUFFMAN_BITS constant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The VLC trees used here have very few different codes
and are therefore guaranteed to not be very deep: The AC/DC
VLCs have 12 elements and therefore a depth <= 11 whereas
the run VLCs have only nine elements and therefore a depth <= 8.
This allows to reduce the worst-case number of reloads for
reading a VLC code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are only 2*3*4 VLC trees for decoding Huffman encoded
AC coefficients; see section 13.3.2 of the spec.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will bring these bugs to our attention.
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Return AVERROR_DECODER_NOT_FOUND.
(This can be triggered because this decoder tries to be
generic and work with multiple underlying AAC decoders,
so that there is no configure dependency for any decoder.)
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is simpler and allows to fuzz them -- up until now,
the linker did not see the dependency and fuzzing them
returned AVERROR_BUG during init.
It took just a few seconds here to run into an assert
due to a return value of AVERROR(EAGAIN) in the decode
callback...
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_mjpeg_decoder is now referenced directly by the relevant
decoders, so that the linker sees the dependency and
just does the desired thing. So remove the hack.
(Btw: The preprocessor does not do string comparisons, instead
undefined tokens in #if checks evaluate to 0, making the check
true regardless of the actual codec fuzzed (and leading to
linker errors if the mjpeg decoder is disabled).)
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is simpler than calling avcodec_find_decoder().
Notice that av_codec_init_static() has already been called
by the time we reach these decoders' init functions,
so it is not necessary to call avcodec_find_decoder()
for it (which doesn't do anything for the mjpeg decoder
anyway).
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
According to RFC 6416 the audio stream sender can pass the data rate
for the audio bitstream as "bitrate=" media format parameter.
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Right now it is possible for the pointer for the current frame to
be set in the context even when it could not be properly set up;
this does not influence the ordinary ref frames, but only
VP8Context.prev_frame. And since this code has been ported to the
ProgressFrame API in d48d7bc434,
this leads to segfaults, because the ProgressFrame API is less
forgiving than the ThreadFrame API (waiting on an uninitialized
ProgressFrame segfaults, waiting on an uninitialized ThreadFrame
is a no-op (the code behaves as if frame-threading is not in use)).
Fix this by maintaining the consistency of the frame pointers
in the context (by setting them later).
Fixes: NULL pointer dereference
Fixes: 68192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP8_fuzzer-6180311026171904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids a potential overflow when multiplying nb_colors by 6.
Also make the nb_colors check a bit more strict.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is written as region_id which is a single byte.
Also fixes a potential (defined) overflow in the num_rects * 6
multiplication later; this has been found by 김승호 <kimsho98@naver.com>.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have already calculated the size of the packet
and therefore don't need to rely on these implicit checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be easily done because we have a count of the number of
values and the length of the associated codes. This allows
to switch to ff_get_encode_buffer() and thereby avoids an implicit
intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that we can calculate the size of each slice in advance,
we can determine the position in the output packet where it
needs to be put and can therefore avoid the intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code only used the counts from the last slice.
The two FATE tests using slices show compression improvements
due to this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Every frame contains an array of uint8_t with values
0..(s->planes * s->nb_slices - 1), so this needs to fit
into an uint8_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do not derive it via av_cpu_count() in case AVCodecContext.slices
is unset. Instead default to AVCodecContext.thread_num instead
(which is one in case frame-threading is used and gives the actual
number of slice threads for slice threading).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Vulkan's main issue around using BGR is simple.
The letters in the shader don't match up (rgba in shader, bgra in format).
So of course, rather than allowing "bgra" or other permutations of
formats in the shader, they went the nuclear option and spent months writing
an extension to get rid of the need to have a format in the shader to begin
with.
All this to solve a problem that should never have existed to begin with.
This fixes BGRA images since enabling WithoutFormat, as the GPU now remaps
without your involvement.
Seeing the offset of video and audio streams to each other is often
a useful metric in diagnosing and understanding issues with playback
or transcoding.
This commit adds those offsets to the stream info print.
Signed-off-by: softworkz <softworkz@hotmail.com>
The previous code expected a segment of type CLUT definition to exist
in order to accept a set of segments to be complete.
This was an incorrect assumption as the presence of a CLUT segment
is not mandatory.
(version 1.6.1 of the spec is probably a bit more clear about this
than earlier versions: https://www.etsi.org/deliver/etsi_en/
300700_300799/300743/01.06.01_20/en_300743v010601a.pdf)
The incorrect condition prevented proper fallback to using the default
resolution for the decoding context.
This also adds variables and moves the fallback check to the outside
for better clarity.
Signed-off-by: softworkz <softworkz@hotmail.com>
This add support for WebVTT subtitles in HLS streams.
Just like for separate audio streams, it supports all available
WebVTT streams in all renditions.
No new options are added, it just works and provides subtitles streams
like any other demuxer.
The code prevents downloading subtitle segments which are farther
in the future than the main segments, to avoid loading hundreds
of subtitle segments in advance.
Signed-off-by: softworkz <softworkz@hotmail.com>
In filtering, and SDR encoding, we use storage images.
This fixes using Vulkan filters on Intel.
Tested not to break anything on the three major vendors.
This implements support for reading and writing storage images with
no format.
The issue is that we define our images as arrays, and arrays can
only have a single type, which means that f.ex. NV12 needs two
different images, R8 and RG8.
The only driver known not to advertise support for the extension
as a whole is Intel, because they have parial support for odd formats
we never use. Therefore, just always enable it by default.
It is unnecessary, as we already have the entries sorted by
probability and therefore implicitly by length. All we need
on top of that to build the tree is the number of entries
of a given length.
Doing so gives a 3.6% speedup of ff_mjpeg_encode_huffman_close()
here; it also saves about 640B of .text here.
The new code puts values with higher probability to the left
of the tree. The old code did not and therefore
the FATE checksums needed to be updated. Due to MJPEG's
0xFF unescaping file sizes as well as file checksums
needed to be updated; the decoded picture hashes stayed
the same. Given that codes on the left of the tree have
on average fewer bits set than codes on the right, the
file sizes mostly improve (all except vsynth3-mjpeg-444).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We violated the spec, which, despite the actual command buffer pool
*not* being involved in any functions which require external synchronization
of the pool, *require* external synchronization even if only the
command buffers are used.
This also has the effect of *significantly* speeding up execution
in case command buffers are contended.
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
see: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance
but in short, first our API since 16years says we dont have multiple values per key
(which it supports since 9 years only)
and it causes some problems for ffprobe apparently.
I do believe the original patch is the correct direction but it requires
more changes. So revert this until other things are in place and until
we have a consensus.
This reverts commit 80b77e8e8d.
fix ticket #11531
the rtsp aac did not marked keyframe which cannot easy copy to output.
because f265f9c9d0 commit change the AAC props to match xHE-AAC.
in some formats like MOV, need_parsing is set, so AAC can be still parsed be keyframe
but rtsp did not, so this patch add it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current behavior when using restart_with_keyframe is that it will
recover if it also encounters any audio packet, as they are flagged as a
keyframe.
The expectation is that packets are dropped until the next _video_
keyframe.
To fix that, check if exists a video stream, if it exists check the
packet stream codec type, only letting it recover when it is a video
one. If there is no video stream, resume to the original behavior, not
checking the codec type.
Fixes ticket: #11467
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
GNU apparently deprecated their egrep alias, replace it with 'grep -E'
to avoid getting flooded with deprecation warnings.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Just like normal close functions.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avtext_context_close() calls av_opt_free() on an AVTextFormatContext
as well as av_bprint_finalize() on the containing section_pbuf
AvBPrints, yet it can happen that the AVBPrints have not been
initialized (only zeroed) and that av_opt_set_defaults() has
not been called. This works, but it is not really documented to do so.
So ensure that the options and the AVBPrints have been initialized
when avtext_context_close() is called.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Would happen if an AVTextFormatContext's private context
could not be allocated.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avtextwriter_create_file() creates an AVIOContext whose pointer
resides in its private context. If it were not always closed on
uninit, the AVIOContext would leak, so it makes no sense
to have this parameter.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This AVTextWriter does not have any options.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use snprintf() directly instead of initializing an AVBPrint
just for this.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All users (namely HEVC) that use ff_progress_frame_alloc()
should just use ff_thread_get_buffer(). Using
ff_progress_frame_get_buffer() is not a must; it is merely
a convenience wrapper.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds support for compiler hints.
While on AMD these are not used/needed, Nvidia benefits from them, and gives
a sizeable 10% speedup on 4k.
This commit also makes it possible for the encoder to choose a different
quantization table on a per-slice basis, as well as adding this capability
to the decoder.
Also, this commit fully fixes decoding of context=1 encoded files.
This reduces the intermediate VRAM used for RGB decoding by a
factor of 100x for 6k video.
This also speeds the decoder up by 16% for 4k RGB24 and 31% for 6k video.
This is equivalent to what the software decoder does, but with less pointers.
We know the final size before encoding, so we can switch to
ff_get_encode_buffer() which avoids an implicit memcpy().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most of the encoders is the same. So deduplicate them.
This reduces code size from 22410B to 12637B here.
The data in mpegaudiotab.h is also automatically deduplicated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample rates here have already been checked generically
via CODEC_SAMPLERATES().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample rates have already been checked generically
via AVCodec.supported_samplerates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to avoid the codes table; furthermore, given
that the runs fit into seven bits and level into nine,
one can put them into one int16_t and use as symbols table
in ff_vlc_init_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Initialize a list of 128 pointers at decoder init
instead of using a const list of pointers (which
will be initialized at runtime when libavcodec
is loaded when using pic code with Elf); the former
takes only 128 bytes (+ a bit of initialization code),
the latter 1KiB on 64 bit systems (+3KiB on x64 elf
for relocation information).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, hq_decode_block() zeroed every block (of 128 bytes)
before decoding a block; yet this is suboptimal for all modes,
because all modes need to reset all the blocks they use anyway
and so it should be done in one go for all blocks.
For the alpha mode (where blocks need not be coded) all blocks
are zeroed initially anyway, because decode_block() might not
be doing it, so zeroing there again for the coded blocks is
a waste.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This table is so small (32 elements amounting to 128 bytes)
that it is more efficient size-wise to hardcode it instead
of initializing it at runtime.
Also stop duplicating it in hq_hqa.o and hqx.o.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avcodec_free_context() only calls ff_codec_close() if there
is an AVCodecContext and avcodec_open2() unconditionally
dereferences the AVCodecContext*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also document the constant.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ASV-1/2 does not really have a header and so using
FF_INPUT_BUFFER_MIN_SIZE is wasteful as well as ugly
(such bounds should be codec-specific).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Parse format can be called multiple times, e.g., when resolution
changed. If getInt32 fails, optional member variables will retain
their previously set values without modification. This can be a
big problem for new resolution with old crop info.
This patch reset optional fields to zero when getInt32 failed.
The rounds value is constant and can be one of three hardcoded values, so
instead of checking it on every loop, just split the function into three
different implementations for each value.
Before:
aes_decrypt_128_aesni: 93.8 (47.58x)
aes_decrypt_192_aesni: 106.9 (49.30x)
aes_decrypt_256_aesni: 109.8 (56.50x)
aes_encrypt_128_aesni: 93.2 (47.70x)
aes_encrypt_192_aesni: 111.1 (48.36x)
aes_encrypt_256_aesni: 113.6 (56.27x)
After:
aes_decrypt_128_aesni: 71.5 (63.31x)
aes_decrypt_192_aesni: 96.8 (55.64x)
aes_decrypt_256_aesni: 106.1 (58.51x)
aes_encrypt_128_aesni: 81.3 (55.92x)
aes_encrypt_192_aesni: 91.2 (59.78x)
aes_encrypt_256_aesni: 109.0 (58.26x)
Signed-off-by: James Almer <jamrial@gmail.com>
This allows catching whether the functions write outside of
the designated rectangle, and if run with "checkasm -v", it also
prints out on which side of the rectangle the overwrite was.
Signed-off-by: Martin Storsjö <martin@martin.st>
this is a good compromise between speed and compression
-rw-r----- 1 michael michael 180987 Feb 6 14:29 lena-def.png
-rw-r----- 1 michael michael 128430 Feb 6 14:36 lena-pavg.png
-rw-r----- 1 michael michael 126269 Feb 6 14:36 lena-pmixed.png
-rw-r----- 1 michael michael 180987 Feb 6 14:35 lena-pnone.png
-rw-r----- 1 michael michael 127758 Feb 6 14:35 lena-ppaeth.png
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 390646659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-5040277374435328
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: division by zero
Fixes: 391981061/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6691017763389440
Fixes: 392929028/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5142088307507200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1966895953 + 210305024 cannot be represented in type 'int'
Fixes: 391921975/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5916798905548800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since 45eeb1f785
optimal Huffman tables are the default (without slice-threading).
This made the fate-vsynth*-mjpeg-{trell-,}-huffman tests
identical to their corresponding tests without "-huffman".
This is of course wasteful, so switch the two tests with
"-huffman" counterparts back to the default tables.
Also use one of these tests to test slice threaded encoding.
It has so far been untested.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that there are actually ASM functions of this type,
one can't simply remove the ff_ prefix from the definitions
and declare them as static. Yet one can do nearly that
if one keeps the ff_ prefix and removes the declarations
for the (now static) functions defined in dsp_init.c
from hevcdsp.h and if one defines the functions in the correct
order (smaller width first) so that no forward declarations
are necessary (which was already true).
The new declarations avoid nested macros to simplify things.
It nevertheless turned out to be beneficial line-wise.
(It would be possible to avoid most of these declarations:
It is legal to repeat a function declaration without static
if the first declaration declared a function as static.
So if the macros simply declared all the functions that
they call, one could avoid declarations for the functions
that are called. While this is legal C, it unfortuntaly
clashes with GCC's -Wredundant-decls (which configure enables)
and it is also ugly, as these macro definitions would
provide declarations used in ff_hevc_dsp_init_x86().)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This C90 rule forces us to use a too big scope and should
therefore be dropped. Given that we already require C11,
all supported compilers can handle mixed declarations
and statements just fine.
Reviewed-by: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both GCC and Clang use unsigned as underlying type of
an enum with no negative enumeration constants, making
checks like "layout->order >= 0" here tautologically true.
Clang warns about this. Combine both range checks
by casting to unsigned to suppress this warning.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This also means that if a plane*slice has only 1 color nothing
is stored after the remap table
This also corrects the RCT offset to the exact value after remap
not a fixed 65536
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes https://trac.ffmpeg.org/ticket/6949
Ordinary text frames in ID3v2 are allowed to have multiple
(null-separated) values. This technically isn't allowed in TXXX,
but it's used in practice by Picard, and supporting it is harmless.
TIPL/IPL (Involved People List) and TMCL (Musician Credits List) work
similarly to TXXX, but alternate key-value-key-value.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is useful when multiple metadata inputs may set the same value
(e.g. both a container-specific header and an ID3 tag).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Process data in chunks of four or eight bytes, depending on host, instead of
one at a time.
before:
55561 decicycles in av_aes_ctr_crypt
after:
52204 decicycles in av_aes_ctr_crypt
Signed-off-by: James Almer <jamrial@gmail.com>
The test in its current form is just ensuring the plain text output is the same
as the plain text input, not bothering to check if anything was done with the
latter. av_aes_ctr_crypt() could be a simple memcpy under the hood and this
test would still succeed.
To check the integrity of the encrypted buffer, both the IV and the key need to
be fixed. As such, and in order to not remove the existing randomization of the
input IV, do two runs, one with random initialization data, and one with static
data.
Signed-off-by: James Almer <jamrial@gmail.com>
The Reference-Only feature in DirectX 12 is a memory optimization
technique designed for video decoding scenarios.
This feature requires that reference resources must be allocated with
the D3D12_RESOURCE_FLAG_VIDEO_DECODE_REFERENCE_ONLY resource flag.
Reference textures must also be separated from output textures.
This feature is not supported in the current version of ffmpeg.
Since AMD GPU uses this feature in Direct 12 decoder,
ffmpeg does not support AMD GPU Direct 12 decoding.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
This reduces needed memory and also removes the 65536 maximum for remap
on the decoder side
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
That is instead of a fixed 65536, we now allocate only as many as there
are pixels.
We also allocate only for the encoder and only when remapping is enabled
and only for 32bit per sample
This should reduce memory consumption, the 2nd array will be
dealt with in a future commit
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
BSF can update extradata, e.g., vvc_mp4toannexb. If we don't copy
bsf->par_out back to avcodec context, decoder can get extradata in
mp4 format, while packets are in annexb format.
This class is unavailable on tvOS before 17.0 (and macOS before 10.7
and iOS before 4.0, but those are fairly ancient). This makes sure
that we don't try to build the avfoundation indevice for such
OSes.
Signed-off-by: Martin Storsjö <martin@martin.st>
E.g. tvOS doesn't have devicesWithMediaType.
In principle, we could probably disable building the whole
input device on such OSes, but that would either require
testing explicitly for the OS type in configure (which we don't
do anywhere so far), or test for individual objective C methods.
This approach allows the code to compile, but no input devices
will be found at runtime.
Signed-off-by: Martin Storsjö <martin@martin.st>
While technically not specifiad as valid by the AVFilterLink documentation,
it is currently possible to get an FPS of zero from various sources inside
libavfilter (notably vf_buffersrc).
Avoid a division by zero and resulting infinity when this happens.
Fixed warning about OBU count being wrong, which can only be
determined when the number of OBUs in the header is non-zero,
not the other way round.
Signed-off-by: Chris Hodges <chris.hodges@axis.com>
They are not needed for shared builds (and because --gc-sections
is not the default for shared builds, they were included by default
included in libavutil since bf22c4cc3e).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mpegvideodec.h includes mpegvideodata.h which in turn contains
a "static const uint8_t *const ff_mpeg1_dc_scale_table =
ff_mpeg12_dc_scale_table[0]"; yet if mpegvideo is disabled,
ff_mpeg12_dc_scale_table is not available, yet a non-optimizing
compiler (like GCC with -O0) may emit ff_mpeg1_dc_scale_table
and therefore a reference to ff_mpeg12_dc_scale_table nevertheless.
Fix this by only including mpegvideodec.h if it is needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ff_h2656_put_{uni_,}8tap_hv{32,64,128}_8_avx2
and ff_h2656_put_{uni_,}4tap_hv{64,128}_8_avx2
functions were unused and have been removed.
This saved 3712B of .text here.
(ff_h2656_put_{uni_,}4tap_hv32_8_avx2 are now only
called from exactly one callsite (in
ff_hevc_put_{uni_,}epel_hv32_8_avx2) and could be inlined.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The line which appears to be using it was always commented out
(since it has been added in 70c5ae870b).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It can't really happen, because no currently used pixel format
has a name exceeding the size of the buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
big secret, reading a float as the corresponding integer is a good
approximation of log2() for numbers not too close to 1.0. At the same
time it maintains strict monotonicity
this reduces run time from 19sec to 17sec for the slowest of my testcases
(with default remap_optimizer 3)
Compression is about the same:
-rw-r----- 1 michael michael 497603370 Mar 30 15:23 float-303503-fixed-40-optim-3-1log2F.nut
-rw-r----- 1 michael michael 497603374 Mar 28 11:27 float-303503-fixed-40-optim-3b.nut
-rw-r----- 1 michael michael 549938852 Mar 28 11:27 float-303503-float16-40-optim-3b.nut
-rw-r----- 1 michael michael 549938857 Mar 30 15:23 float-303503-float16-40-optim-3-1log2F.nut
-rw-r----- 1 michael michael 1150827841 Mar 28 11:28 float-303503-float-40-optim-3b.nut
-rw-r----- 1 michael michael 1150832913 Mar 30 15:22 float-303503-float-40-optim-3ref-log2F2.nut
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When running 'ffmpeg -init_hw_device list' to display available hardware
devices, it incorrectly shows an error message:
"Failed to set value 'list' for option 'init_hw_device': Immediate exit requested"
This is a regression introduced by commit a50f90f1c2. The command is
actually working as intended - it should exit after listing devices, but
shouldn't display an error message.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add videotoolbox to the list of supported hardware acceleration methods
in the -hwaccel option documentation. This option allows users to utilize
Apple's VideoToolbox framework for hardware-accelerated video decoding
on macOS and iOS devices.
The videotoolbox acceleration has been supported for a while, but was
missing from the documentation.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This data is only used by sbcdsp.c, so delete sbcdsp_data.h,
make a header out of sbcdsp_data.c and make the data contained
therein static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is simpler, avoids several loops and also makes GCC no longer
emit bogus -Wstringop-overflow= warnings.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Doing so gets rid of a stupid GCC -Wstringop-overflow= warning
(GCC somehow believes that fbw_channels can be 7 with the old
form of the code, so that channel_uses_spx[7] would be written
to, but now it no longer believes so).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
GCC considers declarations using a parameter of pointer
type (or equivalently a parameter using an array of unspecified
dimensions) to be inconsistent with a declaration using
a known-length array type and emits a -Warray-parameter warning
for several ff_j_rev_dct* functions for this.
This patch makes the declarations match the actual definitions
to suppress these (IMO nonsensical) warnings.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Previously, AV1 used filler data with CBR by default while H.264
and HEVC may or may not depending on driver version. Make this
consistent by using not filler data in CBR mode for all codecs.
Since there are valid reasons to use CBR with or without filler,
also add a cbr_padding option to allow users to override this.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This backports similar functionality from dav1d, from commits
35d1d011fda4a92bcaf42d30ed137583b27d7f6d and
d130da9c315d5a1d3968d278bbee2238ad9051e7.
This allows detecting writes out of bounds, on all 4 sides of
the intended destination rectangle.
The bounds checking also can optionally allow small overwrites
(up to a specified alignment), while still checking for larger
overwrites past the intended allowed region.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it easier to implement custom error printouts in tests.
This is a port of dav1d's commit
13a7d78655f8747c2cd01e8a48d44dcc7f60a8e5 into ffmpeg's checkasm.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure to disable VideoToolbox if building with an SDK
that does contain VideoToolbox, but targeting an older version of
the OS where it is unavailable. Previously, we would enable
VideoToolbox as long as the framework itself was found, which only
require the framework to exist in the SDK.
Signed-off-by: Martin Storsjö <martin@martin.st>
The audiotoolbox outdev uses APIs that only are available on macOS,
not on iOS or tvOS. Check for them in configure, and make sure the
outdev is disabled otherwise.
This allows building for iOS without explicitly having to disable
the audiotoolbox outdev.
Signed-off-by: Martin Storsjö <martin@martin.st>
The conversion functions were added in
e7382b4d01, yet they were never
really enabled. Found via -ffunction-sections and --gc-sections.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This was changed 8 years ago with the introduction of the linux-perf path,
with seemingly no justification at the time. Likely a developer oversight
from testing.
This bug not only made --runs completely ineffective, but also meant that we
didn't actually correctly filter out outliers.
Fixes: e0d56f097f
Sometimes, the reference SSIM is significantly higher than the
SSIM level expected for the test. This is the case when the source format
has a much lower bit depth than the destination format. In this case, the fact
that legacy swscale does not accurately preserve the source dither pattern
gives it an unfair advantage in a direct comparison, leading to false
positives.
For example, conversion like rgb4 -> rgb565 should be lossless, but swscale
low passes / downscales the input chroma, throwing away massive amounts of
detail. This gives it a higher SSIM score since the lowpassed result removes
some of the dither noise that was present in the source.
We can calculate with some confidence the theoretical expected SSIM
from an "ideal" conversion, by computing the reference SSIM level
for an image dithered with uniformly distributed quatization noise.
This gives us an additional safety net to check for regressions even in
the absence of a reference to compare against.
And bias it towards Y. This is much better at ignoring errors due to differing
dither patterns, and rewards algorithms that lower luma noise at the cost of
higher chroma noise.
The (0.8, 0.1, 0.1) weights for YCbCr are taken from the paper:
"Understanding SSIM" by Jim Nilsson and Tomas Akenine-Möller
(https://arxiv.org/abs/2006.13846)
Instead of the lossy yuva420p. This does change the results compared to the
status quo, but is more reflective of the actual strength of a conversion,
since it will faithfully measure the round-trip error from subsampling and
upsampling.
I need this to be able to test the new unscaled conversion code more quickly.
We re-order the flags order to make 0 the first entry, so we don't set any
flags when performing unscaled tests.
Also fixes a -Wdeclaration-after-statement warning.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This increases the search space from the hardcoded 17 tables
to ~ 23^512 tables
The mul_count choice is chosen by bruteforce
All testcases tried, improve
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is currently not due to endianness. This forced to add
workarounds with sed in fate/mxf.mak (which are removed
in this commit).
This is supposed to fix the enhanced-flv-hevc-hdr10 test
on big endian systems.
Reviewed-by: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not all rtp formats require the video dimensions to be available
up front. H264 and HEVC will send them as stream parameters.
The flag is restrictive and prevents RTP repacketization
without parsing the codec information out of the stream.
This change checks to see if the codec parameters are available
on the rtp formats that need it.
Signed-off-by: Koushik Dutta <koushd@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes compilation in case where the FLV encoder is disabled
with any other H.263 based encoder enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Put it into SnowEncContext instead. Also use the proper type
(it is only used as IDWTELEM aka short).
(The allocation code allocated it in units of uint32_t,
yet it was never used in this way. I made the array so big
that the size (in bytes) does not change.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They have a fixed size and given that nowadays
MotionEstContext is no longer in any decoder's private context,
it is not wasteful to just put it into there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With this modification the test would have caught the regression
introduced in 72bf3d3c12.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_thread() puts two MPVEncContexts (2*6516B here)
on the stack and zeroes one of them in order to
temporarily store the variables that get changed
during encoding a macroblock (when there is more than
one candidate type for a macroblock). This is wasteful
and therefore this commit adds a small (328B here) structure
to store exactly the fields that actually need to be backed
up. Then one can extend MPVEncContext without fearing
too use up to much stack.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this instead of exporting raw_pix_fmt_tags
via avpriv_get_raw_pix_fmt_tags().
For shared builds this will lead to an increase in the
combined size of the lavc and fourcc2pixfmt binaries
(because the overhead of exporting avpriv_get_raw_pix_fmt_tags()
is dwarfed by the size of the array), but given that
fourcc2pixfmt is a test tool that is not widely distributed
it does not really matter. For static builds the opposite
is true (the rest of lavc/raw.o is no longer pulled into
the test tool and the getter can be removed, too).
This patch has the additional benefit of removing
struct PixelFormatTag from the ABI.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not worth the overhead of exporting it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This is possible without deprecation period, because said field
is documented as only for our libav* libraries and not the general
public.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
There is a special case I missed, its simpler to just store
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We need to allocate space for 64 coefficients per block;
24dbc4c2e8 wanted to
perform the calculation 64*sizeof(MJpegHuffmanCode)
at compile time, yet in the end did it in a way that
made it allocate 64 times as much memory as needed.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes a regression caused by my desire to use loop-scope
for iterators in 72bf3d3c12.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The kVTVideoDecoderReferenceMissingErr constant was only added
in the macOS 12 and iOS 15 SDKs. Use a hardcoded value instead
of the named constant, to fix building with older SDKs
after c6214b0d69.
Signed-off-by: Martin Storsjö <martin@martin.st>
For all encoders and all decoders except MPEG-4 the unquantize
functions to use don't change at all and therefore needn't be
kept in the context. So discard them after setting them;
for MPEG-4, the functions get assigned on a per-frame basis.
Decoders not using any unquantize functions (H.261, MPEG-1/2)
as well as decoders that only call ff_mpv_reconstruct_mb()
through error resilience (RV30/40, the VC-1 family) don't have
the remaining pointers set at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
block_last_index and nCoeffs is an optimization designed
to avoid processing unnecessarily many coefficients; yet
it would be legal to always process all coefficients
(all coefficients beyond nCoeffs are zero anyway and
zeros are always unquantized to zeros). Therefore
one does not need a scalar tail.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't do it depending upon dct_algo, as this is not supposed
to influence the unquantize function selection.
(This check originated in 05c4072b45
where it was used for the dct_quantize function only.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This affected the WMV1/2 encoders (but not when running FATE because
the encoding part uses the fastint dct, so this code isn't used
then anyway).
It did not affect anything else, because a) only WMV1/2 use different
scantables, b) ff_msmpeg4_decode_block() (and therefore the WMV1
decoder) already unquantize inter macroblocks as they are parsed
c) the WMV2 decoder does not use the unquantize functions for inter
macroblocks at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for only keeping the actually used
unquantize functions in MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use spell out what me_cmp_func means.
Avoids inclusions in the H.264 decoder as well as all
mpegvideo decoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only set them after mb_x and mb_y are known which happens
only after the call to ff_h261_reorder_mb_index().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reset them in ff_me_init_pic(). It is the appropriate place for it
and allows to remove resetting code from multiple places
(e.g. mpegvideo_enc.c resetted it in two different places
(one for the main slice context, one for all the others)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also avoid casts and parentheses.
(This is only possible now because ff_update_duplicate_context()
no longer touches the PutBitContext.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These pointers point to static tables which must not be modified
by anyone after they have been initialized. So constify the pointees.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens currently for the non-main slice contexts.
But these variables get reset at the start of encode_thread()
anyway for all slices, so this is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Many of the fields of MpegEncContext (which is also used by decoders)
are actually only used by encoders. Therefore this commit adds
a new encoder-only structure and moves all of the encoder-only
fields to it except for those which require more explicit
synchronisation between the main slice context and the other
slice contexts. This synchronisation is currently mainly provided
by ff_update_thread_context() which simply copies most of
the main slice context over the other slice contexts. Fields
which are moved to the new MPVEncContext no longer participate
in this (which is desired, because it is horrible and for the
fields b) below wasteful) which means that some fields can only
be moved when explicit synchronisation code is added in later commits.
More explicitly, this commit moves the following fields:
a) Fields not copied by ff_update_duplicate_context():
dct_error_sum and dct_count; the former does not need synchronisation,
the latter is synchronised in merge_context_after_encode().
b) Fields which do not change after initialisation (these fields
could also be put into MPVMainEncContext at the cost of
an indirection to access them): lambda_table, adaptive_quant,
{luma,chroma}_elim_threshold, new_pic, fdsp, mpvencdsp, pdsp,
{p,b_forw,b_back,b_bidir_forw,b_bidir_back,b_direct,b_field}_mv_table,
[pb]_field_select_table, mb_{type,var,mean}, mc_mb_var, {min,max}_qcoeff,
{inter,intra}_quant_bias, ac_esc_length, the *_vlc_length fields,
the q_{intra,inter,chroma_intra}_matrix{,16}, dct_offset, mb_info,
mjpeg_ctx, rtp_mode, rtp_payload_size, encode_mb, all function
pointers, mpv_flags, quantizer_noise_shaping,
frame_reconstruction_bitfield, error_rate and intra_penalty.
c) Fields which are already (re)set explicitly: The PutBitContexts
pb, tex_pb, pb2; dquant, skipdct, encoding_error, the statistics
fields {mv,i_tex,p_tex,misc,last}_bits and i_count; last_mv_dir,
esc_pos (reset when writing the header).
d) Fields which are only used by encoders not supporting slice
threading for which synchronisation doesn't matter: esc3_level_length
and the remaining mb_info fields.
e) coded_score: This field is only really used when FF_MPV_FLAG_CBP_RD
is set (which implies trellis) and even then it is only used for
non-intra blocks. For these blocks dct_quantize_trellis_c() either
sets coded_score[n] or returns a last_non_zero value of -1
in which case coded_score will be reset in encode_mb_internal().
Therefore no old values are ever used.
The MotionEstContext has not been moved yet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids relying on ff_update_duplicate_context() to copy
these fields to the slice contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely after the main slice context has already been initialized,
so that this initialized state is directly copied to the newly
created slice contexts without relying on it being copied
by ff_update_duplicate_context(). This is in preparation for further
commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_MPV_encode_init_x86() has been renamed to ff_dct_encode_init_x86()
in 6b33e91899 in FFmpeg; libav renamed
it to ff_mpv_encode_init_x86() in commit
6b33e91899. This hasn't been noticed
in c1df467d73 when merging.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
last_pict_type, last_non_b_pict_type and last_lambda_for
are only used by the encoder's main thread.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for adding a special slice context for
the encoders and moving all the encoder-specific fields to it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(Checking in the same way for intra_only is not straightforward,
because at least p_mv_table is written to even in intra_only
mode.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also allocate them jointly (thereby reducing the number of base
arrays considerably) and already set them on all slice contexts;
don't rely on ff_update_duplicate_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
dct_error_sum and me.map are allocated per slice-context
and therefore their allocation has not been moved to
mpegvideoenc.c in 0154fb43e3.
This commit changes this by allocating them jointly and
moving said allocations to mpegvideo_enc.c like the other
encoder-only buffers.
The buffers are suitably aligned to ensure that no false
sharing occurs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several fields are not used by any generic code and can therefore
be moved to more specialized contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Switch to using the length+symbol table combination that is
also used by the decoder and remove MVTable as well as
the old tables altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the decoder uses VLCs to determine whether
this is an escape element or an index in two separate tables
giving the x and y components of the motion vector.
Given that both these components fit into an int16_t and therefore
into a VLCElem's symbol one can simply use a symbol table
to avoid the latter lookups.
This necessitated to combine the two tables for x and y components.
While just at it, also switch to ff_vlc_init_tables_from_lengths().
This will allow to get rid of the code tables (about 4KiB) once
the encoder has been ported, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a pointer to const to allow the slice threads to inspect
values without modifying them; also make it a simple cast
for codecs that don't support slice threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It gets rid of a switch (with accompanying CONFIG_*_ENCODER checks);
for MJPEG, it even lets one perform the check for whether one is
really encoding or only recording the macroblock once during init.
Furthermore, the switch actually contained lots of dead code --
it is compiled three times (for different pixel formats: 420, 422, 444),
yet most encoders only support 420. The approach used here automatically
fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Will avoid forward declarations later.
While just at it, forward ff_mpv_encode_init() errors.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The header is always written by the main thread, so it is
not surprising that header_bits can be moved to MPVMainEncContext
as well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_slicethread_free() is one of our functions that takes
a pointer to a pointer and resets the pointer when done.
It is legal for such functions to be passed a pointer to a NULL
pointer, yet passing a NULL pointer would be insane and should
not be tolerated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is no longer necessary given that the MPEG-1 encoder
now adapts the size of the last slice to ensure that
no slice header has an invalid slice_start_code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The valid values for slice_start_code are 0x1..0xAF, which implies
that one can't start a slice with row nb > 174 (zero-based).
This problem can be encountered with files of sufficient height
(more than 2800 pixels) either by using the slice option or by
imposing an RTP payload limit.
Fix this by making the last slice start on the maximum allowed
slice row if necessary and divide the first 174 rows to the remaining
slices. This will impede parallelism both in the decoder and encoder,
but that is unavoidable.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Everything except setting the dc_scale_tables can be done
before calling ff_mpv_encode_init(); setting the dc_scale_tables
unfortunately still has to be performed via a (now inlined)
callback performed by ff_mpv_encode_init() as it relies
on intra_dc_precision having been sanitized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for merging ff_mpeg1_encode_init()
into the MPEG-1/2 encoder's init function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reuse the already computed value of macroblocks; use an array
instead of a switch, evaluate 64 * sizeof(MJpegHuffmanCode)
at compile-time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_speedhq_encode_init(). The opposite is more natural,
avoids a non-static function and allows to reuse e.g.
slice_context_count instead of duplicating the logic from
ff_mpv_common_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely use avctx directly instead of s->avctx. While just at it,
also move the switch to the other checks involving avctx.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_speedhq_encode_init(). The opposite is more natural
and avoids a non-static function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the H.263-based decoders as well as the encoders need it;
so move it to ff_h263_decode_init() as well as ff_mpv_encode_init().
Also for the latter make it only set these tables if none are
already set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_h261_encode_init(). The opposite is more natural
and avoids a non-static function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move b_frame_strategy and b_sensitivity and brd_scale;
they are all only used by an encoder's main thread when
b_frame_strategy == 2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for moving all the elements from
MpegEncContext that are only used by the main encoder thread
to MPVMainEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Core framework and AV1 only for now.
This will be useful in an upcoming commit, where CBS will be utilized by
a module outside libavcodec.
Signed-off-by: James Almer <jamrial@gmail.com>
This will be useful a following commit, where the offset of the Tile Group
inside a Frame OBU needs to be known.
Signed-off-by: James Almer <jamrial@gmail.com>
will move to specific areas once they are there.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reduces stack space requirements my 1.5 mb and should fix fate
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
not a bugfix as this path was only used for float16 but it makes sense
to allow using this for integers too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes failures in some systems since 171060d5dc.
This can be further improved by only allocating the arrays when needed.
Signed-off-by: James Almer <jamrial@gmail.com>
ATM this performs as well or better as any other algorithm tried.
Its simple for the decoder.
On the encoder side complexity depends on how parameters are
chosen. But with a fixed mul_count of 1 and basic heuristic
it performs as well as any more complex choice i tried so far.
The encoder code here is flexible and allows mul_count > 1
and also can easily be used to exactly test various parameters.
With mul_count=512 we can gain another 6% in remap table size
for fixed point in float data. (this is not implemented in this
patch though)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a replacement in ffmpeg for the deprecated avcodec flag AV_CODEC_FLAG_DROPCHANGED.
This option is meant to be used when the filtergraph should not be
reinited upon input parameter changes as that leads to loss of state
in the filtergraph potentially leading to broken or aborted output,
e.g. inserting of silence with first_pts specified in aresample.
Generally useful to avoid corrupted yet decodable packets in live
streaming inputs.
This option when enabled takes precedence over reinit_filters
The existing default value is the same as the primary readrate.
This maintains the flow rate as best as possible but does not
reduce the lag. This new value allows catchup to gradually happen
without overwhelming the receiver.
Addresses a concern brought up in #11469
Otherwise the decoder may enter an loop of repeated state resets.
This can happen for streams with CRA but no IDR.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It allows the callee to clobber the MMX state,
yet since 1e3dc705df this is no longer
done. So use the stricter declare_func instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds option for enabling SmartAccess Video (SAV)
in AMF encoders. SAV is an AMD hardware-specific feature which
enables the parallelization of encode and decode streams across
multiple Video Codec Engine (VCN) hardware instances.
SDL2's headers #define HAVE_PTHREAD_SETNAME_NP (to one here);
we also have a config define which leads the compiler to
warn about this when the values are distinct (as they are here).
Suppress this warning by including config.h before SDL.h.
The latter will then redefine our define which doesn't matter
and which does not lead to warnings because compilers don't warn
about system headers by default (depending upon -Wsystem-headers).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The field width in a %s directive gives the amount of characters
to read from the input and not the size of the receiving buffer;
the latter must be of course also have space for the trailing \0
which has been forgotten here. The commit adds it (and fixes a
-Wfortify-source warning from Clang).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The underlying integer type of an enumeration is
implementation-defined (see C11, 6.7.2.2 (4)); GCC defaults
to unsigned if there are no negative values like for all enums
from pixfmt.h except enum AVPixelFormat.
This means that tests like "if (csp >= AVCOL_SPC_NB)" for
invalid colorspaces need not work as expected (namely if
enum AVColorSpace is signed). It also means that testing
for such an enum variable to be >= 0 may be tautologically
true. Clang emits a -Wtautological-unsigned-enum-zero-compare
warning for this.
Fix both of these issues by casting to unsigned.
Also do the same in libswscale/format.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The previous link lead to a 404 page as that page doesn't exist anymore.
Signed-off-by: Leon Grutters <gruttersleonbot2@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behavior. Pass a dummy buffer instead.
Fixes "runtime error: applying non-zero offset 1024 to null pointer".
affected the SVQ1 vsynth FATE tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behavior.
Fixes "runtime error: applying non-zero offset 8 to null pointer".
Fixes the Snow vsynth FATE-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes "runtime error: addition of unsigned offset to 0x765a09523a90
overflowed to 0x765a09523a8e". This fixes all H.261 tests when run
under UBsan.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
codec20 is raw uncompressed image data.
It exists in Rebel Assault 1 as a special format for STOR/FTCH
and is used again in the Full Throttle Remaster from 2017.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec45 is used in some RA2 videos on top of codec37.
It consists of 2 tables (768 and 32768 bytes), and datapackets
like codec2 (delta-x, delta-y) with a pixel counter instead of a color value.
It then reads the 4 surrounding pixels, looks up 3 separate values
for each in table1, adds them together to form an index into
table2 for a new pixel value, in a row.
The data coming in gets the x/y coordinates out of the visible
area very quickly (2-3 iterations); I don't see any visual
difference between the ffmpeg-produced frames and ones captured
with dosbox from rebel assault 2, which leads me to believe this
codec never worked as intended.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Handle STOR/FTCH the same way the RA1 game engine does:
On STOR, save the next following FOBJ (not the decoded image)
in a buffer; decode it on FTCH.
The RA1 codecs and the fobj handler now take an explicit
GetByteContext in order to be able to replay stored data.
Used extensively by Rebel Assault 1 for e.g. backgrounds and
the cockpit overlay.
For ANIMv2 keep the current system to store the decoded image, as
replaying a FOBJ would not work with codecs37/47/48 due to sequence
violations.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Compression 4 code 0 means copy from delta buffer without mv,
AND start of a skip run. This gets rid of the extra case and column
index manipulation and implements this as it is implemented in the
original game exe, i.e. as a special case for after mv copy.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This codec works on 4x4 pixel tiles, which can be generated and read
from the datastream. They're both identical, codec5 misses a tile
index to skip the current tile.
Codecs33/34 are the same as 4/5 but with a different tileset generator.
Used only in Rebel Assault 1.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This codec alternatingly skips and changes existing pixels.
A second 16bit parameter in the FOBJ header indicates how to do
the pixel changes: either by specifying a LUT in the codec datastream
or by adding a constant value to the pixel.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
this codec consists of 4 byte packets: 2bytes delta-x, 1 byte delta-y
and 1 byte color to put at that spot.
Used in Rebel Assault 1 only.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
codec3 is codec1 which writes zero values instead of skipping them.
This fixes a lot of RA1 videos.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- clear the front buffer with color 0 on the first FOBJ.
Fixes a lot of Rebel Assault 1 videos and Rebel Assault 2 space
scenes (e.g. 08PLAY.SAN which consists only of codec1/2/21 objects
which only ever touch parts of the buffer).
- for ANIMv1 (Rebel Assault 1): set palette index 0 to all zeroes.
This fixes a lot of stray colors in e.g L1HANGAR.ANM, L2INTRO.ANM,
space scenes.
- Esp in RA1, there are a lot of FRME objects which don't contain
any video data (prebuffering some audio only). Account for that.
- In RA1 L2PLAY.ANM there are a few unaligned FOBJs, handle this
in a generic way.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The size of the video frame (FOBJ) of the old codecs (ANIMv0/1/2) can
very reliably be determined:
- ANIMv0/1 (=Rebel Assault 1) uses a 384x242 internal buffer for
everything. The codec parameters only describe the size and offset
of the specific FOBJ on that buffer.
- ANIMv2 titles usually use one of the fullscreen codecs (37/47/48)
as first FOBJ, and their dimensions can generally be trusted.
- RA2 uses 424x260 as internal buffer, use that if encountered:
08PLAY.SAN does not use codec37 so we need to guess using the
codec coordinates.
- ignore sizes smaller than 2x2 or larger than 800x600.
- some game videos have an initial fobj with either 1x1 or -1x-1
pixels in size, ignore them with a warning (Full Throttle
and the Rebel Assault 2 xxRETRY.SAN videos).
Once a known/valid dimension set has been discovered, use it and
don't change it for subsequent FOBJs, rather clamp the large frame
to the determined dimensions.
Tested with RA1, RA2, Full Throttle, Dig, Outlaws, SotE and MotS
videos.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The left/top parameters of a FOBJ are signed values. Adjust
codec1 code accordingly to not draw outside the buffer area.
Rebel Assault 1 makes heavy use of this.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The block-based codecs 37/47/48 work on the full frame, and there's no
existing LucasArts game video that uses left/top offsets for these,
as it doesn't make sense. Ignore the left/top parameters for these codecs.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
fix ticket: 10786
parse the SPS from extradata and
get profile_compatibility, tier, constraints which was been hard code before.
HEVC CODECS Attribute reference to: ISO/IEC14496-15
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
If h2645data.c were changed in a way that makes it rely on another
object file, all components that need h2645data.o would need to be
updated. And given that the VVC decoder->h2645data.o dependency is
currently hidden in a separate Makefile, it would likely be forgotten.
So move it to the libavcodec/Makefile.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
swscale internals don't distinguish between 16-bit and higher bit depth
output formats internally when it comes to the choice of intermediate
representation.
Clamping this value both prevents a SIGFPE and also aligns the check
with reality.
The linker command can exceed the maximum argument limit on MinGW,
especially for libavcodec.
The objects list is now stored in a file and passed to the linker.
This patch adds a fully-featured level 3 and 4 decoder for FFv1,
supporting Golomb and all Range coding variants, all pixel formats,
and all features, except for the newly added floating-point formats.
On a 6000 Ada, for 3840x2160 bgr0 content at 50Mbps (standard desktop
recording), it is able to do 400fps.
An Alder Lake with 24 threads can barely do 100fps.
This commit adds a reference to the buffer as an argument to
start_frame, and adapts all existing code.
This allows for asynchronous hardware accelerators to skip
copying packet data by referencing it.
This commit adds support for hardware accelerated decoding to
the decoder.
The previous commits already refactored the decoder, this commit
simply adds calls to hooks to decode.
Previously, the callback was only called on init. This makes it
get called on every frame.
We should switch to VK_KHR_video_maintenance2 and provide all params
upfront, but almost nothing supports it yet.
This commit uses the recently exported code for host mapping images back
where it was exported from.
The function also had broken download code for image downloading since its
recent refactor.
This commit adds a 32-bit *integer* planar RGBA format.
Vulkan FFv1 decoding is best performed on separate planes, rather than
packed RGBA (i.e. RGBA128), hence this is useful as an intermediate format.
Mixing declarations and code is quite common in Objective-C (as can be
seen by the number of warnings we have for this in Objective-C files)
and forcing to not do it usually results in worse code, with unnecessary
widely scoped variables, which in turn makes variable shadowing and
accidentally using the wrong variable more common and harder to notice.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Passing Objective-C flags from configure to the Makefiles was broken, as
configure incorrectly used the OBJCCFLAGS instead of OBJCFLAGS variable
which was then later overwritten in the common.mak:
OBJCCFLAGS = $(CPPFLAGS) $(CFLAGS) $(OBJCFLAGS)
The fix for this is simple, analogous to how it is handled for CFLAGS,
use OBJCFLAGS here so that the flags are properly included in the
aforementioned OBJCCFLAGS definition.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Nothing in this decoder would break if the generic code were to be
changed to allow slice "threading" with only one thread.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes undefined integer overflows. The overflows could always
happen, yet before 4d8b706b1d
it was not undefined because the code implicitly used atomic
types, for which signed integer overflow is defined.
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If there were not enough data, checksum_size would be read
as zero (due to the implicit checks of the bytestream2 API)
and run into a "data block size invalid" error. Erroring out
earlier via "not enough extradata" is better.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It makes no sense to try to be exact with max depth
in get_vlc2(): It will mean that the compiler emits code
for all three stages of parsing and runtime checks for
whether max_depth is big enough to parse the next stage
when a not yet complete code has been encountered.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, decode_block() zeroed every block (of 128 bytes)
before decoding a block; yet this is suboptimal for all modes,
because all modes need to reset all the blocks they use anyway
and so it should be done in one go for all blocks.
For the alpha modes (where blocks need not be coded) all blocks
are zeroed initially anyway, because decode_block() might not
be doing it, so zeroing there again for the coded blocks is
a waste.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows to share them between frame threads.
dc11 can unfortunately not be made static without increasing
LOCALBUF_ELEMS in vlc.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is trivial as well as beneficial because frame threads
now use the same table, saving cache/memory.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to expose HQXContext in a header
and allows to make several symbols static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
hqxvlc.c contains sort-of run-length VLCs in hardcoded form;
they amount to 26688 elements, taking 104KiB. These tables contain
many duplicated entries (they are partially created via a RPT_1024
macro). There are actually only 3039 different codes in all tables
combined, making this very wasteful.
This commit changes this by extracting the underlying entries
and creating a (static) RL-VLC. This only costs 3*3039 bytes
of .rodata. The resulting table needs only 15630 entries,
because our VLC init code uses smaller subtables when possible
(for an incomplete code, the negative of the length stored in
the VLC code is the number of bits the subtable uses; the hardcoded
tables uses a worst-case per table value).
Using GET_RL_VLC also gets rid of an unnecessary reload in case
a code is too long to be parsed in the first stage.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will simplify creating RL-VLCs (which until now used
a stack-based VLC as temporary buffer).
Notice that there would be another option to merge them, namely:
struct VLCElem {
union {
VLCBaseType sym;
int16_t level;
};
int8_t len;
uint8_t run;
};
The main difference to the current patch is that this would change
the type of the length field of VLCElem to int8_t from int16_t.
It turns out that that this would entail additional sign extensions
on ppc, see https://godbolt.org/z/behWYEYE7. I have therefore refrained
from doing so, although it would make the patch simpler.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These fields are meant to be for encoders; just use a local
table in pcm_decode_init() to convert from AVCodecID to AVSampleFormat
and also use it to provide sample_size.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead use a dedicated context for the few decoders that
use the LUT. Also use a dedicated init function for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also align it in preparation of a slightly longer macro.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
No need to go through two switches per packet.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All codecs here have a valid sample size at this point.
This check has (presumably) been added for DVD PCM,
but even for them the check was always-true after
381e195b46 (and the DVD
code was later moved out altogether). So just remove
this check and the leftover DVD comment.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said escape code is only six bits long, so that one has at least 25 - 6
bits in the bitstream reader's cache after reading it; therefore the
whole following 16 bits (containing the actual code) are already in the
bitstream reader's cache, making it unnecessary to reload the cache.
This is the eamad analogue of fe9bc1cc45.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said escape code is only six bits long, so that one has at least 25 - 6
bits in the bitstream reader's cache after reading it; therefore the
whole following 16 bits (containing the actual code) are already in the
bitstream reader's cache, making it unnecessary to reload the cache.
This is the mdec analogue of fe9bc1cc45.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These values are only used by the mpegvideo unquantize functions,
yet these are not active when intrax is in use. Furthermore,
given that ff_intrax8_decode_picture() decodes multiple
macroblocks in a given call, it makes no sense to return
any value (that was in practice the maximum of the indices
of all the macroblocks decoded).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the mpegvideo unquantize functions which
this decoder does not use at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
dst_depth - src_depth where the result is 6 or 7 in a high bd path means this
is only executed for 16 -> 10 and 16 -> 9.
This patch makes this path general, supporting arbitrary formats as long as
dst_depth > src_depth > 8.
Signed-off-by: James Almer <jamrial@gmail.com>
If pps_single_slice_per_subpic_flag is 1,
slice_{width,height}_in_tiles are undefined and we must instead get the
dimensions of the slice by referring to the corresponding subpicture.
Signed-off-by: Frank Plowman <post@frankplowman.com>
av_frame_side_data_add() typically takes ownership of
the provided AVBufferRef reference and therefore
uses a parameter of type AVBufferRef**; yet with
the AV_FRAME_SIDE_DATA_FLAG_NEW_REF, it creates
new references instead, without touching the given
reference. Therefore it is safe to cast const away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
utils.c is getting quite crowded, and I need a new place to dump a lot of
format handling code for the ongoing rewrite. Rather than bloating this file
even more, start splitting format handling helpers off into a new file.
This also renames the existing utils.h header, which didn't really contain
anything except the SwsFormat definition anyway (the prototypes for what should
have been in utils.h are all still in the legacy swscale_internal.h).
This also makes remap optional (which is a good idea even if we decide to keep flip fixed)
Effect on compression (using 2 rawlsb, golomb rice, large context model with ACES_OT_VWG_SampleFrames
-rw-r----- 1 michael michael 499101306 Mär 11 14:58 float-303503-try3d-m2.nut
-rw-r----- 1 michael michael 503700199 Mär 11 14:57 float-303503-try3d-m1.nut
-rw-r----- 1 michael michael 518150578 Mär 11 14:57 float-303503-try3d-m0.nut
(the test above used the rawlsb patch, which is not applied yet)
Reviewed-by: Jerome Martinez <jerome@mediaarea.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
and call it from ff_ffv1_encode_init()
setting micro version from code writing the extradata is messy, this should
be cleaner
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The webvtt extension is sometimes used in HLS playlists.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has been deconstified in 2c2dfd9149
because the FFCodec is touched in av_codec_init_static because
of its get_supported_config callback. Yet this is easily remedied:
Only call get_supported_config to set pix_fmts if the codec does
not already have it set.
This also fixes a mismatch between the declaration of ff_mjpeg_encoder
in allcodecs.c and the definition in mjpegenc.c. Said mismatch is
actually undefined behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only two encoders (the native MPEG-1/2 ones) provide
supported_framerates and they don't implement the
get_supported_config callback. It is highly unlikely that
any codec will set supported_framerates dynamically at all,
so remove the code querying for frame rates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions check whether the AVCodec* is NULL, but this
has already been checked at a lot of places in our codebase,
so that it boils down to checking the is_decoder flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It also applies to scenarios where ff_encode_receive_frame()
is used. Also remove the redundant av_codec_is_decoder().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sbcdec_data.h is only included by sbcdec.c, so this won't
cause the data to be included multiple times in the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ///< or /**< form of doxygen comments are only to be used
when the documentation follows the member and the comment
block starts on the same line as the member. This commit
fixes wrong uses of them; in particular, this fixes the comment
for mb_height in H.264 SPS's structure which was wrongly added
to mb_width.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to inline put_vc2_ue_uint() everywhere;
only one call site is actually hot: The one in encode_subband()
(which accounts for 35735040 of 35739495 calls to said function
in a FATE run). Uninline all the others.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The precision should be enough for primaries and luminance.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Also remove the condition of AMF_DATA_TYPE_BOOL when parse color
info. There is no AMF_DATA_TYPE_BOOL type in color info.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
1. Rename metaVideoColor to meta_color_info
2. Allocated FLVMetaVideoColor together with FLVContext
3. Improve the use of meta_color_info_flag. Do a sequence of strcmp
only if meta_color_info_flag is FLV_COLOR_INFO_FLAG_PARSING.
4. Check return value of amf_parse_object().
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
sizeof AVMasteringDisplayMetadata isn't part of ABI.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Up until now, the encoder processed only one bit at a time.
With this patch, it is eight bits.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The return value of ff_draw_init and ff_draw_init2 are not checked in
most usages. However, if they return an error, they don't get to the
point where they set the attributes of the FFDrawContext. These
functions are typically used in conjunction with ff_draw_color, which
checks draw->desc->flags, causing a null pointer dereference.
Signed-off-by: Nil Fons Miret <nilf@netflix.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch refactors the CUDA import code to allow for Vulkan images
with multiple planes to be mapped.
Currently, a driver bug exists which causes NV12 images to be mapped
incorrectly when the memory being mapped contains both planes, the
issue has been reported to NVIDIA.
yuv420p does work correctly, however.
This is still an improvement, as the code used to crash when trying to
map the memory, unless disable_multiplane=1 was given as an option.
When using a 64bit PutBitContext (i.e. on x64), put_bits_no_assert()
can naturally write up to 63 bits. So one can avoid treating the
cases <32bits, 32 bits and <63 bits differently.
As it turns out, no user actually wants to write 64 bit at once
(maybe except testprograms).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code used a loop to determine the number of bits used
and called ff_log2() on a power of two (and it would be easy to
keep track of the exponent of said power-of-two); neither GCC nor
Clang optimized the loop away or avoided the ff_log2().
This patch replaces the loop and the log2 with a single av_log2().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We normally don't need else statements here; the common pattern
is to assign lower level SIMD implementations first, then
conditionally reassign higher level ones afterwards, if supported.
Signed-off-by: Martin Storsjö <martin@martin.st>
The aim of this is twofold: a) Clang warns when setting a deprecated
field in a definition and because several of the widely set
AVCodec fields are deprecated, one gets several hundred warnings
from Clang for an ordinary build. Yet fortunately Clang (unlike GCC)
allows to disable deprecation warnings inside a definition, so
that one can create simple macros to set these fields that also suppress
deprecation warnings for Clang. This has already been done in
fdff1b9cbf for AVCodec.channel_layouts.
b) Using macros will allow to easily migrate these fields to internal ones.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
where appropriate. Avoids including ff_vp8_decode_frame()
when the VP8 decoder is disabled.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While just at it, also move the init functions inside
the #if CONFIG_VP?_DECODER (to avoid linking failures).
While just at it, also declare these init functions
as av_cold and uninline the remaining common init function.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When pps_num_exp_slices_in_tile[i] is nonzero, the ith tile is made up
of pps_num_exp_slices_in_tile[i] slices stacked atop one another, where
the height of the jth slice in the ith tile is given by
pps_exp_slice_height_in_ctus_minus1[i][j]. The sum of the heights of
the slices in the tile should not exceed the height of the tile itself.
Signed-off-by: Frank Plowman <post@frankplowman.com>
It comes from a time before frames were refcounted; it has indeed been
added in a follow-up commit to c13e490dce:
"codec_release_buffer: fix handling of non user buffers". This type
of check is obsolete now.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This improves compression by 0.1% overall and 44% for the changed table
I tried several other things but so far this is the best
compromise between complexity and compression
This can also be extended to 32 and 64bit floats
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows switching it on conditionally and also for non float,
it may improve compression for RGB data that was paletted
or other synthetic images
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
float16 (and more so float32) have many odd values
half the values are negative, many are larger than "1.0"
and many values are very close to 0.
Storing the 16bits as is, looses compression because of the mixture
of dense and sparse regions and also many completely unused ones.
This simply remaps the 65536 values so no unused values remain
This improves compression by about 1.5% for the ACES_OT_VWG_SampleFrames testset
(this testset contains all kind of funny values including many images
with negative rgb values)
The space needed for the map is insignificant compared to the
compression gained
This patch also flips half the float range as it can be done
using the same table.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't error out, just ignore unknown codec numbers and pretend
decode succeeded. This is useful for older LucasArts titles
which stack a lot of different FOBJs with different codecs into
a single frame.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise it is possible for av_log() to receive a non-NULL object
with a NULL AVClass pointer; the default log callback handles it
gracefully, yet this is probably an API violation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While it is save for these codecs (they all have private contexts),
it is customary to always use the AVCodecContext for logging.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The logging functions here can be reached by codecs without
private class, so that the log callback will receive a non-NULL
object whose AVClass pointer is NULL. Although the default log
callback handles this gracefully, it is probably an API violation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said parent is shared between all slice contexts and encode_block()
can be run concurrently by slice threads, so the parent context
must not be (and is not) modified. So constify the pointers.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both these options are unsupported and silently ignored for AMV;
so it is better to not offer them at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is an extremely simple function that is only called once,
so it should be inlined.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also only allocate them when they are needed (namely iff
adaptive quant is true) and allocate them jointly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move this code to init_matrices().
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Used with trellis; notice that inter_matrix is unused for
(intra-only) SpeedHQ, so it is irrelevant that its value changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also start factoring the matrix-init code out into a function
of its own to declutter ff_mpv_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently does two things: a) Get a prediction for the dc
and the dc direction and b) process said prediction. Processing
the prediction differs for encoding (getting a diff) and decoding
(getting the level via diff+prediction). So having a common function
performing b) makes no sense.
Even worse, there is a decoding mode where the dc coefficient (diff)
is not coded specially and therefore unavailable before entering
the block decoding loop, so that one can only perform a). Before
this commit, the decoder simply called ff_mpeg4_pred_dc() twice;
the results of the b) part of the call before the loop were ignored
(but the compiler could not elide them because they involved error
messages) and a) was also performed twice.
This commit changes this by splitting b) out of ff_mpeg4_pred_dc()
and moving this code to decoder and encoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The scantables are unused for the parser (and in fact
the IDCT permutation used has not been initialized at all).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(To perform this optimization a compiler would have to look
at both ff_rv_decode_dc() and av_log(). The latter seems very
unlikely.)
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
h263_aic is always zero for FLV and ff_mpeg1_dc_scale_table
is already the default dc_scale table for both y and c.
h263_aic is also always zero for the FLV decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They only do it for the mv_penalty table. Factor initializating
the static tables out into a function of its own; also move
everything not needed by SVQ1 or Snow behind #if CONFIG_H263_ENCODER
(this involved moving ff_h263_encode_motion() which is used
by svq1enc).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MPEG-1/2 and the H.263-based encoders overwrite the default later
and SpeedHQ and MJPEG-based encoders are intra-only and don't
need a mv_penalty table at all. So only H.261 uses this table.
Also add a comment to explain why it exists and is non-const.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Compilers can not perform this optimization on their own
given that they don't know that the different thread_context
pointers don't alias.
Also avoid using sequentially consistent operations with
atomics when only a single thread accesses them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The VC-1 decoders don't need ScanTable.raster_end as
they don't call any of the unquantize functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it only returned the number of bits for the
start offset, but not the start offset; the GetBitContext
passed to it was unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not possible to put USAC into ADTS due to exceeding the
field size (4 bits) for ADTS profile. As such cases where
the frame starts with 0xfff shouldn't be checked.
This ensures the sample at https://crbug.com/396190942 is
properly detected as USAC content.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Storing the values via a union of an uint32_t and a float makes
said union the effective type of the destination. This means that
it may only be read via such a union which is of course not what
our users do/expect. So store the values via AV_WN32A instead
which disables effective type analysis (for compilers that perform it).
This also fixes a -Wdeclaration-after-statement warning
introduced in 0e917389fe.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise compilers might emit code that presumes there to be
a GOT which can't be fixed by the linker.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is inspired by the equivalent dav1d attribute introduced
by Henrik Gramner in e4c4af02f3de5e6cea6f81272a2981c0fa7bae28.
Also already use it to beautify declarations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When used with the "mpegvideo" or "mpeg1video" decoder (which do not
have a private class) this would lead to the log callback receiving
a non-NULL object with a NULL AVClass pointer. The default log callback
handles this gracefully, yet it is probably an API violation.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the initialization of AMV's matrices happened
after the initialization for MJPEG matrices, overwriting
the earlier data. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the packet is reference-counted
and because we never combine the data from several packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible by moving the code using it to open a GetBitContext
from h263dec.c to mpeg4videodec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All hwaccels for MPEG-4/H.263 are run serially even when frame-threading
is in use. Therefore there is no gain in calling
ff_thread_finish_setup() in this case right before outputting
the frame.
Removing this call also allows to revert commit
39a5c0ac06.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1/2 decoders don't need ScanTable.raster_end
(as the coefficients are unquantized as they are parsed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is pointless to try to report the true number because
decode_simple_internal() always treats the buffer as
completely consumed for video codecs anyway.
(Apart from that: The h263dec code would report to only
have consumed the header data in case decoding is aborted
due to skip_frame which makes no sense.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added in 59fa3f96f4,
yet avctx->workaround_bugs is never copied to
MpegEncContext.workaround_bugs, so this code is dead
(it seems that this was true even when it was added).
Furthermore, workaround_bugs is flagged as decoder-only,
so just remove the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't reuse MpegEncContext.max_b_frames, which is supposed
to be encoder-only.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by MPEG-4 (and is used in h263dec.c and can therefore
not just be moved to Mpeg4DecContext...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since d50635cd24 the
dct_unquantize_h263_intra functions have set the number of
coefficients to 63 in case of ac_pred, so ff_msmpeg4_decode_block()
doesn't have to bump it on its own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This code has been added in f5957f3fe2
when support for WMV1 has been added. It was needed for decoding
inter macroblocks, as WMV1 uses a different scantable and
the ScanTable and ScanTable.raster_end was not yet introduced
(the H263 unquantize function instead used a hardcoded version
of ff_zigzag_direct's raster_end). In other words,
there is no reason to continue to do so for WMV1 inter blocks.
(Apart from that: WMV1 inter blocks don't use
dct_unquantize_h263_inter any more, as unquantizing happens
when parsing the block via specialized RL VLC tables.)
It is also not needed for WMV1/2 intra blocks (for non-ac_pred
it uses the correct ScanTable used by the h263 unquantize
intra function; for ac_pred, the number is overridden)
as well as for WMV2 inter-blocks (raster_end is not really
used in this case; the ordinary ScanTable is used in case
abt_type is zero, otherwise there are two different ScanTables
and block_last_index is overridden in wmv2dec.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder unquantizes while parsing blocks
and does not use dct_unquantize_mpeg1_intra
(which uses *_dc_scale) at all.
repeat_field was unused since
e0a3d744a0.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value here has been set in ff_set_qscale() from
ff_mpeg1_dc_scale_table, all of whose entries are 8.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Encoding was untested before this.
Notice that the filesize degradation is partially due to
mpegvideo no longer using progressive_sequence and
progressive_frame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Effectively reverts c59b5e3d1e.
This is possible now that ff_print_debug_info2() uses
the MPVPicture dimensions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MotionEstContext contains pointers (to function pointers) that
have been set on a per-frame basis depending upon no_rounding
in ff_me_init_pic() to avoid branches like these. Also makes
MotionEstContext more independent of MpegEncContext.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mpegvideo-based encoders do one uncommon thing with
the packet's data given by ff_alloc_packet(): They potentially
reallocate it. But this only affects the internal buffer
and is not user-facing at all, so one can nevertheless
use the AV_CODEC_CAP_DR1 for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When there are multiple candidates for macroblock type, the encoder
tries them all. In order to do so, it keeps several sets of states
containing the variables that get modified when encoding
the macroblock and in the end uses the best of these.
Yet one variable was set, but not included in this state:
The current macroblock's qscale value in the current picture's
qscale_table. This may currently be set multiple times in
mpv_reconstruct_mb(), yet it is read when adaptive_quant is true.
Currently, the value read can be the value set by the last attempt
to write the current macroblock and not the initial value.
Fix this by only setting the qscale_table value in one place
outside of mpv_reconstruct_mb() (where it does not belong at all).
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reduce binary size at the same time. The performance compared to clang -O3
is the same.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
'avs3' is registered at mp4ra.org. The Avs3ConfigurationBox 'av3c'
inside 'avs3' hasn't been registered yet, but is specified by the
AVS3 spec.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The idea is to split the 16 bit coefficients into lower and upper half,
invoke udot for the lower half, shift by 8, and follow by udot for the
upper half.
Benchmark on A78:
bgra_to_y_128_c: 682.0 ( 1.00x)
bgra_to_y_128_neon: 181.2 ( 3.76x)
bgra_to_y_128_dotprod: 117.8 ( 5.79x)
bgra_to_y_1080_c: 5742.5 ( 1.00x)
bgra_to_y_1080_neon: 1472.5 ( 3.90x)
bgra_to_y_1080_dotprod: 906.5 ( 6.33x)
bgra_to_y_1920_c: 10194.0 ( 1.00x)
bgra_to_y_1920_neon: 2589.8 ( 3.94x)
bgra_to_y_1920_dotprod: 1573.8 ( 6.48x)
Signed-off-by: Martin Storsjö <martin@martin.st>
Change the type of logctx from void* to AVFormatContext*. This is in
preparation for the next commit.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some frames may be buffered before a complex filtergraph can be configured.
This change ensures the side data removal in the cases where autorotation is
enabled also applies to them.
Fixes ticket #11487
Signed-off-by: James Almer <jamrial@gmail.com>
ff_decode_frame_props() injects global side data passed by the caller (Usually
coming from the container) but ignores the global side data the decoder
gathered from the bitstream itself.
This commit amends this.
Signed-off-by: James Almer <jamrial@gmail.com>
This simplifies the code, reduces allocations, and critically, does
not store references of frames, along with references to hw_frames_ctx.
The issue was that storing refs to frames while transferring stored
refs to hw_frames_ctx of frames, and so created a circular dependency,
which caused the Vulkan device to never be terminated.
This only stores what it strictly needs as a dependency, and enables
the frames context to be freed, even while doing asynchronous transfers.
It prevents the filter of running in case such option is missing,
failing early, during init() instead of simply logging an error
during runtime.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
Instead, rely on AV_OPT_TYPE_FLAG_ARRAY, which will automatically
perform the parsing.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
Instead of calculating a^2, b^2, (a+b)^2 and (a-b)^2, calculate only
a^2, b^2 and 2*a*b in each iteration and derive the latter parts from
these three at the end.
Before and after:
A78
ac3_sum_square_bufferfly_int32_neon: 484.8 ( 2.00x)
ac3_sum_square_bufferfly_int32_neon: 468.2 ( 2.08x)
A72
ac3_sum_square_bufferfly_int32_neon: 793.6 ( 1.26x)
ac3_sum_square_bufferfly_int32_neon: 527.3 ( 1.92x)
Signed-off-by: Martin Storsjö <martin@martin.st>
Constify dstStrice argument of rgbx_to_nv12_neon_16_wrapper to be
compatible with other functions as used in function assignment.
Signed-off-by: Adam Lackorzynski <adam@l4re.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
(setting to 100 as a reasonable compromise)
The change has caused regressions for many users and consumers.
Playlist reloads only happen when a playlist doesn't indicate that it
has ended (via #EXT-X-ENDLIST), which means that the addition of future
segments is still expected.
It is well possible that an HLS server is temporarily unable to serve
further segments but resumes after some time, either indicating a
discontinuity or even by fully catching up.
With a segment length of 3s, a max_reload value of 1000 corresponds to
a duration of 50 minutes which appears to be a reasonable default.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The issue is that this could consume gigabytes of VRAM at higher
resolutions for not that much of a speedup.
Automatic detection was not a good idea as we can't know how much
VRAM is actually free.
Just remove it.
BGR formats in Vulkan cannot be used in storage images, as the
pixel labels on storage images are always ordered as RGB, and
swizzling is not an option due to old hardware limitations.
This means that you must always use an RGB format and manually
swizzle when reading or writing to BGR images, or simply not use
a format in the shader itself.
This adds support for the latter.
&pl_alpha_overlay expects straight alpha, but the alpha output may be
premultiplied as a result of the target alpha mode (or in the absence of an
alpha channel). Fix it by requesting independent alpha explicitly when
blending.
There is no reason to only do this on the first input. It doesn't actually
matter for now given that we don't constrain the color space list, but it
may matter when that changes.
Signed-off-by: Niklas Haas <git@haasn.dev>
Each input is entirely independent and can have varying pixel formats,
color spaces, etc. To accomplish this, we need to make a full copy of the
format list for each subsequent input, rather than sharing the same ref.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Fixes a deprecation warning, and also fixes a bug where the depredated
skip_target_clearing option was not correctly mapped to the new API inside
libplacebo upstream.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
These were introduced in libplacebo API version 220. We actually already
map the field by default, but deinterlacing was never enabled unless the user
explicitly forced it using extra_ops.
This filter already failed to compile on older versions, because of an
unconditional use of an API introduced in API version 220. Nobody noticed
this, so I conclude that it's safe to bump the required version by now.
External libraries are not components and so their CONFIG_ define
is in config.h.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently uses an intermediate int which wouldn't work
if linesize exceeded the range of int and inhibits compiler
optimizations. Also switch to pointer arithmetic and use
smaller scope.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avctx->bits_per_raw_sample is always 10 or 12 here;
the checks have been added in preparation for making
bits_per_raw_sample user-settable via an AVOption,
but this never happened.
While just at it, also set unpack_alpha earlier
(where bits_per_raw_sample is set).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using LONG_BITSTREAM_READER means that every get_bits() call
uses an AV_RB64() to ensure that cache always contains 32 valid bits
(as opposed to the ordinary 25 guaranteed by reading 32 bits);
yet this is unnecessary when unpacking alpha. So only use these
64bit reads where necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP streams via
GStreamer.
It also adds the required SDP attributes for AV1.
AV1 RTP encoding is marked as experimental due to
draft specification status, debug amount reduced
and other changes suggested by Tristan.
Added optional code for searching the sequence
header to determine the first packet for broken
AV1 encoders / parsers.
Stops depacketizing on corruption until next keyframe,
no longer prematurely issues packet on decoding if
temporal unit was not complete yet.
Change-Id: I90f5c5b9d577908a0d713606706b5654fde5f910
Signed-off-by: Chris Hodges <chrishod@axis.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
If there's ever a rework of the AAC encoder, it won't start from here.
The codec, with all its oddities and tweaks needed to acheive good quality
has strayed far from the academic work upon which this coder was based on.
Its been 20 years since this paper was released, and no known existing
implementations, open-source or proprietary that we know of, are based on it.
The LTP profile of AAC is... terrible.
It was an early 90's attempt at bridging the gap between speech
codecs and general purpose codecs. It did so by trying to exploit the fact
that most speech patterns are regular.
Unfortunately, it went about it the same way as AAC Main, by taking
the previous frame's samples, modifying them through an LPC filter,
transforming them back using a forward MDCT, putting the output
coefficients back into the current frame, and using delta coding.
But once again, they ignored basic mathematics and MDCT leakage.
Thankfully, because AAC LTP is meant to operate at very low bitrates,
the extreme quantization results in most leakage being irrelevant.
Unfortunately, the result is that the output sounds pretty much
terrible regardless of whether LTP is enabled or not.
This was the first attempt at trying to couple speech coding into AAC.
No, the second attempt did not succeed either.
Nnnneither did the third. Or fourth.
For the fifth one, they literally just jammed a speech codec into AAC
with USAC once they saw Opus do it.
Just drop support for encoding AAC LTP. It was always experimental
to begin with.
The Main profile of AAC is... terrible.
It enables the use of delta coding across coefficients of two frames
to try to increase compression, and it enabled one more pole for TNS
filters.
What the AAC authors failed to take into account were basic
mathematics, as MDCT leakage (e.g. the spread of each frequency when
represented in a discrete spectrum) is significant in most audio codecs.
This leads to huge variations between each frame, basically rendering
prediction completely pointless.
In fact, enabling AAC-Main prediction does not, in general, even recoup
the metadata losses from signalling the profile and prediction properties
in the first place. So you lose efficiency by using AAC Main.
The rumor is that it was put in the AAC spec for patent reasons, though
patent-wise, it has about as much use as a patent for a bicycle designed
for use by snakes.
The only other thing AAC Main changes is it permits 3-pole TNS filters.
When AAC's bands are absolutely tiny, except for very high frequency bands,
where you're likely to use PNS instead.
Just get rid of it.
This changes the default behaviour of ffmpeg where content-type headers
on an input gives an absolut probe score (of 75) to instead give a bonus
score (of 30). This gives the probe a better chance to arrive at the
correct format by (hopefully) giving a large enough bonus to push edge
cases in the right direction (MPEG-PS vs MP3, I am looking at you) while
also not adversly punishing clearer cases (raw ADTS marked as
"audio/mpeg" for example).
This patch was regression tested against 20 million recent podcast
submissions (after content-type propagation was added to
original-storage), and 50k Juno vodcasts submissions (dito). No adverse
effects observed (but the bonus may still need tweaking if other edge
cases are detected in production).
When an Info-tag is present, marking initial and trailing samples as
padding, those samples should not be included in the calculation of track
duration.
This solves a surprising user experience where converting a WAV->MP3->WAV,
ffprobe will show the duration of the mp3 as slightly longer than both the
input and the output.
As a result, the estimated duration and imprecise seek-results of some
FATE-tests have been updated.
rtmp_write is used both for writing outputs as a server. The
rt->listen flag determines which mode we're running in.
Previously, when running as a server, the message stream id would
always be set to 0 for media/metadata messages. This is surprising
given that we have both responded to "createStream()" with a value
of 1 and sent a "Stream Begin 1" to the client. Furthermore, some
client libraries (Red5) seem to trip up on receiving
"@setDataFrame" on stream 0 (and may be correct to assume that
this message would be sent on stream 1).
Forward errors from `avio_read` directly. When `avio_read` sees EOF before
expected bytes can be read, consistently return `AVERROR_INVALIDDATA`
We used to return `AVERROR(AVERROR_INVALIDDATA)` when failing to read
metadata block headers. `AVERROR_INVALIDDATA` is already negative, so
wrapping in `AVERROR` leads to double-negation.
We used to return `AVERROR(EIO)` when failing to read extended metadata.
However, many times, the IO-layer is not at fault, the input data is simply
corrupted (truncated), so we return `AVERROR_INVALIDDATA` here as well.
---
Tomas: changed to use AVERROR_EOF
WMA files that fail to decode due to incoherent block lengths and
frame lengths currently result in a "Operation not permitted".
After this change, they will instead result in "Invalid data found
when processing input".
Several other error cases are also changed from returning -1.
As we change the error propagation logic in wma_decode_frame and
wma_decode_superframe, previous occurrences of returning
AVERROR_INVALIDDATA are also affected by this. This includes
"total_gain overread" and a "channel exponents_initialized" check.
---
Tomas: changed some -1's to AVERROR_INVALIDDATA
Currently, a prematurely broken connection normally leads to the same
EOF, as a completed successful transfer. However, enabling reconnect
changes this logic, and leads to the return of EIO.
This patch unifies that logic, leading to the return of EIO for premature
disconnect, regardless of setting of "reconnect".
This fixed wasm checkasm failure
$ wasm-tools validate tests/checkasm/checkasm
error: wasisdk://v25.0/build/sysroot/wasi-libc-wasm32-wasip1-threads/libc-top-half/musl/src/stdio/__stdio_close.c:24:9 function `__stdio_close` failed to validate
Caused by:
0: func 4581 failed to validate
1: type mismatch: expected i32 but nothing on stack (at offset 0x43b770)
Since close is declared as static function, it's more like a bug
in wasi sdk, but we can workaround it easily.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: James Almer <jamrial@gmail.com>
We can't use AV_FRAME_SIDE_DATA_FLAG_REPLACE here because the side data already in the
frame should have priority over the global one, so just ensure we don't copy any if
it already exists.
Fixes ticket #11468.
Signed-off-by: James Almer <jamrial@gmail.com>
This compares the MITRE CVE list with our webpage security list and
produces a diff, so people can investigate, fix, backport and correct
differences
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes several #if checks. While just at it, also switch
to static mutex initialization.
This commit does not enable -show_log for builds without threads
though.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
At present, if reading from a readrate-limited input is stalled,
then upon resumption, ffmpeg will read the input without any
throttle till the average readrate matches the specified readrate.
This new option allows to set a speed limit when reading is resumed
until the average readrate matches the primary readrate.
Fixes#11469
This is essentially a re-implementation of
2024100522.54158-1-post@frankplowman.com/
That patch was not applied last time. Instead we opted to identify
issues which could be caused by invalid subpicture layouts and remedy
those issues where they manifest, either through error detection or code
hardening. This was primarily implemented in the set
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13381.
This has worked to some degree, however issues with subpicture layouts
continue to crop up from the fuzzer and I've fixed a number of bugs
related to subpicture layouts since then. I think it's best to return
to the initial plan and simply check if the subpicture layout is valid
initially.
This implementation is also lighter than the first time -- by doing a
bit more logic in pps_subpic_less_than_one_tile_slice, we are able to
store a tile_in_subpic map rather than a ctu_in_subpic map. This
reduces the size of the map to the point it becomes possible to allocate
it on the stack. Similar to 8bd66a8c95,
the layout is also validated in the slice map construction code, rather
than in the CBS, which avoids duplicating some logic.
Signed-off-by: Frank Plowman <post@frankplowman.com>
In the case pps_subpic_less_than_one_tile_slice is called, the
subpicture is smaller than the tile and so there are multiple
subpictures in the tile. Of course, then, not all the
subpictures can start in the top-left corner as the code before the
patch does. Patch fixes this, so each subpicture starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).
Signed-off-by: Frank Plowman <post@frankplowman.com>
A large part of this template is decoder-only. This makes
the complexity of the IS_ENCODER-checks not worth it.
So simply merge the template into both its users.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a more appropriate place than a function designed
to reconstruct a macroblock. It furthermore limits these checks
to the codecs that actually need it (and removes it from e.g.
RV10 and RV20 -- the latter actually uses these buffers, but
only for intra-frames, so they don't need to be cleaned
manually).
This furthermore means that ff_mpv_reconstruct_mb() and therefore
also the error-resilience code no longer needs block_index set.
This fixes a crash caused by 65d5ccb808
when ff_mpv_reconstruct_mb() is called by VC-1 code without
block_index being initialized properly (VC-1 uses and initializes
block_index itself normally).
Fixes: 69814/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4868081575329792
Fixes: heap-buffer-overflow
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1/2 encoders are the only non-intra-only mpegvideo
encoders that want last_dc reset when encoding non-intra macroblocks.
Therefore move resetting it to mpeg12enc.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the MPEG-1/2, MSMPEG4V1, MPEG-4 and RV.10 decoders use last_dc
at all. Of these, RV.10 only uses it for intra frames; it does not
need these predictors reset in ff_mpv_reconstruct_mb(). MSMPEG4V1
has h263_pred set, so that last_dc is already not reset in
ff_mpv_reconstruct_mb() (instead it is reset at the beginning
of every line). MPEG-4 also has h263_pred set (and uses last_dc only
for the intra-only studio profile and needs them reset to sligthly
different values anyway).
So only the MPEG-1/2 decoders need these values reset. So move
resetting them there. This avoids resetting them unnecessarily
for FLV1, H.261, H.263I, RV.10, RV.20 and H.263(+)
(for the latter it depends upon whether h263_aic is in use).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SVT-AV1 made a change in their public API in 988e930c but without a
version bump or any other accessible marker, thus breaking ffmpeg build
with current versions of SVT-AV1.
They have finally bumped versions a month later, so check added.
The clamping of idxYInv from H.266(V3) section 8.8.2.3 was missing.
This could lead to OOB reads from lmcs->pivot or input_pivot.
I also changed the derivation of the forward LMCS idx to use a shift
rather than a division for speed and as this is actually how the
variable is declared in the specification (8.7.5.2).
Signed-off-by: Frank Plowman <post@frankplowman.com>
Before .buf_elems, users had to manually print to a string if they
wanted a non-fixed number of elements in an array.
Since we're printing everything to the shaders manually anyway, use
the new mechanism.
This enables users to specify a number that would be appended to
the buf_content string.
Saves users from needing to manually print to a string.
An earlier commit tried doing this via .elems, but it was
faulty, as this also incremented the total number of descriptors
in the descriptor set.
This adds support for default range coder tables, rather than
only custom ones. Its two lines, as the same code can be used
for both thanks to ffv1enc.c setting f->state_transition properly.
Theora signals "Output last frame again" with an empty packet.
To keep the behaviour of 18f24527eb of ignoring side data only packets, as
generated by the FLAC encoder to propagate updated extradata, also check for
pkt->side_data_size to choose wheter to mux the paket or not.
Fixes part of ticket #11451.
Signed-off-by: James Almer <jamrial@gmail.com>
If sc->tts_count is not 0, then the sample index has already been built.
Fixes: Null-dereference READ
Fixes: 396192874/clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4589309789143040
Signed-off-by: James Almer <jamrial@gmail.com>
The scalar loop is replaced with masked AVX512 instructions.
For extracting the Y from UYVY, vperm2b is used instead of
various AND and packuswb.
Instead of loading the vectors with interleaved lanes as done
in AVX2 version, normal load is used. At the end of packuswb,
for U and V, an extra permute operation is done to get the
required layout.
AMD 7950x Zen 4 benchmark data:
uyvytoyuv422_c: 29105.0 ( 1.00x)
uyvytoyuv422_sse2: 3888.0 ( 7.49x)
uyvytoyuv422_avx: 3374.2 ( 8.63x)
uyvytoyuv422_avx2: 2649.8 (10.98x)
uyvytoyuv422_avx512icl: 1615.0 (18.02x)
Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
texture() uses bilinear scaling; imageLoad() accesses the image directly.
The reason why texture() was used throughout Vulkan filters is that
back when they were written, they were targetting old Intel hardware,
which had a texel cache only for sampled images.
These days, GPUs have a generic cache that doesn't care what source it
gets populated with. Additionally, bypassing the sampling circuitry saves
us some performance.
Finally, all the old texture() code had an issue where unnormalized
coordinates were used, but an offset of 0.5 was not added, hence each
pixel ended up being interpolated. This fixes this.
Remove a for loop and make it easy to extend to support other types
of scalability. Move ScalabilityMask to hevc header file so it can
be used in hevc decoder.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: out of array access
Fixes: 385170375/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-4710055187906560
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: null pointer dereference
Fixes: 385644864/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4551049565765632
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>
The limit is based on later code storing 32bits
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 393164866/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4606798354513920
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
types and SFO become confused for a USAC stream
Fixes: out of array access
Fixes: 383854203/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4996677847547904.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -251517880 * 32 cannot be represented in type 'int'
Fixes: 385224934/clusterfuzz-testcase-minimized-ffmpeg_dem_W64_fuzzer-4909298151915520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit adds two logging flags: 'time' and 'datetime'.
Usage:
ffmpeg -loglevel +time
or
ffmpeg -loglevel +datetime
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the fail: block of decode_nal_units, a check as to whether fc->ref is
nonzero is used. Before this patch, fc->ref was set to NULL in
frame_context_setup. The issue is that, by the time frame_context_setup
is called, falliable functions (namely slices_realloc and
ff_vvc_decode_frame_ps) have already been called. Therefore, there
could arise a situation in which the fc->ref test of decode_nal_units'
fail: block is performed while fc->ref has an invalid value. This seems
to be particularly prevalent in situations where the FrameContexts are
being reused. The patch resolves the issue by moving the assignment of
fc->ref to NULL to the very top of decode_nal_units, before any falliable
functions are called.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Parameter sets may be coded in the packet before an IRAP (as is the case for
the hev1 ISO-BMFF brand), and they should have priority as they may override
the extradata ones.
As such, prepend the extradata PS NALUs to the packet PS NALUs if they are
present before an IRAP, instead of prepending them to the IRAP slice.
Should fix ticket #11458.
Signed-off-by: James Almer <jamrial@gmail.com>
On a Zen 5, on Ubuntu 24.04 (with CLOCKS_PER_SEC 1000000), the
value of clock() in this loop increments by 0 most of the time,
and when it does increment, it usually increments by 1 compared
to the previous round.
Due to the "last_t + 2*last_td + (CLOCKS_PER_SEC > 1000) >= t"
expression, we only manage to take one step forward in this loop
(incrementing i) if clock() increments by 2, while it incremented
by 0 in the previous iteration (last_td).
This is similar to the change done in
c4152fc42e, to speed it up on
systems with very small CLOCKS_PER_SEC. However in this case,
CLOCKS_PER_SEC is still very large, but the machine is fast enough
to hit every clock increment repeatedly.
For this case, use the number of repetitions of each timer value
as entropy source; require a change in the number of repetitions
in order to proceed to the next buffer index.
This helps the fate-random-seed test to actually terminate within
a reasonable time on such a system (where it previously could hang,
running for many minutes).
Signed-off-by: Martin Storsjö <martin@martin.st>
t_info.keyframe_granule_shift is set to the library default of 6, which is ok
for gop sizes up to 63. Since there's apparently no way to query the updated
value after having forced a gop value with TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE,
calculate it manually instead.
Fixes ticket #11454.
Signed-off-by: James Almer <jamrial@gmail.com>
This also ensures the layout set during the indev init is used instead of the
blank one in st->codecpar.
Signed-off-by: James Almer <jamrial@gmail.com>
Some files keep extra metadata such as 'name' fields within udta, and
it is useful for Wine to access them with the "export_all" option so
they can then be exposed to Windows applications.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
4b77a0a681 added a new consumer of ff_scale_adjust_dimensions
which was recently modified to allow for square pixel output.
This commit extends the new option to vpp_amf, and unbreaks the building
of vf_amf_common.c
This change removes one extra floating point operation and simplifies
load operations at the beginning of the loop by using dedicated register
for each of the 5 pointers and interleaving it with calculations. The
first case seems to be a bit slower, but the performance increase is
substantial in the other two.
A78 before:
postfilter_15_neon: 1684.8 ( 4.23x)
postfilter_512_neon: 1395.5 ( 5.10x)
postfilter_1022_neon: 1357.0 ( 5.25x)
After:
postfilter_15_neon: 1742.2 ( 4.09x)
postfilter_512_neon: 1169.8 ( 6.09x)
postfilter_1022_neon: 1160.0 ( 6.12x)
A72 before:
postfilter_15_neon: 3144.8 ( 2.39x)
postfilter_512_neon: 3141.2 ( 2.39x)
postfilter_1022_neon: 3230.0 ( 2.33x)
After:
postfilter_15_neon: 2847.8 ( 2.64x)
postfilter_512_neon: 2877.8 ( 2.61x)
postfilter_1022_neon: 2837.2 ( 2.65x)
x13s before:
postfilter_15_neon: 1615.4 ( 2.61x)
postfilter_512_neon: 963.1 ( 4.39x)
postfilter_1022_neon: 963.6 ( 4.39x)
After:
postfilter_15_neon: 1749.6 ( 2.41x)
postfilter_512_neon: 707.1 ( 5.97x)
postfilter_1022_neon: 706.1 ( 5.99x)
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, we read elements from ff_aac_pow34sf_tab; however
that table is initialized to zero; one needs to call
ff_aac_float_common_init() to make sure that the table is
initialized.
However, given the range of the input values, a large number of
entries in ff_aac_pow34sf_tab would give results outside of the
range for signed 32 bit integers. As the largest aac_cb_maxval
entry is 16, it seems more reasonable to produce values within
an order of mangitude of that value.
(When hitting INT_MIN, implementations may end up with different
results depending on whether the value is negated as a float or
as an int. This corner case is irrelevant in practice as this
is way outside of the expected value range here.)
Coincidentally, this fixes linking checkasm with Apple's older
linker. (In Xcode 15, Apple switched to a new linker. The one in
older toolchains seems to have a bug where it won't figure out to
load object files from a static library, if the only symbol
referenced in the object file is a "common" symbol, i.e. one for
a zero-initialized variable. This issue can also be reproduced with
newer Apple toolchains by passing -Wl,-ld_classic to the linker.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, we would do OR with the sign bit, forcing the output
to a negative value, while we want to negate it, by inverting the
sign bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
For anamorphic videos, enabling this option leads to adjustment of
output dimensions to obtain square pixels when the user requests
proportional scaling through either of the w/h expressions or
force_original_aspect_ratio.
Output SAR is always reset to 1.
Option added to scale, scale_cuda, scale_npp & scale_vaapi.
libplacebo already has a similar option with different semantics,
scale_vt and scale_vulkan don't implement force_oar, so for these
three filters, I've made minimal changes needed to not break building
or change output.
IVTV, a Linux driver for TV tuners, and V4L2 utilize
a coding named after IVTV to carry sliced VBI data
in MPEG streams produced by tuner cards with
VBI capture capability and an MPEG-2 encoder SoC.
IVTV or V4L2 driver will transport the coded data into a
MPEG-PS private stream ("IVTV") that can be captured
from the card alongside the video/audio.
The data could include:
EIA-608, Teletext, WSS (PAL widescreen signaling),
or VPS (PAL VCR signaling).
Signed-off-by: Marth64 <marth64@proxyid.net>
Currently, if there is a hardware encode failure, the numeric
error code will be printed making it somewhat hard to get to
the root cause of the issue. Print the readable message generated
by av_err2str() instead.
Signed-off-by: Marth64 <marth64@proxyid.net>
If a malformed chunk like sBIT appears but otherwise the stream
is still parseable, we should print a warning and skip it rather
than failing with an error.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Using audio_substream_id for AVStream ids is not ideal give that in containers
like mp4, the IAMF structure is opaque to the outside and other streams may
share such id values.
Signed-off-by: James Almer <jamrial@gmail.com>
Currently when a Unix Domain Socket is used as input there is a loss
of data when data is consumed from the stream. Setting is_streamed to
true fixes this, since the unix domain socket is now treated like a
consumable stream.
Fixes: #9346
Signed-off-by: dank074 <torresefrain10@gmail.com>
Reviewed-by: Leo Izen <leo.izen@gmail.com>
amf_device_create() calls amf_device_uninit() on errors, but if things
were not initialized it will null deref amf_ctx->factory.
Fixes: https://github.com/mpv-player/mpv/issues/15814
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Fixes: 392672068/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-6232335892152320
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allow mp4 with all mpegts extensions
Fixes: Ticket11435
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fix ensures that the loop stops early on EOF. The issue occurs
because mov_read_infe() performs a version check and skips unsupported
versions. The problem is that seeking within the stream clears the EOF
flag, causing avio_feof() to not function as expected. This is resolved
by moving the EOF check after reading the size and type, ensuring the
EOF flag is set when necessary.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Here is a proposed patch for portability of doc/t2h.pm for GNU Texinfo
7.1 and 7.1.90 (7.2 pretest). I tested against 7.1 and 7.1.90 (7.2
pretest). There is a difference in the headings compared to the website
version, maybe related to FA_ICONS not being set the same, but the
result seems correct.
I also renamed $element to $output_unit in ffmpeg_heading_command as in
new equivalent makeinfo/texi2any code the $element variable is the
$command variable in ffmpeg_heading_command, which is very confusing. I
left as is the $command variable to have a patch easier to read, but it
could make sense to rename $command as $element later on.
The patch could also have effects with Texinfo 7.0, since some of the
changes are for that version, but that probably never show up because it
is for situations that may not exist in ffmpeg manuals (for example
@node without sectioning command), or because the code is robust to some
missing information (case of $heading_level in ffmpeg_heading_command
that was not set, as far as I can tell).
Signed-off-by: James Almer <jamrial@gmail.com>
Free AVOption in drawtext private context when freeing old copy of drawtext
private context during processing of "reinit" runtime command.
Signed-off-by: Steven Zhou <steven.zhou@netint.ca>
Signed-off-by: James Almer <jamrial@gmail.com>
The ref input may have its frame rate unset, which would then lead to
SIGFPE. So fall back to the main link frame rate. If that too is unset,
default to 0.
Related to #11428
Fixes 7187eadf8c
The issue is that while avctx->pix_fmt is synchronized between
threads, f->pix_fmt was not.
Fixes fate-vsynth1-ffv1-2pass10 with THREADS=2.
The spec seems to allow these to be negative
Fixes: left shift of negative value -15
Fixes: 392687035/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-6559804532785152
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
Adds hwcontext_amf, enabling a shared AMF context for encoders,
decoders, and AMF-based filters, without copy to the host memory.
Code also was tested in HandBrake.
Benefits:
- Optimizations for direct video memory access from CPU
- Significant performance boost in full AMF pipelines with filters
- Integration of GPU filters like VPP, Super Resolution, and
Compression Artefact Removal(in future plans)
- VCN power management control for decoders.
- Ability to specify which VCN instance to use for decoding
(like for encoder)
- AMD will soon introduce full AMF API for multimedia accelerator MA35D
- With AMF API, integration will be much easier:
GPU and the accelerator will have the same API
- including encoder, decoder, scaler, color converter,
Windows and Linux.
Learn more:
https://www.amd.com/en/products/accelerators/alveo/ma35d.html
Changes by versions:
v2: Header file cleanup.
v3: Removed an unnecessary class.
v4: code cleanup and improved error handling
v5: Fixes related to HandBrake integration.
v6: Sequential filters error and memory leak have been fixed.
Otherwise all frames can be dropped after seek without the
output_corrupt/showall flags.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
This fixes timeout issues and seems like it was intended
since the line emits an error log.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Marth64 <marth64@proxyid.net>
The format is used by at least Dish Network, but is not
defined in any DVB standard, so remove references to DVB.
This is a simple rename, no functional change.
Signed-off-by: Marth64 <marth64@proxyid.net>
AV1 uses a vastly different range than what the global options permit,
and also for the other codecs the range of the global options is at
least misaligned.
Fixes#11365
This commit extends the support for Temporal Filtering in NVENC for
AV1 and H.264 codecs. For natural videos with noise, NVENC temporal
filtering improves video coding efficiency by 4-5%.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for Ultra High Quality mode for AV1 on
NVIDIA GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 encoding for HEVC and H.264 on
NVIDIA Blackwell GPUs. Additionally, it supports 10-bit encoding
for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 decoding for HEVC and H.264 on
NVIDIA Blackwell GPUs for cuviddec. Moreover, it supports 10-bit
decoding for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 decoding for HEVC and H.264 on
NVIDIA Blackwell GPUs. Additionally, it supports 10-bit decoding
for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 pixel formats, namely NV16 and
P216 for NVIDIA GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
ff_w1111 and ff_bgr2(Y|UV)Offset are only used there
(and only on x86-32 since caaec2ea95).
Also make them static.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Missed in ffc4fd3cc2, which after
e78173557d broke setting channel count.
Should fix ticket #11434.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
If there's a very large ISOBMFF box that needs to be skipped, it can
cause an overflow for ctx->skip. There's already a safeguard to return
quickly if ctx->skip > bufsize, so changing ctx->skip to int64_t will
allow this to happen even if ctx->skip would overflow a signed int.
Several other members are also changed to int64_t to avoid this problem
in other possible scenarios.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Fixes: clusterfuzz-testcase-minimized-fuzzer_loadfile-6085331937460224
`POS(1,` and `POS(2,` may trigger UBSAN report:
"runtime error: applying non-zero offset 304 to null pointer"
Looks like values are not used without `chroma_format_idc`,
so maybe there is no other issues than the UB.
Can't reproduce with "fate".
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 7803923888585309955 - -3407677434275325337 cannot be represented in type 'int64_t' (aka 'long')
Fixes: 377736723/clusterfuzz-testcase-minimized-media_pipeline_integration_fuzzer-5052449500889088
Signed-off-by: James Almer <jamrial@gmail.com>
This function can return AVERROR_BUG in theory if something
went wrong, but so can the caller, so we should propagate that
error message upward in that case.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When running the cleanup in rtmp_close on failures in rtmp_open,
we can in rare cases end up using rt->playpath, assuming that it
is still set.
The crash could happen if we hit the fail codepath in rtmp_open
while publishing (rt->is_input == 0) with rt->state set to
a value > STATE_FCPUBLISH.
This would normally not happen while publishing; either we have
an error (and rt->state <= STATE_FCPUBLISH) or we reach
rt->state = STATE_PUBLISHING, and then we also return successfully
from rtmp_open.
The unexpected combination of states could happen if the server
responds with e.g. "NetStream.Play.Stop" while expecting
"NetStream.Publish.Start"; this sets rt->state to STATE_STOPPED,
which also fulfills the condition "> STATE_FCPUBLISH".
We don't need to free the rt->playpath/tcurl/flashver strings here;
they're handled via AVOption, and thus are freed automatically when
the protocol instance is freed (that's why they aren't freed
manually within the rtmp_close function either).
We also don't need to free the AVDictionary with options; it's
owned by the caller.
A smaller fix would be to just call rtmp_close before freeing
the strings and dictionary, but as we don't need to free them
at all, let's remove that redundant code.
Signed-off-by: Martin Storsjö <martin@martin.st>
Traditionally, macOS has shipped an old version of rsync that lacked
support for this option, hence this check (added in
a8b3f0c5cf).
However, in macOS 15.x, Apple have switched to providing rsync as a
different tool, openrsync. The version of openrsync in at least
macOS 15.2 does include "[--contimeout]" (note the lack of "=" after
the option), in the output of "rsync --help", but when used, the tool
errors out with "rsync: --contimeout=60: unknown option". So apparently
the tool erroenously lists the option as supported, while it really
isn't.
The original rsync tool (with a new enough version) prints
"--contimeout=SECONDS" in the output of "rsync --help".
It is unclear which version of openrsync Apple are shipping; the latest
upstream openrsync from OpenBSD does support the option and includes
"[--contimeout=seconds]" in the output of "--help", and older versions
don't seem to include the option as listed at all.
Therefore, check for "--conntimeout=" with the "=", this should
properly detect both new enough rsync and openrsync.
This fixes running "fate-rsync" on macOS 15.x.
Signed-off-by: Martin Storsjö <martin@martin.st>
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
workflows, our docs and across the web is `PTS-STARTPTS` or others of the
general form `PTS+constant` which preserves the input framerate.
Default value is false, which restores old behaviour.
Fixes#11428
Global side data as exported by a decoder may no longer apply if a filter in
the chain altered the frames in some form, like changing color, dimensions,
or channel layout information.
After this change, any such changes in side data will be taken into account by
the encoder futher in the process.
Signed-off-by: James Almer <jamrial@gmail.com>
This blocks disallowed extensions from probing
It also requires all available segments to have matching extensions to the format
mpegts is treated independent of the extension
It is recommended to set the whitelists correctly
instead of depending on extensions, but this should help a bit,
and this is easier to backport
Fixes: CVE-2023-6602 II. HLS Force TTY Demuxer
Fixes: CVE-2023-6602 IV. HLS XBIN Demuxer DoS Amplification
The other parts of CVE-2023-6602 have been fixed by prior commits
Found-by: Harvey Phillips of Amazon Element55 (element55)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
codec37 operates on 2 buffers, which must be considered private to
the codec and must therefore not be changed by subsequent FOBJs.
Let codec37 therefore operate on frm1/2 instead of frm0/2, but copy
the decoded image to frm0 where other codecs operate on.
Fixes artifacts encountered in Full Throttle "dazed.san" and also
in a lot of Rebel Assault II gameplay videos: these videos consist of
frames with an initial codec37 FOBJ image to set the stage, and
optional codec1-23 FOBJs overlaid on top of that image.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was disabled in da60b99a88 and then
accidentally re-enabled in 172b0e2e88.
The code in question was never properly adapted for litte-endian mode.
refs: trac/10955
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The comments supposed to track the possible value of the qmat and qmat16
matrices, but they were not updated properly in the long history of the
mpegvideo encoder. Also they wrongly assumed the usage of built-in quantizer
matrices and linear quantization.
Signed-off-by: Marton Balint <cus@passwd.hu>
Values in csp, prim, trc, etc, are irrelevant if there's no conversion needed.
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: Use of uninitialized memory
Fixes: 71444/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5448597561212928
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -277109688 * 8 cannot be represented in type 'int'
Fixes: 376118159/clusterfuzz-testcase-minimized-ffmpeg_SWR_fuzzer-5884436320681984
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 memory
Fixes: 375286238/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-6352546854141952
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 memory
Fixes: 377642312/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4554550985424896
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 uninitilaized data
Fixes: 385167047/clusterfuzz-testcase-minimized-ffmpeg_dem_IPMOVIE_fuzzer-5941477505564672
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_parse_mpeg2_descriptor() reads over what is initialized
Fixes: use of uninitialized memory
Fixes: 383825645/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-5144130618982400
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 data
Fixes: 383825642/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5380168801124352
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It performs better when its less buggy
Compression changes for rgb_scanline_half_piz_dw_t08 (using float16 with remaping) from
56086 byte to 34371
(with a single slice its 28122 byte)
prior remap it was 188186 bytes
ACES_OT_VWG_SampleFrames/ACES_OT_VWG_SampleFrames improves too but only by a fraction of a percent
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't export a matrix encoding side data when there's none signaled.
And if downmixing was handled by the decoder itself, then the downmix info does
not apply to the frame.
Signed-off-by: James Almer <jamrial@gmail.com>
With this, if the eac3 dependent frame doesn't have coded downmix values when
parsed by ff_eac3_parse_header(), it will inherit the coded ones from the core
ac3 frame instead of ignoring them.
Signed-off-by: James Almer <jamrial@gmail.com>
A flag in the codec header determines whether opcodes 0xfd/0xfe
are to be treated as special or not. The current code has 2
implementations of the same decoding scheme, with one treating
the 2 opcodes as special, the other not.
Collapse them into a single implementation and treat these opcode
according to the flag.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
RLE-compressed stream of motion vector indices and a special opcode
to fill a block with data from the source stream.
It is used in the LucasArts "Full Throttle" blink*.san animations.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Fixes: Ticket5753
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
packet_buffer is used in mux.c, and if a muxing process fails at a point where
packets remained in said queue, they will leak.
Fixes ticket #11419
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: applying zero offset to null pointer
partly Fixes: verysmall.flv
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This may be needed for floats
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: undefined NULL pointer use
Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-6363211175493632
This performs equivalent sanity checks as are done in mov_read_trak()
before mov_build_index()
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The reason for the failure is that the function yuv2rgb_1_c_template was modified
in 095f8038fa. The corresponding functional test
was added in c601bb8df5. The code on loongarch was
not updated in a timely manner, resulting in the error.
Signed-off-by: yuanhecai <yuanhecai@loongson.cn>
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
if sc->tts_count is 0, this condition will wrap around to UINT_MAX and the
code will try to dereference a NULL pointer.
Fixes ticket #11417
Signed-off-by: James Almer <jamrial@gmail.com>
close input file if open output fail/read errors.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
lavapipe recently added support for external_semaphore_fd, but only for syncfiles,
not for opaque file descriptors.
The code is written to allow using syncfiles later on.
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12422
This filter uses the AVBuffer API to allocate buffers that are never
shared at all and frees them via av_freep() (actually, it passes
pointers to AVBufferRefs to av_freep, so that only the AVBuffer
structures are freed at all (because AVBufferRef has a AVBuffer* as its
first member), not the AVBufferRef and not the underlying buffers;
and due to a wrong check the AVBuffers corresponding
to buf_org[c] with c>0 were never freed at all). This is a violation
of the AVBuffer API and causes a memleak. Fix this by avoiding the
AVBuffer API altogether.
(The FATE tests don't catch this, because they use piping to awk,
so that the error code from ffmpeg is ignored.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch is analogous to 20f9727018:
It hides the internal part of AVFilter by adding a new internal
structure FFFilter (declared in filters.h) that has an AVFilter
as its first member; the internal part of AVFilter is moved to
this new structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 8a29b4e38d
(this test depends on lcms2 and is therefore disabled by default).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Symbols with the sws_* prefix are exported.
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The criteria for slice structure validity is similar to that of
subpicture structure validity that we saw not too long ago [1].
The relationship between tiles and slices must satisfy the following
properties:
* Exhaustivity. All tiles in a picture must belong to a slice. The
tiles cover the picture, so this implies the slices must cover the
picture.
* Mutual exclusivity. No tile may belong to more than one slice, i.e.
slices may not overlap.
In most cases these properties are guaranteed by the syntax. There is
one noticable exception however: when pps_tile_idx_delta_present_flag is
equal to one, each slice is associated with a syntax element
pps_tile_idx_delta_val[i] which "specifies the difference between the
tile index of the tile containing the first CTU in the ( i + 1 )-th
rectangular slice and the tile index of the tile containing the first
CTU in the i-th rectangular slice" [2]. When these syntax elements are
present, the i-th slice can begin anywhere and the usual guarantees
provided by the syntax are lost.
The patch detects slice structures which violate either of the two
properties above, and are therefore invalid, while building the
slice map. Should the slice map be determined to be invalid, an
AVERROR_INVALIDDATA is returned. This prevents issues including
segmentation faults when trying to decode, invalid bitstreams.
[1]: https://ffmpeg.org//pipermail/ffmpeg-devel/2024-October/334470.html
[2]: H.266 (V3) Section 7.4.3.5, Picture parameter set RBSP semantics
Signed-off-by: Frank Plowman <post@frankplowman.com>
A minimal DNG header is added to each LJ92 compressed frame, allowing
thme to be decoded by the TIFF decoder. The TIFF decoder is responsible
for setting up the MJPEG decoder, signalling the correct s->bayer flag,
and setting pix_fmt.
The LJ92 compressed frames can be muxed out to DNG files, and manipulated
in DNG software. Tested with darktable and rawtherapee.
Contributor: South East <8billion.people@gmail.com>
It should be more clear what this flag is indicating with a more
verbose comment documenting it.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Marth64 <marth64@proxyid.net>
This was previously adjusted by me in 6b3f9c2e92.
Unfortunately, I traded one integer overflow bug for
another.
Currently, NTP timestamps that exceed INT64_MAX
(~Jan 20, 1968) will cause an overflow when passed
to av_rescale.
This patch replaces av_rescale, which operates on
int64_t, with ff_parse_ntp_time, which operates on
uint64_t. This will give the correct values for
timestamps back around the NTP epoch and present day
timestamps.
Fixes ticket #11388.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: 377965565/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4504434689769472
Fixes: out of array access
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: index 5 out of bounds for type 'uint8_t [5]'
Fixes: 377748135/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5167109774049280
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: -nan is outside the range of representable values of type 'int'
Fixes: 377072730/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6545416570601472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2 * -4962931467012268000 cannot be represented in type 'long'
Fixes: 376496313/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4921469185884160
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1239596184 + 2119376059 cannot be represented in type 'int'
Fixes: 376136844/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6581164455821312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1082982400 + -1195645138 cannot be represented in type 'int'
Fixes: 376136843/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4791844321427456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: crash
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Found-by: Elias Myllymäki <elias.myllymaki04p@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
In mpeg_decode_a53_cc() only the A/53 part 4 CC data ("GA94") is saved between
frames. The other formats incorrectly created a larger buffer than they use
since a705bcd763 because they did not append to
the previous data.
The a53_buf_ref is added to the frame in mpeg_field_start() which will only be
called in decode_chunks() if not all of the picture data slices are skipped.
For these formats, utilize the data added to the buffer in case frames are skipped
(concatenating the CC data until a frame can be exported), in a similar fashion to
the A/53 part 4 logic.
Reviewed-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Marth64 <marth64@proxyid.net>
After support was added for DVB 0502 Closed Caption coding,
the cc_format option's range was never updated so user
cannot select this coding as a forced formatting choice.
Fix the range of the option by ending it with the new coding type.
Signed-off-by: Marth64 <marth64@proxyid.net>
Fix the incorrect capitalization of the project name in a comment.
The project is named FFmpeg, not FFMpeg.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This will ensure any future goto leave that may be added doesn't accidentally forget to
set ret to some proper value.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: James Almer <jamrial@gmail.com>
When muxing to FLV/RTMP a MP3 track with an ID greater than zero,
enhanced RTMP has to be used, and a sequence start should preceed track
data.
This is already implemented (see line 823 of flvenc.c) but the code is
never reached due to a too-strict condition before it. This patch fixes
the issue.
Signed-off-by: Alessandro Ros <aler9.dev@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The scale_vulkan filter initializes the shader once, with the crop
region set by the original frame. However, subsequent frames may
specify a different crop region than the first frame. This change
updates the cropping to match the behavior present on the other
hardware frame scale filters.
The scale filter should also allow negative values
that respect aspect ratio, similar to other scale filters.
Signed-off-by: Koushik Dutta <koushd@gmail.com>
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
When the current subpicture has sps_subpic_treated_as_pic_flag equal to
1, motion vectors are cropped such that they cannot point to other
subpictures. This was accounted for in the prediction logic, but not
in pred_get_y, which is used by the scheduling logic to determine which
parts of the reference pictures must have been reconstructed before
inter prediction of a subsequent frame may begin. Consequently, where a
motion vector pointed to a location significantly above the current
subpicture, there was the possibility of a race condition. Patch fixes
this by cropping the motion vector to the current subpicture in
pred_get_y.
Signed-off-by: Frank Plowman <post@frankplowman.com>
When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set indexes alf->ctb_cc_idc are being read uninitialized during ALF filtering.
This change initializes alf->ctb_cc_idc whenever ALF is enabled.
Ref. https://trac.ffmpeg.org/ticket/11325
Indexes in tile_grid->offsets were fixed in the previous commit, but just in case,
make sure to not overread the streams array.
Signed-off-by: James Almer <jamrial@gmail.com>
The amount of tiles does not necessarely need to match the amount of streams referenced
in the grid, as there could be duplicates.
Don't silently ignore EEXIST return codes from avformat_stream_group_add_stream() and
instead store the index of the duplicate stream.
Signed-off-by: James Almer <jamrial@gmail.com>
References https://trac.ffmpeg.org/ticket/11387
Defining anchors is needed, even when a filename with the labels is set.
The issue was identified when using yolov4-tiny model using openvino.
More information about how to reproduce the bug can be found on the trac
issue referenced by this commit.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
A new codec ID has been added to avcodec for animated JPEG XL, so
we should use that in the animated JPEG XL demuxer.
Reviewed-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
libjxl supports animated encoding, so we add a wrapper to the
library using the receive_packet callback method.
This code was based largely on a patch sent by Zsolt Vadász,
although it was updated to use more recent coding practices
and many of the leaks and issues were fixed.
Reviewed-by: Marth64 <marth64@proxyid.net>
Co-authored-by: Zsolt Vadász <zsolt_vadasz@protonmail.com>
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The arm/aarch64 horizontal filter reads one additional pixel beyond what
the filter uses. This can become an issue if the application does not
allocate larger buffers than what's required for the pixel data. If the
motion vector points to the bottom right edge of the picture this
becomes a read buffer overflow. This triggers segfaults in Firefox for
video resolutions which result in a page aligned picture size like
1280x640.
Prevent this by using emulated edge in this case.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
This mirrors the aarch64 change.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
Under these conditions like seen by Firefox a read beyond the end of the
buffer results in a segfault.
After the over-read is reduced to a single pixel it's reasonable to use
VP9's emulated edge motion compensation for this.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Layouts with both pairs (7.1, 7.1.2, etc) in IAMF that follow the definition in
ITU-R BS.2051-3 for Systems I and J also follow its ordering. This means side
comes before back, which is the inverse of how it's defined in AVChannel.
To workaround this without having to use custom order channel layouts, swap the
stream ids in the input IAMF structure, so packets for one are mapped to the
other.
Signed-off-by: James Almer <jamrial@gmail.com>
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:
1235840392
2. Build failing without quotes:
1236047237
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>
This patch corrects a C operator precedence issue in fftools/ffmpeg_opt.c
where the abs_start_seek calculation did not yield the expected result
due to incorrect placement of parentheses.
header is previously declared as an int argument then
shadowed in the scope of the loop as a AV1RawOBUHeader.
Signed-off-by: Marth64 <marth64@proxyid.net>
Fixes: signed integer overflow: 529008646 * 8 cannot be represented in type 'int'
Fixes: 383379145/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-6674045107503104
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -3483479120376300096 - 7442323944145700864 cannot be represented in type 'long'
Fixes: 383187489/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4561470580391936
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: NULL ptr use
Fixes: 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
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: 378634700/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5008344043028480
Fixes: assertion failure
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>
This way the (slow) allocation of an image is done after various additional checks
Fixes: Timeout
Fixes: 379418967/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ESCAPE130_fuzzer-6507383574036480
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Switches to av_frame_side_data_remove_by_props(), covering a number of
cases that we previously ignored. Additionally, stop stripping metadata
when merely changing colorspace or color range, since these do not
affect the actual color volume of the image data, only the encoding.
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matching *all*
properties, but I think this is sufficiently useless in practise to not warrant
inclusion in the API.
Many filters modify certain aspects of frame data, e.g. through resizing
(vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
possibly others.
When this happens, we should strip all frame side data that will no
longer be correct/relevant after the operation. For example, changing
the image size should invalidate AV_FRAME_DATA_PANSCAN because the crop
window (given in pixels) no longer corresponds to the actual image size.
For another example, tone-mapping filters (e.g. from HDR to SDR) should
strip all of the dynamic HDR related metadata.
Since there are a lot of different side data types that are affected by such
operations, it makes sense to establish this information in a common, easily
accessible way. The existing side data properties enum is a perfect fit for
this.
While this one was technically supported on account of the generic options
code allowing "none" as a valid alias for 0, not having it listed here meant
it never showed up in e.g. the -h output, and is also inconsistent with other
places in the code that generally add an explicit alias with appropriate
documentation. Reduces user confusion at negligible cost.
Fixes: #9192
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This leverages the previously introduced color management subsystem in order
to adapt between transfer functions and color spaces, as well as for HDR tone
mapping.
Take special care to handle grayscale formats without a colorspace
gracefully.
This is a lightweight wrapper around the underlying color management system,
whose job it is merely to manage the 3DLUT state and apply them to the frame
data. This is where we might add platform-specific optimizations in the future.
I also plan on adding support for more pixel formats in the future. In
particular, we could support YUV or XYZ input formats directly using only
negligible additional code in the 3DLUT setup functions. This would eliminate
the major source of slowdown, which is currently the roundtrip to RGBA64.
The underlying color mapping logic was ported as straightforwardly as possible
from libplacebo, although the API and glue code has been very heavily
refactored / rewritten. In particular, the generalization of gamut mapping
methods is replaced by a single ICC intent selection, and constants have been
hard-coded.
To minimize the amount of overall operations, this gamut mapping LUT now embeds
a direct end-to-end transformation to the output color space; something that
libplacebo does in shaders, but which is prohibitively expensive in software.
In order to preserve compatibility with dynamic tone mapping without severely
regressing performance, we add the ability to generate a pair of "split" LUTS,
one for encoding the input and output to the perceptual color space, and a
third to embed the tone mapping operation. Additionally, this intermediate
space could be used for additional subjective effect (e.g. changing
saturation or brightness).
The big downside of the new approach is that generating a static color mapping
LUT is now fairly slow, as the chromaticity lobe peaks have to be recomputed
for every single RGB value, since correlated RGB colors are not necessarily
aligned in ICh space. Generating a split 3DLUT significantly alleviates this
problem because the expensive step is done as part of the IPT input LUT, which
can share the same hue peak calculation at least for all input intensities.
This setting can be used to infuence the type of tone and gamut mapping used
internally when color space conversions are required. As discussed at VDD'24,
the default was set to relative colorimetric clipping, which is approximately
associative, surjective and idempotent. As such, it roundtrips well, although
it is strictly speaking not associative on out-of-gamut colors.
Swscale currently handles XYZ by embedding a forced conversion to
BT.709 RGB with a hardcoded matrix. This is not ideal, but to preserve the
status quo and avoid any unexpected changes in behavior, this patch merely
fixes the inferred primaries tag to match the reality.
In the future, I would like to handle XYZ properly, via direct conversion
to the target colorspace (or possibly simply by using a more fitting
RGB intermediate like SMPTE428), but for now just keep the status quo.
Logic is loosely on equivalent decisions in libplacebo. The basic idea is to try
and be a bit conservative by treating AVCOL_*_UNSPECIFIED as a no-op, unless the
other primaries set are non-standard / wide-gamut or HDR. This helps avoid
unintended or unexpected colorspace conversions, while forcing it in cases where
we are almost certain it is needed. The major departure from libplacebo semantics
is that we no default to a 1000:1 contrast ration for SDR displays, instead modelling
them as idealized devices with an infinite contrast ratio.
In either case, setting SWS_STRICT overrides this behavior in favor of always
requiring explicit colorspace metadata.
Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the
provided MaxRGB/MaxSCL values to infer what the actual luminance would have
been, which HDR10+ metadata does not provide directly. It's worth pointing out
that this gives us an *upper* bound on the true maximum luminance, so any
error in the estimation cannot result in clipping.
Only add the condensed values that we actually care about. Group them into
a new struct to make it easier to discard or replace this metadata.
Define a special comparison function that does not choke on undefined/unknown
metadata.
As fixed in the previous commit, this enables semipacked range and
bit depth conversions. Previously these would go through the general
purpose path.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This fixes multiple bugs with semiplanar formats like NV12. Not only do these
false positive the grayscale format checks (because dst[2] in NULL), but they
also copied an incorrect number of pixels.
Fixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc.
Fixes: #11239
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
We should at least bias towards the nearest integer, instead of always
rounding down, when not dithering. This is a bit more correct.
The FATE changes are only in the cases where sws_dither was explicitly set
to "none", which is exactly as expected.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This code only checks hcScale. In practice this is not an issue because
the function pointers should always be identical to hyScale for the same
filter size.
Add an assertion just to make sure this assumption never regresses.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
We recently introduced a public field which was a superset
of the queue context we used to have.
Switch to using it entirely.
This also allows us to get rid of the NIH function which was
valid only for video queues.
This code was simply incorrect through and through. It did not
protect what actually has to be protected in a multi-threaded setup.
Perhaps it was used to silence threading errors?
Either way, remove it, and document the correct way to use execution
pools in a threaded environment.
Originally, the decoder had a single execution pool, with one
execution context per thread. Execution pools were always intended
to be thread-safe, as long as there were enough execution contexts
in the pool to satisfy all threads.
Due to synchronization issues, the threading part was removed at some
point, and, for decoding, each thread had its own execution pool.
Having a single execution pool per context is hacky, not to mention
wasteful.
Most importantly, we *cannot* associate single shaders across multiple
execution pools for a single application. This means that we cannot
use shaders to either apply film grain, or use this framework for
software-defined decoders.
The recent commits added threading capabilities back to the execution
pool, and the number of contexts in each pool was increased. This was
done with the assumption that the execution pool was singular, which
it was not. This led to increased parallelism and number of frames
in flight, which is taxing on memory.
This commit finally restores proper threading behaviour.
The validation layer has isses that are reported and addressed in the
earlier commit.
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the size of next_prev based on the
value of ref_l0 when the GOP structure is initialized.
[1] https://github.com/intel/cartwheel-ffmpeg/issues/278
v2: fix indentation issues
These functions were divided into two special cases; one assuming that
uvalpha == 0, and the other assuming that uvalpha == 2048. This worked fine
for simple 2x chroma upscaling but broke for e.g. yuv410p, non-centered chroma,
or other special cases that involved non-aligned chroma filters.
Fix it by instead dividing this check into two cases, a uvalpha==0 fast path
and a uvalpha>0 general path. Instead of (A+B)/2 the general path now multiplies
in the true uvalpha weight.
I tried preserving the old fast path for the case of uvalpha == 2048, but this
was significantly slower in practise versus having just one general path.
However, we still need a uvalpha == 0 path for the unscaled case.
Fixes: ticket #5083
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
As per section 3.11.1 of the IAMF spec, the sample rate used in Codec Config
for Opus shall be 48kHz, regardless of the original sample rate used during
encoding.
Signed-off-by: James Almer <jamrial@gmail.com>
This option, which is also available on other FFmpeg hardware encoders,
allows the user to trade throughput for reduced output latency. This is
useful for ultra low latency applications like game streaming.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Since its introduction, this function has claimed to return 0 on success, yet
never actually did so (until the introduction of the new graph based API). It
always returned the number of scaled lines, and continues to do so.
To avoid confusion, but also avoid regressing possible clients that relied on
the existing semantics, simply update the documentation to reflect the actual
behavior. Remain ambiguous about the exact interpretation of the return value
on account of the unfortunate difference in behavior between the legacy and
new scaling APIs.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This logic was inverted, but || was not replaced by &&.
Fixes: ed5dd67562
Fixes: ticket #11353
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
It's currently actually not used in MSVC builds, since
6e49b86996.
Older versions of MSVC (or, in particular, older versions of UCRT)
don't have stdalign.h; it's available since WinSDK 10.0.20348.0;
such a new enough version has been installed by default only since
MSVC 2022 17.4 and newer.
With this change, ffmpeg can still be built with MSVC 2019 16.8
(v19.28).
Signed-off-by: Martin Storsjö <martin@martin.st>
Explicitly use ldur for unaligned offsets; newer versions of
armasm64 implicitly convert ldr to ldur as necessary, but older
versions require it explicitly written out.
This fixes these build errors:
ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2039) :
error A2518: operand 2: Memory offset must be aligned
ldr s5, [x1, #1]
ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2250) :
error A2518: operand 2: Memory offset must be aligned
ldr d7, [x1, #2]
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 367840
Signed-off-by: Peng Bin <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 479612
The mismatch between neon and C functions can also be reproduced using the following bitstream and command line.
wget https://streams.videolan.org/ffmpeg/incoming/intra8x8pred_10bit.264
./ffmpeg -cpuflags 0 -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
In input.c and output.c and many other places, swscale follows the rule of using
15-bit intermediate if output bpc is <= 8, and 19-bit (inside int32_t)
intermediate otherwise. See e.g. the comments on hyScale() on
swscale_internal.h. These are also the coefficients that yuv2gbrpf32_full_X_c()
is using.
In contrast to this, the plane init code in slice.c (function fill_ones) is
assuming that we use 35-bit intermediates (inside 64-bit integers) for this
case, seemingly added by commit b4967fc71c with
no further justification.
This causes a mismatch whenever the implicitly initialized plane contents leak
out to the output, e.g. when converting from grayscale to RGB.
Fixes: ticket #10716
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
pthread_t is currently defined as a struct, which gets placed into
caller's memory and filled by pthread_create() (which accepts a
pthread_t*).
The problem with this approach is that pthread_join() accepts pthread_t
itself rather than a pointer to it, so it gets a _copy_ of this
structure. This causes non-deterministic failures of pthread_join() to
produce the correct return value - depending on whether the thread
already finished before pthread_join() is called (and thus the copy
contains the correct value), or not (then it contains 0).
Change the definition of pthread_t into a pointer to a struct, that gets
malloced by pthread_create() and freed by pthread_join().
Fixes random failures of fate-ffmpeg-error-rate-fail on Windows after
433cf391f5.
See also [1] for an alternative approach that does not require dynamic
allocation, but relies on an assumption that the pthread_t value
remains in a fixed memory location.
[1] 23829dd2b2
Reviewed-By: Martin Storsjö <martin@martin.st>
When subblock durations are constant, the last block may be smaller and the
value needs to be calculated.
Signed-off-by: James Almer <jamrial@gmail.com>
Section 3.6.1 of the IAMF spec states "When constant_subblock_duration is equal to 0, the summation of all
subblock_duration in this parameter block SHALL be equal to duration.".
Signed-off-by: James Almer <jamrial@gmail.com>
The queue needs to track each frame/packet's stream index, this is
achieved by maintaining a parallel AVFifo instance for that purpose.
This is simpler than implementing custom AVContainerFifo callbacks.
This can be useful in other places, e.g. it can replace objpool in
fftools.
The API is modified in the following nontrivial ways:
* opaque pointers can be passed through to all user callbacks
* read and write were previously separate callbacks in order to
accomodate the caller wishing to write a new reference to the FIFO and
keep the original one; the two callbacks are now merged into one, and
a flags argument is added that allows to request such behaviour on a
per-call basis
* new peek and drain functions
This makes the behavior of av_file_map() the same on Windows as it is on
other platforms. The file is opened as read-only, but the mapping is
copy-on-write, allowing the user to write to the memory pages returned
by av_file_map().
This commit fixes libavutil\tests\file.c test, which would crash when
trying to write to a read-only memory page.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently, ffprobe has two stream-level fields that do not work,
closed_captions and film_grain).
Their value is always 0 because ffprobe cannot access the internal
codec properties when it is setting up its stream contexts.
In this commit, add the new option -analyze_frames to ffprobe,
allowing the user to read frames up to the interval they have defined
and fill these fields based on what is exposed in AVPacketSideData.
Additionally, in the same commit, don't write these fields to
the output unless analyze_frames is enabled. Finally, fix the
FATE test refs accordingly and update the docs.
Signed-off-by: Marth64 <marth64@proxyid.net>
After introduction of ff_dvdclut_palette_extradata_cat() to convert
DVD subtitle palettes from YUV to RGB, a leak is introduced because
of the call to ff_alloc_extradata(). This is not necessary, instead
we should free the extradata because ff_bprint_to_codecpar_extradata()
will finalize the bprint'ed string to the codecpar and set the length.
Fixes leak introduced in 3b0e6c0ecc.
Signed-off-by: Marth64 <marth64@proxyid.net>
This fixes occasional failed tests, if doing "make fate" without a
regular "make" or "make all" inbetween.
Signed-off-by: Martin Storsjö <martin@martin.st>
If running tests with "make -j<N> fate", the execution will stop
after the first failing test. To get an overview of the whole
test suite, one rather would run "make -k -j<N> fate", which then
again buries the results about what tests actually failed further
up in the console log.
Add a target so one can run "make fate-list-failing", to see a list
of all tests that failed the last time they were executed.
Also add a companion target "fate-clear-reports" which removes all
the old test reports. (When executing a subset of tests, the report
files of all tests that aren't executed stay untouched. This also
allows getting rid of reports for tests that no longer are present
in the testsuite.)
Co-authored-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
This corresponds to commit 9278a14cf406f8edb5052c42b83750112bf5b515
in dav1d.
Omitting the C-only functions doesn't speed up benchmarking
anyway (as those has to be benchmarked before we know if we have
any corresponding assembly functions), and being able to benchmark
those functions without corresponding assembly can be valuable in
a number of cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
We only parse 12 values, so this check always failed. Regression caused by
a change to the print format.
Fixes: 59c39a79ca
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
In 7.4.3.20 of H.266 (V3), there are two similarly-named variables:
scalingMatrixDcPred and ScalingMatrixDcRec. The old code set
ScalingMatrixDcRec, rather than scalingMatrixDcPred, in the first two
branches of the conditions on scaling_list_copy_mode_flag[id] and
aps->scaling_list_pred_mode_flag[id]. This could lead to decode
mismatches in sequences with explicitly-signalled scaling lists.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Share the checkasm_check_pixel macro from hevc_pel in checkasm.h,
to allow other tests to use the same. (To use it in other tests,
those tests need to have a similar setup for high bitdepth pixels,
with a local variable named "bit_depth".)
This simplifies the code for checking the output, and can print
the failing output (including a map of matching/mismatching
elements) if checkasm is run with the -v/--verbose option.
Signed-off-by: Martin Storsjö <martin@martin.st>
The PNGv3 Specification Draft [1] has changed the capitalization
of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates
FFmpeg to work with the new chunk names while retaining decode-side
compatibility with files created using the old names.
[1]: https://w3c.github.io/png/
Signed-off-by: Leo Izen <leo.izen@gmail.com>
SMUSH ANIM files with subversion 2 provide additional fields for
framerate and samplerate, use them if available, otherwise
default to 12 fps which is the default for almost all ANIMv2
since 1995.
Fixes the too-fast playback of test files from LucasArts games
released 1995-1997. It was not noticed since Audio for
those isn't decoded by ffmpeg.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
instead of just resyncing and skipping a bunch of TS packets, leading to
a loss of frames.
Before this, a stray byte with the value of 0x47 in TP_extra_header
would throw off the detection of where TS packets start.
A typical file that could cause issues would look like this:
00000300: 238f 4780 4750 1110 0000 01e0 0000 84c0
^^ ^^
The first four bytes here are TP_extra_header and the actual TS packet
starts at offset 0x304
FFmpeg would try to read a packet at 0x300 but since nothing skips the
4 byte TP_extra_header, find that the first byte is not 0x47 and
immediately go into mpegts_resync, and incorrectly detect the stray 0x47
in the TP_extra_header at 0x302 as the new sync byte.
Fix this by correctly skipping the first 4 bytes if the source packet
is 192 bytes.
Signed-off-by: llyyr <llyyr.public@gmail.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
Commit 8542f9c4f1 changed replaygain peak
values to use 100k instead of UINT32_MAX as peak, with possibility of
overflow. af_ashowinfo was never updated to reflect this, so we update
it now.
Fixes: 8542f9c4f1
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes FATE on a variety of configurations due to accuracy problems in
floating point math. Most constants tested against here are not even
specified with 7 decimal digits.
Reviewed-by: Niklas Haas <git@haasn.dev>
Reduces memory consumption by ~4MB for 1080p video with a maximum delay
of 16 frames by packing various information related to MIP:
* intra_mip_flag, 1 bit
* intra_mip_transposed_flag, 1 bit
* intra_mip_mode, 4 bits
Into a single byte.
Co-authored-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Frank Plowman <post@frankplowman.com>
There is an issue with the constants used in YUV to YUV range conversion,
where the upper bound is not respected when converting to mpeg range.
With this commit, the constants are calculated at runtime, depending on
the bit depth. This approach also allows us to more easily understand how
the constants are derived.
For bit depths <= 14, the number of fixed point bits has been set to 14
for all conversions, to simplify the code.
For bit depths > 14, the number of fixed points bits has been raised and
set to 18, to allow for the conversion to be accurate enough for the mpeg
range to be respected.
The convert functions now take the conversion constants (coeff and offset)
as function arguments.
For bit depths <= 14, coeff is unsigned 16-bit and offset is 32-bit.
For bit depths > 14, coeff is unsigned 32-bit and offset is 64-bit.
x86_64:
chrRangeFromJpeg8_1920_c: 2127.4 2125.0 (1.00x)
chrRangeFromJpeg16_1920_c: 2325.2 2127.2 (1.09x)
chrRangeToJpeg8_1920_c: 3166.9 3168.7 (1.00x)
chrRangeToJpeg16_1920_c: 2152.4 3164.8 (0.68x)
lumRangeFromJpeg8_1920_c: 1263.0 1302.5 (0.97x)
lumRangeFromJpeg16_1920_c: 1080.5 1299.2 (0.83x)
lumRangeToJpeg8_1920_c: 1886.8 2112.2 (0.89x)
lumRangeToJpeg16_1920_c: 1077.0 1906.5 (0.56x)
aarch64 A55:
chrRangeFromJpeg8_1920_c: 28835.2 28835.6 (1.00x)
chrRangeFromJpeg16_1920_c: 28839.8 32680.8 (0.88x)
chrRangeToJpeg8_1920_c: 23074.7 23075.4 (1.00x)
chrRangeToJpeg16_1920_c: 17318.9 24996.0 (0.69x)
lumRangeFromJpeg8_1920_c: 15389.7 15384.5 (1.00x)
lumRangeFromJpeg16_1920_c: 15388.2 17306.7 (0.89x)
lumRangeToJpeg8_1920_c: 19227.8 19226.6 (1.00x)
lumRangeToJpeg16_1920_c: 15387.0 21146.3 (0.73x)
aarch64 A76:
chrRangeFromJpeg8_1920_c: 6324.4 6268.1 (1.01x)
chrRangeFromJpeg16_1920_c: 6339.9 11521.5 (0.55x)
chrRangeToJpeg8_1920_c: 9656.0 9612.8 (1.00x)
chrRangeToJpeg16_1920_c: 6340.4 11651.8 (0.54x)
lumRangeFromJpeg8_1920_c: 4422.0 4420.8 (1.00x)
lumRangeFromJpeg16_1920_c: 4420.9 5762.0 (0.77x)
lumRangeToJpeg8_1920_c: 5949.1 5977.5 (1.00x)
lumRangeToJpeg16_1920_c: 4446.8 5946.2 (0.75x)
NOTE: all simd optimizations for range_convert have been disabled.
they will be re-enabled when they are fixed for each architecture.
NOTE2: the same issue still exists in rgb2yuv conversions, which is not
addressed in this commit.
The existing av_csp_trc_func_from_id() mostly implements the OETF, except for
PQ. As such, we are currently missing a precise definition of an ITU-R EOTF.
Introduce the new functions av_csp_itu_eotf() and av_csp_itu_eotf_inv(), to fill
this void. Note that this is not possible in all cases, e.g. AVCOL_TRC_LOG which
has no corresponding EOTF definition in any ITU-R standard.
Note that we cannot implement the proper HLG and SMPTE 428 OOTFs without access
to all three color channels, because they are not independent per channel. As a
result, we need to define them on double[3] instead of double (*func)(double).
This explanation was inaccurate and highly misleading. The new wording is taken
more or less directly from ITU-T H.273, and also matches my understanding of
these functions.
The basic problem here is that the rgb*ToUV_half_* functions hard-code a
bilinear downsample from src[i] + src[i+1], with no bounds check on the i+1
access.
Due to the signature of the function, we cannot easily plumb the "true" width
into the function body to perform a bounds check. Similarly, we cannot easily
pre-pad the input because it is typically reading from the (const) input
frame, which would require a full memcpy to pad. Either of these solutions are
more trouble than the feature is worth, so just disable it on odd input sizes.
Fixes: use of uninitialized value
Fixes: ticket #11265
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
WASI mssing signal and siglongjmp support. This patch workaround
build error and add simd128 flag. Please note that many tests use
large array on stack, so you need to increase the stack size when
build checkasm, e.g., --extra-ldflags='-Wl,-z,stack-size=10485760'
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
And add wasm simd128 flag, so we can add simd128 optimizations.
It can be enabled by put -msimd128 to extra cflags. There is
no runtime detection on simd128 support yet. I think that needs to
be done with JavaScript.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: 70991/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WEBP_fuzzer-5544067620995072
Fixes: use of uninintailized value
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: 71350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-6322020827070464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rv60_qp_to_idx table only supports qp up to 31 on intra
Fixes: global-buffer-overflow
Fixes: 377543818/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5160167345291264
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>
Note ISO/IEC 13818-1 defines an Extension_descriptor with descriptor_tag value
0x3f (63), so I kept the DVB comment.
I don't know what defines stream_type value 0x8a as DTS.
I don't have any Blu-ray standards so I don't know where those stream_type
values are defined.
Signed-off-by: Marton Balint <cus@passwd.hu>
H.266 (V3) section 7.4.12.8: "The value of lMvd[ compIdx ] shall be in
the range of −2^{17} to 2^{17} − 1, inclusive."
Signed-off-by: Frank Plowman <post@frankplowman.com>
Per H.266 (V3) section 7.4.3.19, LmcsMaxBinIdx is set equal to
15 - lmcs_delta_max_bin_idx. The previous code instead had it equal to
15 - lmcs_min_bin_idx. This could cause decoder mismatches.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Previously, the code only stored the MIP mode and transpose flag in the
relevant tables at the top-left corner of the CU. This information ends
up being retrieved in ff_vvc_intra_pred_* not based on the CU position
but instead the transform unit position (specifically, using the x0 and
y0 from get_luma_predict_unit). There might be multiple transform units
in a CU, hence the top-left corner of the transform unit might not
coincide with the top-left corner of the CU. Consequently, we need to
store the MIP information at all positions in the CU, not only its
top-left corner, as we already do for the MIP flag.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The final parameter of check_available determines whether the motion
estimation region constraints imposed in section 8.5.2.3 of H.266 (V3)
on MVP candidates apply to the current candidate or not. In the case of
IBC spatial merge candidates they do not, as their availability is
dependent only on the criteria described in sections 8.6.2.3 and 6.4.4,
which do not include this constraint on the motion estimation region.
Signed-off-by: Frank Plowman <post@frankplowman.com>
MinQtLog2SizeIntraC is usually (eq. (51) from VVCv3) defined as
sps_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY
However, in the case ph_log2_diff_min_qt_min_cb_intra_slice_chroma is
present, it is instead (eq. (83) from VVCv3) defined as
ph_log2_diff_min_qt_min_cb_intra_slice_chroma + MinCbLog2SizeY
When ph_log2_diff_max_bt_min_qt_intra_slice_chroma and
ph_log2_diff_max_tt_min_qt_intra_slice_chroma are present, so is
ph_log2_diff_min_qt_min_cb_intra_slice_chroma, and so we should use the
second definition of MinQtLog2SizeIntraC, rather than the first, when
calculating the bounds for these syntax elements.
Signed-off-by: Frank Plowman <post@frankplowman.com>
This does not replicate on my setup, thus this is a blind fix based on ossfuzz trace
Fixes: use of uninitialized value
Fixes: 71747/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5427736120721408
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: 71551/clusterfuzz-testcase-minimized-ffmpeg_dem_QCP_fuzzer-4647386712965120
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 memory
Fixes: 71546/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGQ_fuzzer-5607656650244096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflow: -2147483648 - 1 cannot be represented in type 'int'
Fixes: 373971762/clusterfuzz-testcase-minimized-ffmpeg_dem_DXA_fuzzer-4880491112103936
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 memory in hScale16To15_c()
Fixes: 373924007/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5841199968092160
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the function is not inlined, this is more efficient. Also
it allows calling refill() without the check
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Comply with "For purposes other than determining the amount of data in the decoding units
of the bitstream, decoders shall ignore all data that follow the value 63 for nuh_layer_id in a NAL unit"
Rec. ITU-T H.265 v8 (08/2021) Page 67
Fixes: index 63 out of bounds for type 'const int8_t[63]' (aka 'const signed char[63]')
Fixes: clusterfuzz-testcase-fuzzer_loadfile-5109286752026624
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Found-by: ossfuzz
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The FATE test 'checkasm-sw_yuv2rgb' currently fails on this platform,
in both little- and big-endian configurations with AltiVec enabled.
Disable it for the time being.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ambisonics mode > 1 does not initialize any layer but layer 0
is unconditionally dereferenced
Fixes: poc-2024-11
Fixes: null pointer dereference
Found-by: 苏童 <220235212@seu.edu.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When using fast chapter marker calculation (default), the last
marker is inadverdently ignored due to an off-by-one.
Signed-off-by: Marth64 <marth64@proxyid.net>
Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
The v3 spec reserves CTU size 256. Currently, we use an uint8_t* table to hold cb_width and cb_height.
If a CTU size of 256 is not split, cb_width and cb_height will overflow to 0.
To avoid switching to uint16_t, rejecting CTU size 256 provides a simple solution.
If the current stage reports an error, some variables may not be correctly initialized.
Scheduling the next stage could lead to the use of uninitialized variables.
According to section 6.3.3 "Spatial or component-wise partitionings,"
CTUs should fully cover slices with no overlaps, gaps, or additions.
No overlaps are ensured by task_init_parse.
No gaps and no additions are ensured by this patch.
Co-authored-by: Frank Plowman <post@frankplowman.com>
According to section 6.3.3, 'Spatial or component-wise partitionings,'
Subpictures must cover the entire picture.
Therefore, the total number of subpicture slices should equal the number of picture slices
Co-authored-by: Frank Plowman <post@frankplowman.com>
Previously the delta phase was fixed point fractional with 2^32 fractions,
which caused inaccuracies in the output frequency, unless the input
frequency*2^32 was divisable by the sample rate.
This patch improves frequency accuracy by tracking subfractions of the delta
phase fractions. For this we are using a denominator which is a multiple of the
sample rate, making sure that integer frequencies are always accurately
represented.
Signed-off-by: Marton Balint <cus@passwd.hu>
The filter currently uses inaccurate frequencies, this is in preparation for
fixing that, by using numbers that will map to the equivalent value in the
future code.
Signed-off-by: Marton Balint <cus@passwd.hu>
alignas is portable than compiler's specific __attribute__. It do
have a limitation, that alignas don't support specify aligment on
the declarations of struct (it works for specify alignment on struct
fields), which only used by avcodec/cavs, and is removed now.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
There are another three cavs_vector variables, ff_cavs_dir_mv,
ff_cavs_intra_mv and un_mv. They don't need align to 8.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
SAN FRME objects specify width/height as well as offsets from top/left.
These offsets need to be taken into account for the diff buffers
as well. Fixes playback of all SAN videos of "Shadows of the Empire",
which have a constant top offset of 60 (640x272 video on a 640x480 window)
and show tons of ghosting and block artifacts.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The codec47 header provides colors to use to clear the
2 difference buffers. This fixes artifacts (black hair, faces) in
Curse of Monkey Island "CURSERNG.SAN" video.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Outlaws' RAE.SAN file did not properly fade out in certain scenes,
but simply turned to black as soon as the first XPAL chunk with
the apply command was encountered.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Some codec47 frames come with an interpolation table:
Combining 2 adjacent pixels into a 16bit value, this value can
then be used as index into the interpolation table to get a new
pixel value. This is used for subcodec 1, which encodes a key-
frame at half width and height, and makes these frame less blocky
appearing.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When RPU is removed EL should also be removed. This only applies to
HEVC as AV1 based Profile 10 does not support EL at all.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The changes to output frame props in query_frame overlapped since
578ac59887. Move the copy frame props before the changes.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
According to the GL_EXT_buffer_reference spec alignment
"must be a power of two and be greater than or equal to the largest scalar/component type in the block."
This means by using u32vec2 we can drop the requirement alignment from 8 bytes to 4 bytes
and save a pack64 call in reverse8 (though I assume in most ISAs that compiles to nothing)
Allows the vc2 vulkan encoder to function without setting PB_UNALIGNED
If caller wrote a divisible by eight number of bits it would write an extra byte.
Also increment by to_write instead of BUF_BYTES which overly pads the bitstream.
The code used to use atomic, but over time, this got broken.
This commit also remmoves the is-the-last-submission-ready
shortcut, which rarely did anything.
There's also value in relying on the fact that contexts
always carry their frames in a strictly incremental order
with no gaps.
The function is quite important to ensure that the output
is always going to be sufficient, and it can change version to
version, so exposing it makes sense.
This allows the encoder to fully saturate all queues the GPU
has, giving a good 10% in certain cases and resolutions.
This also improves error resilience if an allocation fails,
and properly cleans up after itself if it does.
This function dates back a long time ago, before vkfmt_from_pixfmt2.
When it was converted over, the thought was that this was far too
restrictive to demand storage images for each format.
With the new clever function, it makes sure to check that the compatible
subformats a format can be used as support storage capabilities.
This gets rid of fake support for RGB48/RGB96 which some implementations
offer but don't support using as storage images.
The crop filter has no effect on scale_vt:
-vf crop=100:100,scale_vt=300x300
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_* properties,
as seen in the implementation vf_crop.c.
Signed-off-by: Koushik Dutta <koushd@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
Rework the parser logic to work similar to other parsers and be able to
correctly packetize raw DNXUC bitstreams.
Bump minor version because the DNXUC codec packet format changes with this.
Normally this would be a breaking change, but in this particular case it should
not cause any issues in practice because the DNXUC codec is relatively new and
we never added a decoder for it.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is an experimental and research codec of which ffmpeg is the only
encoder and decoder, development has stalled since 2013 and these files
don't exist in the wild.
Deprecate the encoders to be removed next major bump, decoders to be
removed one bump afterwards. We also disable the the encoders by default
in configure, the decoders should be disabled by default next bump.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Also fix checks for sc->stts_count that assume it may not be in sync with
sample count.
Missed in 865c73c86f. Fixes parsing durations in
some cases.
Signed-off-by: James Almer <jamrial@gmail.com>
Ensure downmixed is only set once during init, as it used to be.
Fixes a regression since acbb2777e2.
Fixes ticket #11321
Signed-off-by: James Almer <jamrial@gmail.com>
Makes it easier to immediately see if the code examples given in the
style documentation are good or bad examples, making it harder to
accidentally confuse a bad example for a good one.
Given the frequency that new developers, myself included, get the
code style wrong, it is useful to add some examples to clarify how
things should be done.
I do some development and usage of FFmpeg regularly on macOS and sent
some patches to fix issues specific to Darwin in the past so I think it
makes sense to add myself as maintainer so people know they can ping me
if required, for Darwin specific issues/testing.
I have both Intel and Apple Silicon (aarch64) machines as well as older
Macs for testing on older macOS versions if necessary.
Results in over-read of the array. Fortunately, the excess element was
never actually used, but it still triggers ASAN (and could in theory trigger
a segfault).
Fixes: 04ce01df0b
Ronald S. Bultje wrote most of the code before there was a refactor
and condense (which I mostly wrote). As such, listing both him and myself
as maintainers of csp.h and csp.h, which previously had no maintainer
listed at all (after conferring on IRC).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about context initialization, interlacing, etc.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
With the ability to set the thread count as well. This benchmark includes
the constant overhead of context initialization.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against the old one, to serve as an unchanging reference. This
does not accomplish much yet, but serves as a framework for future work.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the existing one.
Most of the API work has been already accomplished in the previous commits,
this commit merely introduces the ability to use sws_scale_frame()
dynamically, without prior sws_init_context() calls. Instead, the new API
takes frame properties from the frames themselves, and the implementation is
based on the new SwsGraph API, which we simply reinitialize as needed.
This high-level wrapper also recreates the logic that used to live inside
vf_scale for scaling interlaced frames, enabling it to be reused more easily
by end users.
Finally, this function is designed to simply copy refs directly when nothing
needs to be done, substantially improving throughput of the noop fast path.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This interface has been designed from the ground up to serve as a new
framework for dispatching various scaling operations at a high level. This
will eventually replace the old ad-hoc system of using cascaded contexts,
as well as allowing us to plug in more dynamic scaling passes requiring
intermediate steps, such as colorspace conversions, etc.
The starter implementation merely piggybacks off the existing sws_init() and
sws_scale(), functions, though it does bring the immediate improvement of
splitting up cascaded functions and pre/post conversion functions into
separate filter passes, which allows them to e.g. be executed in parallel
even when the main scaler is required to be single threaded. Additionally,
a dedicated (multi-threaded) noop memcpy pass substantially improves
throughput of that fast path.
Follow-up commits will eventually expand this to move all of the scaling
decision logic into the graph init function, and also eliminate some of the
current special cases.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.
Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_DIFFUSION.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a purely cosmetic commit aimed at replacing accesses to
SwsInternal.opts by direct access to SwsContext wherever convenient.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Guillaume no longer has a PPC
Romain has no time
CC: Guillaume POIRIER <poirierg@gmail.com>
CC: Romain Dolbeau <romain@dolbeau.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Null pointer dereference
Fixes: sample1.dng
Found-by: South East <8billion.people@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
xHE-AAC is a profile where some frames depend on other key frames, named IPF.
By setting the codec as Intra Only, all frames output by decoders and all
packets output by encoders/demuxers will be unconditionally flaged as
keyframes, which is incorrect.
Should fix ticket #11272.
Signed-off-by: James Almer <jamrial@gmail.com>
And not just the first, as it was being done for lacing. The spec states that the
flag applies to everything inside the simple box.
Signed-off-by: James Almer <jamrial@gmail.com>
The ctxi_dst variable is unused outside of the av_assert1,
causing an unused variable warning. The simplest solution
for this is to avoid the intermediate variable here.
They are needed for audio tracks with priming samples, where negative CTS
offsets can't be used.
Fixes ticket #11031.
Signed-off-by: James Almer <jamrial@gmail.com>
avgBitrate == 0 is used to signal a VBR track, so if that value is propagated by an
encoder, don't overwrite it with a calculated value based on track size.
Part of a fix for ticket #11303.
Signed-off-by: James Almer <jamrial@gmail.com>
Don't reject extradata with missing PS NALUs if array_completeness is not
requested.
Fixes a regression since a696b28886.
Signed-off-by: James Almer <jamrial@gmail.com>
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
STRIDE_ALIGN is a lavc define and is not necessarely 32. And align may be <= 0 at the
point plane_padding is being set.
Signed-off-by: James Almer <jamrial@gmail.com>
This is a preliminary step to separating these into a new struct. This
commit contains no functional changes, it is a pure search-and-replace.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
ATSC A/52:2018 Digital Audio Compression (AC-3, E-AC-3), Annex G
defines stream_type 0x87 for E-AC-3 bit streams.
Signed-off-by: Marton Balint <cus@passwd.hu>
Some mp3 files look surprisingly like mpeg PS streams. In order for us
to hint to ffmpeg that the file really is mp3, we can deliver it with a
mime type. The mp3 probe therefore needs to have a mime type registered,
(which is previously did not).
For example, with
./ffmpeg -operating_rate 400 -hwaccel mediacodec -i test.mp4 -an \
-c:v h264_mediacodec -operating_rate 400 -b:v 5M -f null -
The transcoding speed is 254 FPS.
Without -operating_rate on dec/enc, the speed is 148 FPS.
With -operating_rate on decoder only, the speed is 239 FPS.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The codec wants to know whether the usecase is realtime playback
or full-speed transcoding, or playback at a higher speed. The codec
runs faster when operating_rate higher than framerate.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The typo has no real effect except confusing.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reported-by: Chen Haibo
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
The code used as a basis was the buffer dependency code, where the
counter was incremented after each buffer, but for the sw_frame dep
API, we only support adding individual frames at a time.
Unlike the software FFv1 encoder, none of our buffers are allocated by
FFmpeg, which supports at most 4GiB large allocations.
For really large sizes, the maximum size of the buffer can exceed 4GiB,
which the software encoder optimistically tries to allocate as 4GiB
in the hopes that the encoder will compress to under that amount.
We can just let Vulkan allocate us a larger buffer, and switch to
64-bit offsets.
Ref https://trac.ffmpeg.org/ticket/11152
According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
called, as, quoted:
```
An #hb_font_t object created with hb_ft_font_create()
is preconfigured for FreeType font functions and does not
require this function to be used.
```
Using this function seems to cause memory management issues between
harfbuzz and freetype, and could be eliminated.
This commit also call hb_ft_font_changed() when the underlying FC_Face
changes size, as stated on hardbuzz:
```
HarfBuzz also provides a utility function called hb_ft_font_changed() that you should call
whenever you have altered the properties of your underlying FT_Face, as well as a hb_ft_get_face()
that you can call on an hb_font_t font object to fetch its underlying FT_Face.
```
Finally, the execution order between hb_font_destroy() and
hb_buffer_destroy() is flipped to match the order of creation of
the respective objects.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv
FreeBSD/OpenBSD riscv have elf_aux_info().
Signed-off-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
As of 459a1512f1,
the code is unrolled to process two rows per iteration.
The output cursor thus needs to be incremented by twice the
stride, which is taken care of with SH1ADD. However the original
ADD from the original implemetation was incorrectly left over.
The half-baked assembler in Clang 16 and earlier can't process our
RISC-V assembler. This adds yet another work around that.
If you must use Clang, please use version 17 or later.
This commit implements a standard, compliant, version 3 and version 4
FFv1 encoder, entirely in Vulkan. The encoder is written in standard
GLSL and requires a Vulkan 1.3 supporting GPU with the BDA extension.
The encoder can use any amount of slices, but nominally, should use
32x32 slices (1024 in total) to maximize parallelism.
All features are supported, as well as all pixel formats.
This includes:
- Rice
- Range coding with a custom quantization table
- PCM encoding
CRC calculation is also massively parallelized on the GPU.
Encoding of unaligned dimensions on subsampled data requires
version 4, or requires oversizing the image to 64-pixel alignment
and cropping out the padding via container flags.
Performance-wise, this makes 1080p real-time screen capture possible
at 60fps on even modest GPUs.
We do uploads asynchronously, and we map the software frames in
order to avoid 2-stage copying. However, whilst we added a dependency
upon the mapped buffers, we did not add the original frame backing
those buffers as a dependency.
This caused issues on RADV, particularly with RGB images.
After the branch, the expected SEW/LMUL ratio is 1 byte/vector.
So we have to set the same ratio before branching (QEMU does not care,
but real hardware does).
Some DVD muxers signal segments to start with duplicate audio samples
when starting extraction from a chapter marker or terminate seamless PGs
on partial audio samples (causing corrupt AC3 frames). Clean up after
these muxers by tracking frames with duplicate PTS and eliminating
partial AC3 frames.
This results in smoother chapter extraction and overall seeking experience,
with linear PTS and AC3 delay within 32ms (1 frame) away from the video.
The issue was not apparent until the flushing pattern was replaced with
a full subdemux reset, as the flushing dropped the frames prematurely,
along side others, as such they were never present to begin with.
The packets effectively serve no purpose and we are already
dropping packets with PTS less than 0. This also creates
for a smoother seeking experience after the subdemuxer
reset fix.
Signed-off-by: Marth64 <marth64@proxyid.net>
It is wasteful to open the subdemuxer if an error occurs while
initializing streams or reading IFO headers.
Signed-off-by: Marth64 <marth64@proxyid.net>
The "auto" mode serves no functional purpose except for logging
a message and setting the value to 1. The documentation clearly
explains what the option is for.
Signed-off-by: Marth64 <marth64@proxyid.net>
Menu 0 is the VIDEO_TS root menu, which does not appear to be used
commonly for menu segments. Instead, default to the menu of VTS 1.
Signed-off-by: Marth64 <marth64@proxyid.net>
Some discs present titles with bogus NAV packets. We apply this check
for menus and for title MPEG blocks, but we should also apply it
for NAV packets during title demuxing.
Signed-off-by: Marth64 <marth64@proxyid.net>
DVDs naturally consist of segmented MPEG-PS blobs within a VOB
(i.e. VOBs are not linear). NAV packs set the segment boundaries.
When switching between segments, discontinuities occur and thus
the subdemuxer needs to be reset. The current approach to manage
this is by invoking ff_read_frame_flush() on the subdemuxer context,
via a callback function which is invoked during the menu or dvdnav
block functions. The same subdemuxer context is used throughout
the demux, with a stretched PTS wrap bits value (64) + disabled
overflow correction, and then flushed on each segment. Eventually,
a play_end context variable is set to declare EOF.
However, this approach causes frame drops. The block read flushes the
demuxer before the frame read is complete, causing frames to drop
on discontinuity. The play_end signal likewise ends playback before
the frame read is complete, causing frames to drop at end of the title.
To compound the issue, the PTS wrap bits value of 64 is wrong;
the VOBU limit is actually 32 and the overflow correction should work.
Instead, EOF the MPEG-PS subdemuxer organically when each VOB segment
ends, and re-open it if needed with the offset after the full frame read
is complete. In doing so, correct the PTS wrap behavior to 32 bits and
remove the play_end/segment_started signals and callback pattern.
Note that the timestamps as reported by the NAV packets are known as
"PTMs", so the fields storing the time prior to adjustment are renamed
accordingly. This makes it more clear when we are offsetting the
NAV packet reported timestamps versus what we present as a demuxer.
Signed-off-by: Marth64 <marth64@proxyid.net>
The function has a few branches where it discards frames via
FFERROR_REDO; consolidate is via a goto block to simplify the
function and improve readability. Logging still maintains
all the relevant details for the reason of the discard.
Signed-off-by: Marth64 <marth64@proxyid.net>
Menus are generally segmented by cell, so use them as the
marker delimiters. Requires preindex option to be enabled.
Signed-off-by: Marth64 <marth64@proxyid.net>
This consolidates the FFERROR_REDO handling of NAV packets to
dvdvideo_subdemux_read_data(), is a pre-requisite to calculating
chapter markers for menus, and a pre-requisite to fixing the
frame desync issue when the subdemuxer is flushed.
Signed-off-by: Marth64 <marth64@proxyid.net>
Readability improvement; the warning can be bundled beneath
the preceding validations rather than awkwardly between the memcpy
and return.
Signed-off-by: Marth64 <marth64@proxyid.net>
The default "auto" mode is effectively useless; the reasonable
default use case is to use the first PG (segment) of the
selected PGC for both menus and standard titles. Just
default the value to 1, since the option is irrelevant
unless -pgc is also set.
Note that this should not break users using this advanced option.
The "auto" mode errored and asked for a PG number regardless
for non-menus, and for menus the mode simply defaulted to 1.
Signed-off-by: Marth64 <marth64@proxyid.net>
This reverts 887d74c47e, because it ignores the
maximum allowed numerator/denominator. Even if the result was rounded to zero
or infinity, it should not be cause to ignore the maximum allowed number, this
"feature" is unintuitive and undocumented.
Signed-off-by: Marton Balint <cus@passwd.hu>
PIXFUNC macro is unused since d29a9c2aa6.
Signed-off-by: Kyosuke Kawakami <kawakami150708@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The add_dirac_obmc8_mmx function was the only MMX function left. This
patch migrates it to SSE2.
Here are the checkasm benchmark results:
diracdsp.add_dirac_obmc_8_c: 2299.1 ( 1.00x)
diracdsp.add_dirac_obmc_8_mmx: 237.6 ( 9.68x)
diracdsp.add_dirac_obmc_8_sse2: 109.1 (21.07x)
Signed-off-by: Kyosuke Kawakami <kawakami150708@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The JPEG XL parser has an entropy decoder inside, which supports LZ77
length-distance pairs. If the first symbol from the entropy stream is an
LZ77 pair, the bitstream is invalid, so we should abort immediately rather
than attempt to read it anyway (which would read from the uninitialized
starting window).
Reported-by: Kacper Michajłow <kasper93@gmail.com>
Found-by: ossfuzz
Fixes: 368725676/clusterfuzz-testcase-minimized-fuzzer_protocol_file-6022251122589696-cut
Fixes: 42537758/clusterfuzz-testcase-minimized-fuzzer_protocol_file-5818969469026304-cut
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Before:
$ make tools/enc_recon_frame_test
$ tools/enc_recon_frame_test ~/Movies/cif/bus_cif.y4m libx264 'tune=psnr'
Error submitting a frame for encoding
After:
All 150 encoded frames match
The logic did not follow the documented behaviour and that caused skipping of
some audio in the loop and in the leftover buffer.
Example command line which should produce a smooth sine wave for the whole
duration of the output:
ffmpeg -f lavfi -i "sine=r=48000:f=480:d=4" -af "aloop=loop=4:start=48000:size=48000" out.wav
Fixes ticket #11283.
Signed-off-by: Marton Balint <cus@passwd.hu>
If the audio loop stops inside an audio frame, the leftover buffer contains the
end of the frame, which is not looped. The length supposed to be the part which
was not written to the loop buffer, so we need to drain exactly that number of
bytes from the leftover buffer.
Signed-off-by: Marton Balint <cus@passwd.hu>
And ensure the buffer is synced between threads.
Based on a patch by Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: James Almer <jamrial@gmail.com>
This removes the ABI breaking use of sizeof(AVFilmGrainParams), and achieves the
same size reduction to decoder structs as 08b1bffa49.
Signed-off-by: James Almer <jamrial@gmail.com>
AVFilmGrainAFGS1Params, the offending struct, is using sizeof(AVFilmGrainParams)
when it should not. This change also forgot to make the necessary changes to the
frame threading sync code.
Both of these will be fixed by the following commit.
H274FilmGrainDatabase will be handled later.
This reverts commit 08b1bffa49.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit introduced a regression to VVC_HDR_UHDTV1_OpenGOP_3840x2160_50fps_HLG10_mosaic.ts.
Root Cause:
The AV_CEIL_RSHIFT(a, b) macro uses bit tricks that work only when -a is a negative value.
However, due to integer promotion rules, this behavior does not extend to the unsigned int type.
See "6.3.1.1 Boolean, characters, and integers" in the "ISO/IEC 9899" for details.
Reported-by: Frank Plowman <post@frankplowman.com>
Fixes: use of uninitialized value (untested)
Fixes: 42537627/clusterfuzz-testcase-minimized-fuzzer_loadfile_direct-5505802505355264
Found-by: ossfuzz
Reported-by: Kacper Michajlow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 42537627/clusterfuzz-testcase-minimized-fuzzer_protocol_memory-6656646223298560-cut
Found-by: ossfuzz
Reported-by: Kacper Michajlow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Pointers to specific entries in the array are stored in other structs, so
in the scenario where heif_item was reallocated when parsing an iloc box after
and iinf one, the pointers may end up referencing freed memory.
Fixes use-after-free with such samples.
Signed-off-by: James Almer <jamrial@gmail.com>
Setting it was broken in 8160178dfc, since
links are not yet set up during init. It is also redundant, as the
struct also stores the input index.
Reported-By: llyyr <llyyr.public@gmail.com>
When Closed Captions are discovered, this method is always invoked.
Therefore, use it to set the property instead of repeating the statement.
Signed-off-by: Marth64 <marth64@proxyid.net>
Enable waiting in QueryOutput() based on driver support to reduce
unnecessary delays.
Fix for issue #10622
Co-authored-by: Araz Iusubov <Primeadvice@gmail.com>
When vulkan rendering is requested by the user and fails, ffplay should
exit graciously instead of crash due to a null pointer deref.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Use DXGI/D3DFMT 16bit pixel format to compatible with 12bit Y212/XV36
since there is no 12bit pixel defined in D3D11/D3D9.
Fix cmdline on Windows:
$ ffmpeg.exe -hwaccel qsv -init_hw_device qsv:hw,child_device_type=
{d3d11, dxva2} -i input_12bit.bin -f null -
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Peter Ross <pross@xvid.org>
Same as it's done in lumRangeToJpeg16_c(). Plenty of allowed input values can
overflow here.
Fixes: src/libswscale/swscale.c:198:47: runtime error: signed integer overflow: 475328 * 4663 cannot be represented in type 'int'
Signed-off-by: James Almer <jamrial@gmail.com>
The fate test reference changes are due to the conversion being a simple
lossless deinterleave, instead of going through a RGB -> YUV -> RGB roundtrip.
Signed-off-by: James Almer <jamrial@gmail.com>
Also include the hardware feature flags like the other archs do and
clean up the code a bit.
Tested on Linux POWER9.
Signed-off-by: Brad Smith <brad@comstyle.com>
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=100x100
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_* properties,
as seen in the implementation vf_crop.c.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes the following assert:
[00007f1df83d17e0] vaapi generic error: avcodec_get_hw_frames_parameters failed: -22
Assertion p_dst->hwaccel_threadsafe || (!dst->hwaccel && !dst->internal->hwaccel_priv_data) failed at libavcodec/pthread_frame.c:349
Reproduced from VLC with VAAPI, when fallbacking from hw to sw.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This commit also reduces the number of times ff_sws_init_scale() gets
called (only once per bit depth), and the number of times randomize_buffers()
gets called (only if the function must be checked).
Benchmarks are only performed on bit depths 8 and 16 (since they are
different functions, and not only different constants).
Reduce input sizes to 8 (to test that the function works with widths
smaller than the vector length) and 1920 (raising the largest input
size to improve benchmark results).
This commit also fixes the issue that the call to ff_sws_init_range_convert()
from sws_init_swscale() was not setting up the arch-specific optimizations.
Fixes compile error on windows with decklink:
In file included from ./libavformat/os_support.h:175,
from ./libavformat/internal.h:30,
from libavdevice/decklink_common.cpp:25:
./libavutil/wchar_filename.h: In function 'int wchartocp(unsigned int, const wchar_t*, char**)':
./libavutil/wchar_filename.h:59:32: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
59 | *filename = av_malloc_array(num_chars, sizeof **filename);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void*
Regression since e9e8bea2e7.
Fixes ticket #11103.
Signed-off-by: Marton Balint <cus@passwd.hu>
MediaTek SOC return broken crop info, e.g.,
width: int32(3840) height: int32(2160) crop: Rect(0, 0, 318, 238)
It will notify the right crop info with infoOutputFormatChanged, but
too late.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
MediaCodec can generate AV1CodecConfigurationRecord, which shouldn't
be put into packet->data. Skip four bytes and extract configOBUs
if it exist.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
For example, the default surface configuration on macOS is:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_PASS_THROUGH_EXT
With HDR10 content and swapchain_colorspace_hint, the surface
configuration updated to:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_HDR10_ST2084_EXT
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: use of uninitialized variable
Fixes: 368729566/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTS_fuzzer-6044501804646400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 4611686016549392399 + 9223372033098784800 cannot be represented in type 'long long'
Fixes: 368503277/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5928227458056192
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 368143798/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6475823425585152
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Film grain support adds a huge amount of overhead to the H264Context
structure for a feature that is rarely used. On low end devices or
pages that have lots of media this bloats memory usage rapidly.
This changes the static film grain metadata allocations to be dynamic
which reduces the H264Context size from 851808 bytes to 53444 bytes.
Bug: https://crbug.com/359358875
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Niklas Haas <git@haasn.dev>
This fixes corner cases (requires version 4 or a spec update)
Fixes: Ticket5548
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And preserve the public SwsContext as separate name. The motivation here
is that I want to turn SwsContext into a public struct, while keeping the
internal implementation hidden. Additionally, I also want to be able to
use multiple internal implementations, e.g. for GPU devices.
This commit does not include any functional changes. For the most part, it is
a simple rename. The only complications arise from the public facing API
functions, which preserve their current type (and hence require an additional
unwrapping step internally), and the checkasm test framework, which directly
accesses SwsInternal.
For consistency, the affected functions that need to maintain a distionction
have generally been changed to refer to the SwsContext as *sws, and the
SwsInternal as *c.
In an upcoming commit, I will provide a backing definition for the public
SwsContext, and update `sws_internal()` to dereference the internal struct
instead of merely casting it.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
-disposition:
Clarify the meaning of the default value, and how the '+' and '-'
prefixes work. Add more examples.
-stats:
Clarify that it appears as an "info"-level log.
-progress:
Add info about the "progress" key's value being "continue" or "end".
Add an example of logging to stdout.
Signed-off-by: Soma Lucz <luczsoma@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
I want to pull options out of SwsInternal, so we need to make this field
a dedicated int that gets updated as appropriate in ff_swscale().
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Replacing the old sws_isSupported* API with a more consistent family
of functions that follows the same signature and naming convention,
including a placeholder for testing the color space parameters that
we don't currently implement conversions for.
These functions also perform some extra basic sanity checking.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Groups together all relevant color metadata from an AVFrame. While we could
use AVFrame directly, keeping it a separate struct has three advantages:
1. Functions accepting an SwsFormat will definitely not care about the
data pointers.
2. It clearly separates sanitized and raw metadata, since the function to
construct an SwsFormat from an AVFrame will also sanitize.
3. It's slightly more lightweight to pass around.
Move these into a new header file "utils.h" to avoid crowding
swscale_internal.h even more, and also to solve a circular dependency issue
down the line.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Merely a convenience wrapper around sws_freeContext(). The name change is for
parity with the other sws_* functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
I want to start grouping "legacy" functions which I tend to deprecate
together, away from the new ones.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Slightly more convenient, especially for the upcoming refactor which will
turn SwsContext into a public struct.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This helps detecting inconsistencies in swscale input/output code and
a av_read_image_line()/av_write_image_line() pass.
Signed-off-by: James Almer <jamrial@gmail.com>
Ensure those bits are copied, which will result in the output being the same as
the input, where swscale set them to the equivalent of fully opaque.
Signed-off-by: James Almer <jamrial@gmail.com>
This can be useful to simplify certain processes that need to know how many
reserved bits there are and where they are placed, even if they are ultimately
unused, as will be shown in the next commit.
For any other case where the user simply looks at nb_components components, it
will make no difference.
Signed-off-by: James Almer <jamrial@gmail.com>
As specified in libass's ass_types.h, the colors or ASS_Images
should be converted to YCbCr using the matrix/range specified in
the track's YCbCrMatrix field (unless that field is set to YCBCR_NONE,
and defaulting to TV.601 if the header is missing).
This does not affect any subtitles generated or transcoded by ffmpeg,
since these contain a 'YCbCrMatrix: None' header.
Signed-off-by: arch1t3cht <arch1t3cht@gmail.com>
Signed-off-by: rcombs <rcombs@rcombs.me>
The way the linked list of images was freed caused a
use after free, by accessing pic->next after pic was
already freed.
Regression from 48a1a12968
Fix CID1633236
These per-stream FIFOs hold the packets before every stream is
initialized and the header can be written. Once that happens, current
code will flush each stream's queue one after the other. However, in
case we buffered a lot of data for multiple streams, this may cause the
muxer to overflow max_interleave_delta, resulting in worse interleaving
than necessary.
Change the code to interleave packets from all the queues by DTS.
This made the output non binary reproducible across different versions of
zlib.
This reverts commit bce5855afb.
Signed-off-by: James Almer <jamrial@gmail.com>
The demuxer's 'missing_streams' private option is used to communicate
information from the demuxer to avformat_find_stream_info(). However,
that is not only unnecessarily complicated, it also leaks internal
information to users, e.g. this option appears in the results of the
fate-flv-demux test.
Use a new field in FFFormatContext to communicate this information
instead.
This function would otherwise fail to build on the next major bump, as
inject_global_side_data is marked for removal.
It should also never be needed, as there is now a mechanism for
supplying global side data to decoders directly.
stddev and PSNR values change by the removal of format conversion and because
of the added sws_flags. Either or will have the same effect even on their own.
Signed-off-by: James Almer <jamrial@gmail.com>
This change will save approximately 531 MB for an 8K clip when processed with 16 threads.
The calculation is as follows:
7680 * 4320 * sizeof(int) * 2 * 2 * 16 / (4 * 4).
The deblock boundary strength stage utilizes ~5% of CPU resources for 8K clips.
It's worth considering it as a standalone stage. This stage has been relocated
to follow the parser process, allowing us to reuse CUs and TUs before releasing them.
This function is only used for filtering and generic compute.
The issue is that a view inherits the usage flags from the image
by default, and the spec says the view format must be compatible
with the usage. VkImageViewUsageCreateInfo allows us to filter out
the indeded uses of the imageview.
Pffff.
When using **integer** images inside shaders, it turns out
that conversion doesn't automatically happen, but we need to
explicitly use the imageviews to get the image exposed as
a suitable representation for the shader.
Finally enables bitexact image representations.
This format is useful for doing certain lossless transforms on images,
RCT in particular, which require you to escalate the size from 16 to
32 bits to avoid overflows.
APIchanges will be done alongside when comitting.
Broken after 7753a9d627. Apply only the
whitelist early, and the rest with a single call to av_opt_set_dict2()
with AV_OPT_SEARCH_CHILDREN, which should be equivalent to the original
behaviour.
Reported-by: Cameron Gutman <aicommander@gmail.com>
avfilter API requires all the filter parameters, including hw context
(if present) to be available during init, so that is the proper place to
perform such setup.
The "progress2" API in pthread_slice.c currently associates a progress
value with a thread rather than a job, relying on the broken assumption
that a job's thread number is equal to its job number modulo thread
count.
This removes this API entirely, and changes hevcdec to use a
ThreadProgress-based implementation that associates a
mutex/cond/progress value with every job.
Fixes races and deadlocks in hevdec with slice threading, e.g. some of
those mentioned in #11221.
While we only add the flag if the linker seems to support it,
it turns out that ld.bfd had a bug where the flag is accidentally
accepted, and the flag produces an output file named
"_warn_duplicate_libraries".
The ld.bfd bug was fixed in binutils 2.36, in
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3991c7acb29aa8d7d52150695eb3efa03a08dd50.
Signed-off-by: Martin Storsjö <martin@martin.st>
FATE results differ when using the original zlib and zlib-ng.
Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
Signed-off-by: James Almer <jamrial@gmail.com>
md5 values change because the nut container now reports rawvideo as encoder
and Y410 as codec type instead of the bogus RGB[15].
Signed-off-by: James Almer <jamrial@gmail.com>
The documentation of av_fourcc_make_string states the passed in
buffer must be of at least the size of AV_FOURCC_MAX_STRING_SIZE .
Using av_fourcc2str uses the correct buffer size and moves the
buffer into a nested scope while also being shorter.
Fixes: CID 1632380
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
If 'sname:*' is set in the var_stream_map variable, use it as
the NAME attribute for subtitles. This improves the naming of
subtitle streams in HTML players, providing clearer and more
descriptive labels for users.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Ensure that when the `-hls_flags omit_endlist` option is set,
the `#EXT-X-ENDLIST` tag is also omitted from the `stream_vtt.m3u8`
subtitle playlist. This maintains consistency with the behavior
in other playlists when `omit_endlist` is specified.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Ensure that when the `-hls_flags append_list` option is set,
that *.vtt files in stream_vtt.m3u8 are correctly updated.
This fixes https://trac.ffmpeg.org/ticket/11208
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Note1: when the EOF pts is not accurate enough, the last frame
can be dropped by vf_fps with default rounding.
Note2: vf_scale use framesync since e82a3997cd,
so this is a very commonplace scenario.
For example:
./ffprobe -f lavfi testsrc=d=1,scale,fps -of flat \
-count_frames -show_entries stream=nb_read_frames
Before:
streams.stream.0.nb_read_frames="24"
After:
streams.stream.0.nb_read_frames="25"
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When displaying help for overlay filter in CLI, the flags for x and y
parameters don't have the T flag. However these two parameters do have
the capability to be set at runtime, as implemented in commit
d2752ef061. This commit fixes the CLI documentation.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is unreachable anyway so performance is not an issue here. Allows
guiding the compiler in all build modes to not emit a spurious warning
here:
warning: variable 'mag' is used uninitialized whenever switch default is taken
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
The original either reported 8 or 16-bit conversion from the
original, rather than being able to return the actual original.
This makes it usable in a situation where preserving exactness
is required.
It can't be higher than vps_max_sub_layers.
Do this while keeping the workaround for qsvenc_hevc calling ff_hevc_parse_sps()
without a vps_list, as in some cases it needs to parse an sps to generate a fake
vps derived from it.
Signed-off-by: James Almer <jamrial@gmail.com>
I.e. those that are only used to figure out input/output counts, since
some filters might expect a valid hw device in init and refuse to
initalize otherwise.
This requires complex filtergraphs to be created in a separate step
after parsing global options, after all hw devices are guaranteed to
exist.
Likely a tighter check can be done
Fixes: signed integer overflow: 3305606804154370442 * 8 cannot be represented in type 'long'
Fixes: 70449/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4771166007918592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This basically ignores the overflow without undefined behavior, alternatively we could detect and error out
Fixes: signed integer overflow: 6310596683470275584 + 7660622966157213696 cannot be represented in type 'long'
Fixes: 70433/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5483347233538048
Fixes: 369662284/clusterfuzz-testcase-minimized-media_metadata_parser_fuzzer-5327368763670528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Depending on the magnitude of the output values, the potential
errors can be larger.
This fixes errors in the lls tests on x86_32 for some seeds,
observed with GCC 11 (on Ubuntu 22.04, with the distro compiler,
with -m32).
Signed-off-by: Martin Storsjö <martin@martin.st>
Use "bx lr", or "pop {lr}", which do proper mode switching
between thumb and arm modes. A plain "mov pc, lr" does not switch
from thumb mode to arm mode (while in arm mode, it does switch
mode for a thumb caller).
This is normally not an issue, as CONFIG_THUMB only is enabled if
the C compiler defaults to thumb; but stick to patterns that can
do mode switching if needed, for consistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
Used as an intermediate entry point for the new swscale context. The extra
constification is a consistency measure, as I want to move the memcpy of
stride and plane pointers to the functions that actually need to mutate them.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of taking an int16_t pointer and a stride in halfwords, follow the
usual convention of treating all planes and strides as byte-addressed.
This does not have any immediate effect but makes these functions more
reusable without unintended "gotchas".
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This fixes an 11-year-old bug in the rgb2xyz functions, when used with a
negative stride. The current loop bounds turned it into a no-op.
Additionally, this increases performance on highly cropped images, whose
stride may be substantially higher than the effective width.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The flexible array member struct can have padding added by
the compiler which was not taken into account properly, which
could lead to a heap buffer overflow.
spirv_compiler is an undeclared variable that was spontaneously
enabled if libshaderc or libglslang were detected, and served as
a way to enable filters.
However, it being undeclared had the effect that it was neither
considered explicitly disabled nor enabled if libshaderc or
libglslang were detected.
The only category we have which explicitly disables variables
is EXTERNAL_LIBRARY_LIST, however, spirv_compiler is not a real
external library, and making it present there would report its
detection on ./configure.
If someone were to enable libglslang/libshaderc, and then disable
all Vulkan filters, they would have the same issue as the earlier
fix for libavcodec.
I want to move away from having random leaf processing functions mutate
plane pointers, and while we're at it, we might as well make the strides
and tables const as well.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Ideally there should be three parts to the filter context - public,
private to the filter, and private to generic code, but only the first
and the last of these exist currently. Until the second is implemented,
this is better than nothing.
Split it into sections that describe in detail
* the components of the transcoding pipeline
* the main features it handles, in order of complexity
* streamcopy
* transcoding
* filtering
Replace the current confusing/misleading diagrams with new ones that
actually reflect the program components and data flow between them.
893f3fde4c made libavcodec link to libshaderc/libglslang, though
no codecs depend on it at this immediate moment.
This was merged largely as a coordination effort to synchronize three
different developers' repositories to allow them to send patches without
overlapping functionality in between.
This line can be removed once the first component to depend on spirv_compiler
lands, but leaving it in is fine too.
We started defauling to nasm 8 years ago.
We are still compatible with yasm 0.8.0, released in 2009. **15 years ago**.
The time has more than come to remove support for it.
Maintaining compatibility started cutting into writing new code long ago.
We still can't have 2-argument instructions, preprocessor booleans, and all
AVX2 code must still be wrapped in ifdefs. Newly added code often breaks this.
This is the same as with libavfilter.
We will need SPIR-V compilation for at least three different things,
like the VC-2 encoder and decoder, AV1 film grain synthesis for
hardware with no support for it, and possibly other codecs.
The code is not currently used by libavutil, its just where our
common Vulkan code is.
Since SPIR-V compilation will be needed by lavc, move it, rather
than having lavc including lavfi.
With multilayer001.heic:
Before:
[hevc @ ...] Scalability type 2 not supported
[hevc @ ...] Ignoring unsupported VPS extension
[hevc @ ...] The following bit-depths are currently specified: 8, 9, 10 and 12 bits, chroma_format_idc is 0, depth is 0
After:
[hevc @ ...] Scalability type 2 not supported
[hevc @ ...] Ignoring unsupported VPS extension
[hevc @ ...] SPS 1 references an unsupported VPS extension. Ignoring
Signed-off-by: James Almer <jamrial@gmail.com>
Earlier, x265 made an API change to support alpha and
other multiple layer pictures. We added guards to accommodate
that in 1f801dfdb5
They have now reverted that API change in
78e5b703b1
Updated our wrapper guards to unbreak build again.
This silences a lot of compile warnings (around 160 instances at least), when
compiling with Clang.
These warnings look like this:
libavformat/http.c:176:133: warning: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion]
176 | { "end_offset", "try to limit the request to bytes preceding this offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
| ~ ^~~~~~~~~
Signed-off-by: Martin Storsjö <martin@martin.st>
This file is never included explicitly anywhere else, it's only
included implicitly by passing -Pconfig.asm on the command line.
Signed-off-by: Martin Storsjö <martin@martin.st>
Due to the nature of multithreading, using a "ready check" mechanism may introduce a deadlock. For example:
Suppose all tasks have been submitted to the executor, and the last thread checks the entire list and finds
no ready tasks. It then goes to sleep, waiting for a new task. However, for some multithreading-related reason,
a task becomes ready after the check. Since no other thread is aware of this and no new tasks are being added to
the executor, a deadlock occurs.
In VVC, this function is unnecessary because we use a scoreboard. All tasks submitted to the executor are ready tasks.
We still need several refactors to improve the current VVC decoder's performance,
which will frequently break the API/ABI. To mitigate this, we've copied the executor from
avutil to avcodec. Once the API/ABI is stable, we will move this class back to avutil
The log message was logged for `filtergraphs[j]` which would cause a
heap buffer overflow in certain circumstances.
Correctly it should be logged for the current filtergraph, so just
use `fg` here.
Adds missing ifdef guards to function prototypes depending on definitions from
dxva.h which are not available in Mingw-w64 version 4.0. The configure script
already checks for HEVC/VP9 types in dxva.h.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Use AV1DecContext's current_obu to access the original OBUs, and
feed them to videotoolbox, rather than the bare slice data passed
via decode_slice.
This requires a small addition to AV1DecContext, for keeping track
of the current range of OBUs that belong to the current frame.
Co-authored-by: Ruslan Chernenko <ractyfree@gmail.com>
Co-authored-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Martin Storsjö <martin@martin.st>
We always write minimal slices, the size calculation is wrong in some
corner cases but as its always 1x1 (minus1) we can for now just hard-code it
This helps with ticket 5548
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add a mechanism to AVClass to allow objects to signal their state to
generic code. When an object flags itself with the 'initialized' state,
print an error (and fail, after the next major bump) if the caller
attempts to set non-runtime options.
The options-setting functions share several operations at their
beginnings - locating the option and the object to operate on, handling
the read-only and deprecated flags, and constructing the pointer to the
target value. Some of the functions also do not perform some of the
checks, although they should. E.g. a deprecation warning is currently
only printed for av_opt_set().
Introduce a prologue function that is called from every av_opt_set*()
and performs all these common initialization operations.
Based on a patch by Hacene Bouaroua.
Fixes ticket #11171.
Co-authored-by: Hacene Bouaroua <hbouaroua@freebox.fr>
Signed-off-by: James Almer <jamrial@gmail.com>
Will be used to export certain information present in HEIF samples, like
rotation metadata, ICC profiles, and potentially others.
Signed-off-by: James Almer <jamrial@gmail.com>
Otherwise, things like ICC profiles as read from the colr box meant for an item
with no stream (like a grid) may end up being added to the wrong stream.
Signed-off-by: James Almer <jamrial@gmail.com>
The EXT-X-DISCONTINUITY tag was not being added to subtitle streams,
causing synchronization issues.i
This patch ensures that the tag is applied consistently across video and subtitle streams.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
To streamcopy_init().
This will allow to simplify the control flow in ost_add() by moving the
ost_get_filters() call (which previously had to handle both encoding and
streamcopy streams) to ost_bind_filter() (which is only called for
audio/video encoding).
Also, return EINVAL rather than ENOSYS, as trying to combine filtering
with streamcopy is a parameter error.
Similar to what was previously done for other components, e.g. decoders
(see 3b84140a1b).
Start by moving {samples,frames}_encoded into the public struct.
"int-list" options are a hack that provides rudimentary support for
array-type options by treating them as byte arrays (i.e.
AV_OPT_TYPE_BINARY). Since we now have proper array-type options, they
should replace "int-list" everywhere (which happens to be just
buffersink).
I plan to look after and test them for the forseeable future.
I am not a committer but do care for these muxers/demuxers.
Signed-off-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić <shoutplenty@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In the early return when both draw_bars and signal_loss_action
options are used, the context allocated previously was not
properly freed.
Introduced in 9bcb86b0fa
Fixes CID1619296
Signed-off-by: Marton Balint <cus@passwd.hu>
This function creates AND initializes a filter, so setting any filter
options after it is wrong. It happens to work when the filter's init
function does not touch the options in question, but is forbidden by the
API and is not guaranteed to remain functional.
Instead, use avfilter_graph_alloc_filter(), followed by setting the
options, and avfilter_init_dict().
The function currently writes directly into the input link, which
requires it to be called after the filter has been linked. However, the
documentation does not mention this restriction and the natural place to
call av_buffersink_set_frame_size() during the options-setting stage,
that is before filter init (and so before the input link exists).
This function creates AND initializes a filter, so setting any filter
options after it is wrong. It happens to work when the filter's init
function does not touch the options in question, but is forbidden by the
API and is not guaranteed to remain functional.
Instead, use avfilter_graph_alloc_filter(), followed by setting the
options, and avfilter_init_dict().
The AMF HEVC encoder takes a bool option for whether deblocking filter
should be _disabled_ instead of whether it should _enabled_ like the
AMF H.264 encoder does. The logic was accidentally copied from H.264 to
HEVC without negating the bool value, so the deblocking filter was
actually disabled when AV_CODEC_FLAG_LOOP_FILTER was set.
Before this patch:
------------------
no flags set => deblocking filter on
flags +loop => deblocking filter off
flags -loop => deblocking filter on
After this patch:
-----------------
no flags set => deblocking filter on
flags +loop => deblocking filter on
flags -loop => deblocking filter off
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Since Xcode 15, macOS developer tools use a new linker. The new
linker by default warns for duplicate -l options. As this is a
known and expected thing, not to be considered an issue, ask for
the warning to be silenced.
This silences linker warnings like this:
ld: warning: ignoring duplicate libraries: '-lc++', '-lcrypto', '-lm', '-logg', '-lpthread', '-lssl', '-lvorbis', '-lvpx', '-lz'
The linker can also warn about duplicate -rpath options, and there's
currently no option to silence those warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds a condition that was missed in
b1ee2af843, fixing compilation on
toolchains that don't support SVE.
Signed-off-by: Martin Storsjö <martin@martin.st>
There's no direct processor feature constant for I8MM alone, but
there is a flag for SVE-I8MM (added in WinSDK 10.0.26100 and
recent versions of mingw-w64). If SVE-I8MM is available, we can
assume that I8MM is available.
While HW supporting these features isn't yet commonly running
Windows, this at least allows detecting and running the I8MM codepaths
in Windows builds in Wine (possibly running in QEMU).
Signed-off-by: Martin Storsjö <martin@martin.st>
With this, nothing in ffmpeg_filter acesses OutputStream anymore, thus
there are no more direct ties between filtering and muxing.
Rename init_simple_filtergraph() to fg_create_simple() for consistency.
It is no longer used for anything besides a sanity-checking assert.
Rename the function to ofilter_bind_enc(), as it no longer has any
assumptions about the target being an output stream.
Pass them to ofilter_bind_ost() via OutputFilterOptions, as is done for
most other data it needs. OutputStream.[max_]frame_rate/force_fps are no
longer used outside of ffmpeg_mux*, and so can be made private.
This is a step toward decoupling encoders from muxers.
This code uses no encoder properties or state besides its name, and is
mostly muxer logic, and thus belongs more properly into the muxer.
The results of several test change due to different metadata tag order
(the "encoder" tag is now set first).
Have the muxer code read them out of the encoder context in
of_stream_init() instead.
OutputStream.par_in no longer needs to be public, so can be moved to
MuxStream.
This is a step towards decoupling encoders from muxers.
Instead, pass the encoder context to of_stream_init() and have the muxer
take the timebase from there. Note that the muxer can currently access
the codec context directly, but that will change in future commits.
This is a step towards decoupling encoders from muxers.
The only variable accessed from it is AVCodecContext, which we can
pass directly.
Also, this function currently logs into the AVCodecContext, which is
wrong. Log to Encoder instead.
Log decoder messages to the encoder rather than OutputStream.
This is a step towards decoupling encoders from muxers, similarly to
what was previously done to decoders and demuxers.
The unaligned width test cases fail on i386; we have an assembly
function of rgb24toyv12 which is enabled only within
"#if ARCH_X86_32 && HAVE_7REGS", which seems to fail these new
test cases for unaligned widths.
As that assembly function has existed for a long time in that form,
the issue probably isn't very recent, thus skip testing these cases
for now.
Once the assembly function has been fixed, these test cases can
be readded.
Signed-off-by: Martin Storsjö <martin@martin.st>
The block_buffer was only ever written to but then never used in the
following code, making it unnecessary.
Fixes a "variable 'block_buffer' set but not used" compiler warning.
This was broken in 2fb2cd5c79 and
74553f0026, making a simple make fate-mov fail
and most of the test not run with a simple make fate.
Signed-off-by: James Almer <jamrial@gmail.com>
As VLSE128.V does not exist, we have no other way to deal with latency.
T-Head C908:
h264_weight16_8_c: 989.4 ( 1.00x)
h264_weight16_8_rvv_i32: 193.2 ( 5.12x)
SpacemiT X60:
h264_weight16_8_c: 874.1 ( 1.00x)
h264_weight16_8_rvv_i32: 196.9 ( 4.44x)
The height is a power of two of up to 16 rows. The current code was
optimised for large sample counts.
T-Head C908:
h264_weight2_8_c: 211.7 ( 1.00x)
h264_weight2_8_rvv_i32: before 184.0 ( 1.15x)
h264_weight2_8_rvv_i32: after 54.2 ( 3.90x)
h264_weight4_8_c: 285.7 ( 1.00x)
h264_weight4_8_rvv_i32: before 341.2 ( 0.86x)
h264_weight4_8_rvv_i32: after 82.2 ( 3.47x)
h264_weight8_8_c: 498.7 ( 1.00x)
h264_weight8_8_rvv_i32: before 683.7 ( 0.73x)
h264_weight8_8_rvv_i64: after 128.5 ( 3.95x)
h264_weight16_8_c: 878.2 ( 1.00x)
h264_weight16_8_rvv_i32: unchanged 239.5 ( 3.67x)
SpacemiT X60:
h264_weight2_8_c: 207.2 ( 1.00x)
h264_weight2_8_rvv_i32: before 259.6 ( 0.80x)
h264_weight2_8_rvv_i32: after 82.2 ( 2.52x)
h264_weight4_8_c: 290.8 ( 1.00x)
h264_weight4_8_rvv_i32: before 509.6 ( 0.57x)
h264_weight4_8_rvv_i32: after 61.5 ( 4.73x)
h264_weight8_8_c: 498.8 ( 1.00x)
h264_weight8_8_rvv_i32: before 1019.8 ( 0.49x)
h264_weight8_8_rvv_i64: after 71.8 ( 6.95x)
h264_weight16_8_c: 874.0 ( 1.00x)
h264_weight16_8_rvv_i32: unchanged 249.0 ( 3.51x)
documentation Stefano Sabatini, Mike Melanson, Timothy Gu, Gyan Doshi
project server day to day operations (L: root@ffmpeg.org) Árpád Gereöffy, Michael Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
project server emergencies (L: root@ffmpeg.org) Árpád Gereöffy, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
project server day to day operations (L: root@ffmpeg.org) Michael Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
project server emergencies (L: root@ffmpeg.org) Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler
presets [0]
metadata subsystem Aurelien Jacobs
release management Michael Niedermayer
API tests [0]
samples-request [2] Thilo Borgmann, James Almer, Ben Littler
Communication
@ -82,12 +85,14 @@ Other:
aes_ctr.c, aes_ctr.h Eran Kornblau
bprint Nicolas George
bswap.h
csp.c, csp.h Leo Izen, Ronald S. Bultje
des Reimar Doeffinger
dynarray.h Nicolas George
eval.c, eval.h [2] Michael Niedermayer
float_dsp Loren Merritt
hash Reimar Doeffinger
hwcontext_cuda* Timo Rothenpieler
hwcontext_d3d12va* Wu Jianhua
hwcontext_vulkan* [2] Lynne
intfloat* Michael Niedermayer
integer.c, integer.h Michael Niedermayer
@ -133,8 +138,6 @@ Generic Parts:
ratecontrol.c [2] Michael Niedermayer
simple IDCT:
simple_idct.c, simple_idct.h [2] Michael Niedermayer
postprocessing:
libpostproc/* [2] Michael Niedermayer
table generation:
tableprint.c, tableprint.h Reimar Doeffinger
fixed point FFT:
@ -176,6 +179,7 @@ Codecs:
dss_sp.c Oleksij Rempel
dv.c Roman Shaposhnik
dvbsubdec.c Anshul Maheshwari
dxv.*, dxvenc.* Emma Worley
eacmv*, eaidct*, eat* Peter Ross
exif.c, exif.h Thilo Borgmann
ffv1* [2] Michael Niedermayer
@ -206,7 +210,6 @@ Codecs:
libgsm.c Michel Bardiaux
libkvazaar.c Arttu Ylä-Outinen
libopenh264enc.c Martin Storsjo, Linjie Fu
libopenjpeg.c Jaikrishnan Menon
libopenjpegenc.c Michael Bradshaw
libtheoraenc.c David Conrad
libvorbis.c David Conrad
@ -244,6 +247,7 @@ Codecs:
rpza.c Roberto Togni
rtjpeg.c, rtjpeg.h Reimar Doeffinger
rv10.c Michael Niedermayer
sanm.c Manuel Lauss
smc.c Mike Melanson
snow* Michael Niedermayer, Loren Merritt
sonic.c Alex Beregszaszi
@ -266,7 +270,7 @@ Codecs:
vp8 David Conrad, Ronald Bultje
vp9 Ronald Bultje
vqavideo.c Mike Melanson
vvc [2] Nuo Mi
vvc [2] Nuo Mi, Wu Jianhua, Frank Plowman
wmaprodec.c Sascha Sommer
wmavoice.c Ronald S. Bultje
wmv2.c Michael Niedermayer
@ -276,6 +280,7 @@ Codecs:
Hardware acceleration:
dxva2* Hendrik Leppkes, Laurent Aimar, Steve Lhomme
d3d11va* Steve Lhomme
d3d12va* Wu Jianhua
d3d12va_encode* Tong Wu
mediacodec* Matthieu Bouron, Aman Gupta, Zhao Zhili
vaapi* Haihao Xiang
@ -391,7 +396,7 @@ Muxers/Demuxers:
dss.c Oleksij Rempel
dtsdec.c foo86
dv.c Roman Shaposhnik
dvdvideodec.c Marth64
dvdvideodec.c [2] Marth64
electronicarts.c Peter Ross
evc* Samsung (Dawid Kozinski)
ffm* Baptiste Coudurier
@ -445,7 +450,8 @@ Muxers/Demuxers:
pva.c Ivo van Poorten
r3d.c Baptiste Coudurier
raw.c Michael Niedermayer
rcwtenc.c Marth64
rcwtdec.c [2] Marth64
rcwtenc.c [2] Marth64
rdt.c Ronald S. Bultje
rl2.c Sascha Sommer
rmdec.c, rmenc.c Ronald S. Bultje
@ -464,6 +470,7 @@ Muxers/Demuxers:
sdp.c Martin Storsjo
segafilm.c Mike Melanson
segment.c Stefano Sabatini
smush.c Manuel Lauss
spdif* Anssi Hannula
srtdec.c Aurelien Jacobs
swf.c Baptiste Coudurier
@ -511,9 +518,10 @@ Operating systems / CPU architectures
Alpha [0]
MIPS Manojkumar Bhosale, Shiyou Yin
LoongArch [2] Shiyou Yin
Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier
@ -189,6 +189,52 @@ see page 44-46 or section 5.5 of
Extract the core from a E-AC-3 stream, dropping extra channels.
@section eia608_to_smpte436m
Convert from a @code{EIA_608} stream to a @code{SMPTE_436M_ANC} data stream, wrapping the closed captions in CTA-708 CDP VANC packets.
@table @option
@item line_number
Choose which line number the generated VANC packets should go on. You generally want either line 9 (the default) or 11.
@item wrapping_type
Choose the SMPTE 436M wrapping type, defaults to @samp{vanc_frame}.
It accepts the values:
@table @samp
@item vanc_frame
VANC frame (interlaced or segmented progressive frame)
@item vanc_field_1
@item vanc_field_2
@item vanc_progressive_frame
@end table
@item sample_coding
Choose the SMPTE 436M sample coding, defaults to @samp{8bit_luma}.
It accepts the values:
@table @samp
@item 8bit_luma
8-bit component luma samples
@item 8bit_color_diff
8-bit component color difference samples
@item 8bit_luma_and_color_diff
8-bit component luma and color difference samples
@item 10bit_luma
10-bit component luma samples
@item 10bit_color_diff
10-bit component color difference samples
@item 10bit_luma_and_color_diff
10-bit component luma and color difference samples
@item 8bit_luma_parity_error
8-bit component luma samples with parity error
@item 8bit_color_diff_parity_error
8-bit component color difference samples with parity error
@item 8bit_luma_and_color_diff_parity_error
8-bit component luma and color difference samples with parity error
@end table
@item initial_cdp_sequence_cntr
The initial value of the CDP's 16-bit unsigned integer @code{cdp_hdr_sequence_cntr} and @code{cdp_ftr_sequence_cntr} fields. Defaults to 0.
@item cdp_frame_rate
Set the CDP's @code{cdp_frame_rate} field. This doesn't actually change the timing of the data stream, it just changes the values inserted in that field in the generated CDP packets. Defaults to @samp{30000/1001}.
@end table
@section extract_extradata
Extract the in-band extradata.
@ -423,9 +469,21 @@ Please note that this filter is auto-inserted for MPEG-TS (muxer
@section h264_redundant_pps
This applies a specific fixup to some Blu-ray streams which contain
redundant PPSs modifying irrelevant parameters of the stream which
confuse other transformations which require correct extradata.
This applies a specific fixup to some Blu-ray BDMV H264 streams
which contain redundant PPSs. The PPSs modify irrelevant parameters
of the stream, confusing other transformations which require
the correct extradata.
The encoder used on these impacted streams adds extra PPSs throughout
the stream, varying the initial QP and whether weighted prediction
was enabled. This causes issues after copying the stream into
a global header container, as the starting PPS is not suitable
for the rest of the stream. One side effect, for example,
is seeking will return garbled output until a new PPS appears.
This BSF removes the extra PPSs and rewrites the slice headers
such that the stream uses a single leading PPS in the global header,
@ -292,7 +292,6 @@ DVD-Video demuxer, powered by libdvdnav and libdvdread.
Can directly ingest DVD titles, specifically sequential PGCs, into
a conversion pipeline. Menu assets, such as background video or audio,
can also be demuxed given the menu's coordinates (at best effort).
Seeking is not supported at this time.
Block devices (DVD drives), ISO files, and directory structures are accepted.
Activate with @code{-f dvdvideo} in front of one of these inputs.
@ -380,11 +379,11 @@ Default is false.
@item menu_lu @var{int}
The menu language to demux. In DVD, menus are grouped by language.
Default is 0, the first language unit.
Default is 1, the first language unit.
@item menu_vts @var{int}
The VTS where the menu lives, or 0 if it is a VMG menu (root-level).
Default is 0, VMG menu.
Default is 1, menu of the first VTS.
@item pgc @var{int}
The entry PGC to start playback, in conjunction with @option{pg}.
@ -397,8 +396,7 @@ Default is 0, automatically resolve from value of @option{title}.
The entry PG to start playback, in conjunction with @option{pgc}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
Default is 0, automatically resolve from value of @option{title}, or
start from the beginning (PG 1) of the menu.
Default is 1, the first PG of the PGC.
@item preindex @var{bool}
Enable this to have accurate chapter (PTT) markers and duration measurement,
@ -406,7 +404,6 @@ which requires a slow second pass read in order to index the chapter marker
timestamps from NAV packets. This is non-ideal extra work for real optical drives.
It is recommended and faster to use this option with a backup of the DVD structure
stored on a hard drive. Not compatible with @option{pgc} and @option{pg}.
Not applicable to menus.
Default is 0, false.
@item trim @var{bool}
@ -567,6 +564,13 @@ prefer to use #EXT-X-START if it's in playlist instead of live_start_index.
@item allowed_extensions
',' separated list of file extensions that hls is allowed to access.
@item extension_picky
This blocks disallowed extensions from probing
It also requires all available segments to have matching extensions to the format
except mpegts, which is always allowed.
It is recommended to set the whitelists correctly instead of depending on extensions
Enabled by default.
@item max_reload
Maximum number of times a insufficient list is attempted to be reloaded.
Default value is 1000.
@ -851,6 +855,32 @@ Set the sample rate for libopenmpt to output.
Range is from 1000 to INT_MAX. The value default is 48000.
@end table
@anchor{mccdec}
@section mcc
Demuxer for MacCaption MCC files, it supports MCC versions 1.0 and 2.0.
MCC files store VANC data, which can include closed captions (EIA-608 and CEA-708), ancillary time code, pan-scan data, etc.
By default, for backward compatibility, the MCC demuxer extracts just the EIA-608 and CEA-708 closed captions and returns a @code{EIA_608} stream, ignoring all other VANC data.
You can change it to return all VANC data in a @code{SMPTE_436M_ANC} data stream by setting @option{-eia608_extract 0}
@subsection Examples
@itemize
@item
Convert a MCC file to Scenarist (SCC) format:
@example
ffmpeg -i CC.mcc -c:s copy CC.scc
@end example
Note that the SCC format only supports EIA-608, so this will discard all other data such as CEA-708 extensions.
However no spaces between the parentheses and condition, unless it helps
readability of complex conditions, so the following should not be done:
@example c, bad
// Bad style
if ( condition )
av_foo();
@end example
@item
No unnecessary parentheses, unless it helps readability:
@example c, good
// Good
int fields = ilace ? 2 : 1;
@end example
@item
Don't wrap single-line blocks in braces. Use braces only if there is an accompanying else statement. This keeps future code changes easier to keep track of.
@example c, good
// Good
if (bits_pixel == 24) @{
avctx->pix_fmt = AV_PIX_FMT_BGR24;
@} else if (bits_pixel == 8) @{
avctx->pix_fmt = AV_PIX_FMT_GRAY8;
@} else
return AVERROR_INVALIDDATA;
@end example
@item
Avoid assignments in conditions where it makes sense:
- use av_cpu_max_align() instead of hardcoding alignment requirements (see https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215834.html)
- f44ec22e0 lavc: use av_cpu_max_align() instead of hardcoding alignment requirements
- 4de220d2e frame: allow align=0 (meaning automatic) for av_frame_get_buffer()
- Support recovery from an already present HLS playlist (see 16cb06bb30)
- Remove all output devices (see 8e7e042d41, 8d3db95f20, 6ce13070bd, d46cd24986 and https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216904.html)
- avcodec/libaomenc: export the Sequence Header OBU as extradata (See a024c3ce9a)
Collateral damage that needs work locally:
------------------------------------------
- Merge proresenc_anatoliy.c and proresenc_kostya.c
- Fix MIPS AC3 downmix
Extra changes needed to be aligned with Libav:
----------------------------------------------
- Switching our examples to the new encode/decode API (see 67d28f4a0f)
- HEVC IDCT bit depth 12-bit support (Libav added 8 and 10 but doesn't have 12)
