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>
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>
"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>
The x86 optimized dct_quantize only calculates the last nonzero
coefficient correctly if the zigzag scan order is used. For the
alternate scan order, this value is incorrect.
To work around this, the dct_unquantize functions process the entire
block if the alternate scan order is used.
But a second workaround (bb198e198a) was added that recalculates the
last nonzero coefficient after dct_quantize is called if the alternate
scan order is used.
This commit removes the first workaround, which became redundant.
It's safe to assume that LOCAL_ALIGNED_16 does indeed align. Otherwise
we would have many more problems...
This assert was added in f8188626 all the way back in 2003.
Implement load/save loop filter and segment parameters defined in
section 7.20 and 7.21 in spec for show_existing_frame frames.
Fixes ticket #11151.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
add more stringent restrictions. when pause, do not
enqueuebuffer to the driver. This cen avoid the problem
of noise caused by pause twice.
Signed-off-by: cenzhanquan1 <cenzhanquan1@xiaomi.com>
BDoF used about 10%–25% of the CPU for some clips.
Here are the FPS for one run; please ignore the negative values, as they may be due to round-to-round variation
clips | before | after | delta
--------------------------------------------|--------|-------|------
RitualDance_1920x1080_60_10_420_37_RA.266 | 310.0 | 363.0 | 14.60%
NovosobornayaSquare_1920x1080.bin | 322.3 | 339.7 | 5.12%
Tango2_3840x2160_60_10_420_27_LD.266 | 71.0 | 68.7 | -3.35%
RitualDance_1920x1080_60_10_420_32_LD.266 | 250.0 | 245.3 | -1.92%
Chimera_8bit_1080P_1000_frames.vvc | 359.3 | 422.7 | 15.00%
BQTerrace_1920x1080_60_10_420_22_RA.vvc | 142.3 | 147.7 | 3.66%
Reviewed-by: James Almer <jamrial@gmail.com>
The color range should be set to match the input when creating
the VideoToolbox context. Otherwise, the new context will default
to limited range, creates inconsistencies with full range inputs.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Decoder-Side Motion Vector Refinement is about 4~8% CPU usage for some clips
here is the test result for one time
clips | before| after | delta
------------------------------------------|-------|-------|------
RitualDance_1920x1080_60_10_420_37_RA.266 | 338.7 | 354.3 |4.61%
NovosobornayaSquare_1920x1080.bin | 320.3 | 329.3 |2.81%
Tango2_3840x2160_60_10_420_27_LD.266 | 83.3 | 83.7 |0.48%
RitualDance_1920x1080_60_10_420_32_LD.266 | 320.7 | 327.3 |2.06%
Chimera_8bit_1080P_1000_frames.vvc | 360.7 | 381.0 |5.63%
BQTerrace_1920x1080_60_10_420_22_RA.vvc | 161.7 | 163.0 |0.80%
Callers of ff_framesync_get_frame() generally do not expect the result
to be writable, those that do (e.g. ff_framesync_dualinput_get_writable())
ensure writability themselves.
Significantly reduces memory consumption in complex graphs with
framesync-based filters (e.g. scale, ssim).
Reported-By: Mark Shwartzman
openvela-robot