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>
