eg. `uv -c jpegxs` (only)
broken since 942a76725 (2026-02-24)
The `stop` var was actually needed this so revert this occurence but
improve to push to the encoder just if configured.
Do not bypass the queue by passing empty frame (poison pill) directly to
output queue but leave it passing normally through the pipeline ending
what is needed.
The output queue now can be 1 frame long.
This prevents accumulating frames when not being able to send the frame
at given pace (eg. `-l 10M` and bitrate=20M - this is just an approxmation,
clearly user won't set this but can occur eg. when coonected to 100M
link while the default bittrate is higher for FHD).
if unknown parameter is passed, use more accurate err emssage
- also use ERROR in gpujpeg
- while IS_KEY_PREFIX is used, it can be also missing value to a known
parameter (eg. jpegxs:bitrate) so mention this as well
fix 697d4bdb (2026-02-23), CID 900814
If parameter without value is passed, atoi(1) is called causing
crash. Currently, all of the parameters (except "help", which is already
handled) should have a value. But user may enter incorrectly a parameter
without value, eg. "blabla" causing the crash.
to be able to compile normally without setting std in CFLAGS
+ remove it from macos-14 CI
clang 15 as in macOS 14 doesn't support c23 [[attributes]] such as
[[gnu::always_inline]]
that seem to make a difference as for tool/benchmark_ff_convs (tested
again on x64 with gcc and arm64 with clang)
+ allow setting CFLAGS/CXXFLAGS from cmdline
most of the optimizations is applied just for clang (OPTIMIZED_FOR)
It is not necessary to apply the flags to all - some conversions seem
to be faster without, eg. gbrap->RGB(A).
-Ofast is basically -O3 + -ffast-math
But from my measurements (x64 gcc and arm64 clang), it doesn't make
any difference as tested with `tools/convert benchmark`. Actually,
currently almost no conversion uses floating point math except of
vc_copylineUYVYtoRGBA, for which the -ffast-math didn't have any
performance impact.
Improves the commit 4136c263 from last week - we usually expect gnu
extensions, although doesn't seem to cause problems in this case (but eg.
the asm keywords won't work /not used here because is arm64/ - __asm__
would be required instead).
only for Win + non-ARM Linux - doesn't seem to be officially supported
in neither ARM nor macOS
configure.ac - require just SVT-JPEG-XS 0.9 as is in msys Win package
(proxy mode commented out - isn't needed to set to "proxy_mode_full"
explicitly, anyways)
This should be the last compat needed (in respect to the encoder producing
4:2:0 only in 8-bit - lavc encoder is not considered but it will likely
work just with encoded UYVY, anyways).
