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)
