| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Do not use larger fields than needed, use size-1 bitfields for flags.
Reduces sizeof(HEVCSPS) by 1280 bytes.
|
|
|
|
|
|
|
| |
It is currently an array of 32 uint8_t, each storing a single flag. A
single uint32_t is sufficient.
Reduces sizeof(HEVCSPS) by 1792 bytes.
|
|
|
|
|
|
|
|
|
| |
They are only used in vulkan_hevc and are not actually needed, as they
can be computed from delta_poc.
Reduces sizeof(HEVCSPS) by 16kB.
Also, fix a typo (s0->s1) in the code being touched.
|
|
|
|
|
|
| |
It is actually supposed to go negative in the loop over num_negative
pics, but underflow does not break anything as the result is then
assigned to a signed int.
|
|
|
|
|
|
|
| |
Reduces sizeof(HEVCSPS) by 64 bytes.
Also improve flag names: drop redundant suffixes and prefixes, and
consistently use disabled/enabled.
|
|
|
|
|
| |
It is currently an array of 32 uint8_t, each storing a single flag. A
single uint32_t is sufficient.
|
| |
|
|
|
|
| |
It is more efficient and easier to manage.
|
|
|
|
| |
The latter can be lowered while decoding, which would lead to memleaks.
|
|
|
|
| |
It is more consistent with our naming conventions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ab77b878f1 attempted to fix the issue of broken packets being sent to
the decoder by implementing logic that kept attempting to PTS-step
backwards until it reached a valid point, however applying this
heuristic meant that in files that had no valid points (such as HEVC
videos shot on iPhones), we'd seek back to sample 0 on every seek
attempt. This meant that files that were previously seekable, albeit
with some skipped frames, were not seekable at all now.
Relax this heuristic a bit by giving up on seeking to a valid point if
we've tried a different sample and we still don't have a valid point to
seek to. This may some frames to be skipped on seeking but it's better
than not being able to seek at all in such files.
Fixes: ab77b878f1 ("avformat/mov: fix seeking with HEVC open GOP files")
Fixes: #10585
Signed-off-by: Philip Langdale <philipl@overt.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C908:
vp9_avg4_8bpp_c: 1.2
vp9_avg4_8bpp_rvv_i64: 1.0
vp9_avg8_8bpp_c: 3.7
vp9_avg8_8bpp_rvv_i64: 1.5
vp9_avg16_8bpp_c: 14.7
vp9_avg16_8bpp_rvv_i64: 3.5
vp9_avg32_8bpp_c: 57.7
vp9_avg32_8bpp_rvv_i64: 10.0
vp9_avg64_8bpp_c: 229.0
vp9_avg64_8bpp_rvv_i64: 31.7
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While this function can easily be written with vectors, it just fails to
get any performance improvement.
For reference, this is a simpler loop-free implementation that does get
better performance than the current one depending on hardware, but still
more or less the same metrics as the C code:
func ff_sbr_neg_odd_64_rvv, zve64x
li a1, 32
addi a0, a0, 7
li t0, 8
vsetvli zero, a1, e8, m2, ta, ma
li t1, 0x80
vlse8.v v8, (a0), t0
vxor.vx v8, v8, t1
vsse8.v v8, (a0), t0
ret
endfunc
This reverts commit d06fd18f8f4c6a81ef94cbb600620d83ad51269d.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notes:
- The loop is biased toward no unescaped bytes as that should be most common.
- The input byte array is slid rather than the (8 times smaller) bit-mask,
as RISC-V V does not provide a bit-mask (or bit-wise) slide instruction.
- There are two comparisons with 0 per iteration, for the same reason.
- In case of match, bytes are copied until the first match, and the loop is
restarted after the escape byte. Vector compression (vcompress.vm) could
discard all escape bytes but that is slower if escape bytes are rare.
Further optimisations should be possible, e.g.:
- processing 2 bytes fewer per iteration to get rid of a 2 slides,
- taking a short cut if the input vector contains less than 2 zeroes.
But this is a good starting point:
T-Head C908:
vc1dsp.vc1_unescape_buffer_c: 12749.5
vc1dsp.vc1_unescape_buffer_rvv_i32: 6009.0
SpacemiT X60:
vc1dsp.vc1_unescape_buffer_c: 11038.0
vc1dsp.vc1_unescape_buffer_rvv_i32: 2061.0
|
|
|
|
|
|
|
|
|
|
| |
The loop filters can write before the pointer given to them;
the actual test invocations correctly used an offset, while
the benchmark calls were lacking an offset. Therefore, when
running with benchmarking, these tests could have spurious
failures.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Helps make sense of the possible noise in the results.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some timers on certain device and test combinations can produce noisy
results, affecting the reliability of performance measurements. One
notable example of this is the Canaan K230 RISC-V development board.
An option to adjust the number of samples by an exponent (--runs) has
been added, allowing developers to increase the sample count for more
reliable results.
Signed-off-by: J. Dekker <jdek@itanimul.li>
|
|
|
|
|
|
|
|
|
|
|
| |
Don't benchmark every single combination of widths and heights;
only benchmark cases which are squares (like in vvc_mc.c).
Contrary to vvc_mc, which increases sizes by doubling dimensions,
vvc_alf tests all sizes in increments of 4. Limit benchmarking to
the cases which are powers of two.
This reduces the number of benchmarked cases from 3072 down to 18.
|
|
|
|
| |
see https://dvb.org/specifications/verification-validation/vvc-test-content/
|
|
|
|
|
|
|
|
|
| |
passed clips:
RPR_A_Alibaba_4.bit
RPR_B_Alibaba_3.bit
RPR_C_Alibaba_3.bit
RPR_D_Qualcomm_1.bit
VVC_HDR_UHDTV1_OpenGOP_Max3840x2160_50fps_HLG10_res_change_with_RPR.ts
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
For RPR, the current frame may reference a frame with a different resolution.
Therefore, we need to consider frame scaling when we wait for reference pixels.
|
| |
|
|
|
|
| |
a preparation for Reference Picture Resampling
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
EMULATED_EDGE_DMVR_{LUAM, CHROMA}
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
|
|
|
|
| |
Matches other hwaccels.
|
|
|
|
|
| |
Tested-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: oltolm <oleg.tolmatcev@gmail.com>
|
|
|
|
|
|
| |
Also use loop scope for iterators while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
| |
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
|
|
|
|
|
|
| |
Because of ffio_ensure_seekback() a seek error normally should only happen if
the end of file is reached during checking for the junk run-in. Also use proper
error code.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
|
|
| |
We are protecting the checked buffer with ffio_ensure_seekback(), so if the
inner check fails with a seek error, that likely means the end of file was
reached when checking for the next frame. This could also be the result of a
wrongly guessed (larger than normal) frame size, so let's continue the loop
instead of breaking out early. It will end sooner or later anyway.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the subsequent ffio_ensure_seekback calls destroy the buffer of the
earlier. The worst case ~66kB seekback is so small it is easier to request it
entirely.
Fixes ticket #10837, a regression since
0d17f5228f4d3854066ec1001f69c7d1714b0df9.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
| |
Signed-off-by: LuMingYin <lumingyindetect@163.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
|
|
|
|
|
| |
Signed-off-by: LuMingYin <lumingyindetect@163.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
|
|
|
|
|
|
| |
Signed-off-by: LuMingYin <lumingyindetect@163.com>
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
|
|
|
|
|
| |
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
| |
Should fix many Coverity false positives, namely #1457947-#1457994
as well as #1461195-#146210.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|