updated for clean code
于2024年5月15日周三 11:56写道：
> From: sunyuechi
>
> C908:
> vp9_tm_4x4_8bpp_c: 116.5
> vp9_tm_4x4_8bpp_rvv_i32: 43.5
> vp9_tm_8x8_8bpp_c: 416.2
> vp9_tm_8x8_8bpp_rvv_i32: 86.0
> vp9_tm_16x16_8bpp_c: 1665.5
> vp9_tm_16x16_8bpp_rvv_i32: 187.2
> vp9_tm_32x32_8bpp_c: 6974.2
> vp9_tm
From: sunyuechi
C908:
vp9_tm_4x4_8bpp_c: 116.5
vp9_tm_4x4_8bpp_rvv_i32: 43.5
vp9_tm_8x8_8bpp_c: 416.2
vp9_tm_8x8_8bpp_rvv_i32: 86.0
vp9_tm_16x16_8bpp_c: 1665.5
vp9_tm_16x16_8bpp_rvv_i32: 187.2
vp9_tm_32x32_8bpp_c: 6974.2
vp9_tm_32x32_8bpp_rvv_i32: 625.7
---
libavcodec/riscv/vp9_intra_rvv.S | 118
Fixes "signed integer overflow: [varies] * 104858 cannot be represented in type
'int'" errors
under ubsan.
Signed-off-by: James Almer
---
tests/checkasm/h264dsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index cb180c
On Wed, 15 May 2024 01:36:43 +0530
llyyr.pub...@gmail.com wrote:
> From: llyyr
>
> 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
> heuris
Hiccup Zhu:
> The purpose of this patch is to calculate pts and dts when using pcmdemux.
> Is there anything wrong with doing this, or do you have any suggestions for
> improvement?
>
1. Don't top-post on this list.
2. PTS and DTS are already produced with this demuxer. As has been said:
If it is
The purpose of this patch is to calculate pts and dts when using pcmdemux.
Is there anything wrong with doing this, or do you have any suggestions for
improvement?
Andreas Rheinhardt 于2024年5月14日周二 19:41写道：
> Shiqi Zhu:
> > Signed-off-by: Shiqi Zhu
> > ---
> > libavformat/pcmdec.c | 37
Signed-off-by: James Almer
---
libavformat/movenc.c | 61
1 file changed, 61 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index f907f67752..2aec9a8d17 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -916,6 +91
Signed-off-by: James Almer
---
libavutil/channel_layout.c | 17 -
libavutil/channel_layout.h | 10 ++
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index fd6718e0e7..e213f68666 100644
--- a/libavutil
On 18/04/2024 09:59, tong1.wu-at-intel@ffmpeg.org wrote:
> From: Tong Wu
>
> Signed-off-by: Tong Wu
> ---
> libavcodec/hw_base_encode.c | 11 +++
> libavcodec/hw_base_encode.h | 2 ++
> libavcodec/vaapi_encode.c | 6 +-
> 3 files changed, 14 insertions(+), 5 deletions(-)
".
On 18/04/2024 09:59, tong1.wu-at-intel@ffmpeg.org wrote:
> From: Tong Wu
>
> Surface size and block size parameters are also moved to base layer.
>
> Signed-off-by: Tong Wu
> ---
> libavcodec/hw_base_encode.c | 58 +++
> libavcodec/hw_base_encode.h | 12 +
>
T-Head C908:
flac_wasted_33_c: 786.2
flac_wasted_33_rvv_i64: 486.5
---
libavcodec/riscv/flacdsp_init.c | 4
libavcodec/riscv/flacdsp_rvv.S | 32
2 files changed, 36 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_
T-Head C908:
flac_wasted_32_c: 949.0
flac_wasted_32_rvv_i32: 278.7
---
libavcodec/riscv/flacdsp_init.c | 7 ++-
libavcodec/riscv/flacdsp_rvv.S | 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp
On 18/04/2024 09:59, tong1.wu-at-intel@ffmpeg.org wrote:
> From: Tong Wu
>
> Related parameters are also moved to base layer.
>
> Signed-off-by: Tong Wu
> ---
> libavcodec/hw_base_encode.c | 33
> libavcodec/hw_base_encode.h | 11 ++
> libavcodec/vaapi_encode.c
On 18/04/2024 09:58, tong1.wu-at-intel@ffmpeg.org wrote:
> From: Tong Wu
>
> Move receive_packet function to base. This requires adding *alloc,
> *issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
> introduced as the base layer structure. The related parameters in
> VAAPIEnc
Adds checkasm for DMVR SAD AVX2 implementation.
Benchmarks ( AMD 7940HS )
vvc_sad_8x8_c: 63.0
vvc_sad_8x8_avx2: 3.0
vvc_sad_16x16_c: 263.0
vvc_sad_16x16_avx2: 23.0
vvc_sad_32x32_c: 1003.0
vvc_sad_32x32_avx2: 83.0
vvc_sad_64x64_c: 3923.0
vvc_sad_64x64_avx2: 373.0
vvc_sad_128x128_c: 17533.0
vvc_sad_
Implements AVX2 DMVR (decoder-side motion vector refinement) SAD functions.
DMVR SAD is only calculated if w >= 8, h >= 8, and w * h > 128. To reduce
complexity, SAD is only calculated on even rows. This is calculated for all
video bitdepths, but the values passed to the function are always 16bi
Le sunnuntaina 12. toukokuuta 2024, 22.54.21 EEST Rémi Denis-Courmont a écrit
:
> T-Head C908:
> flac_wasted_33_c: 786.2
> flac_wasted_33_rvv_i64: 486.5
Fails with a minority of checkasm seeds.
--
Rémi Denis-Courmont
http://www.remlab.net/
__
Pointed-out-by: Stefan O'Rear
---
libavutil/riscv/cpu.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 7b8aa7ac21..04ac404bbf 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -77,8 +77,12 @@ int ff_g
From: llyyr
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
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
---
libavformat/mp3dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
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
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
---
libavformat/mp
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
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
On 18/04/2024 09:58, tong1.wu-at-intel@ffmpeg.org wrote:
> From: Tong Wu
>
> Since VAAPI and future D3D12VA implementation may share some common
> parameters,
> a base layer encode context is introduced as vaapi context's base.
>
> Signed-off-by: Tong Wu
> ---
> libavcodec/hw_base_encode.
On Mon, 13 May 2024, Andreas Rheinhardt wrote:
Forgotten in 5b8faaad6c71bbb90951ca1642391e11cf6f5f91.
Signed-off-by: Andreas Rheinhardt
---
tests/checkasm/vf_blend.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blen
Le tiistaina 14. toukokuuta 2024, 22.35.57 EEST Rémi Denis-Courmont a écrit :
> This calculates the optimal vector type value at run-time based on the
> hardware vector length and the FLAC LPC prediction order. In this
> particular case, the additional computation is easily amortised over
> the loo
On Tue, 14 May 2024, Michael Riedl wrote:
Deprecate the option 'draw_bars' in favor of the new option
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains uncha
---
libavutil/riscv/asm.S | 48 +--
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S
index 14be5055f5..ecf3081e61 100644
--- a/libavutil/riscv/asm.S
+++ b/libavutil/riscv/asm.S
@@ -96,20 +96,38 @@
This calculates the optimal vector type value at run-time based on the
hardware vector length and the FLAC LPC prediction order. In this
particular case, the additional computation is easily amortised over
the loop iterations:
T-Head C908: CV before V after
flac_lpc_16_13: 1418
> The macro saves some copycat code, but it seems to prevent good
scheduling.
> Consuming t3 right after loading it is not ideal.
> OTOH, it seems that you could just write the tm_sum32 with a single
parameter,
> as the other ones are just relative by constant +/-1.
Okay, updated it in the reply
From: sunyuechi
C908:
vp9_tm_4x4_8bpp_c: 116.5
vp9_tm_4x4_8bpp_rvv_i32: 43.5
vp9_tm_8x8_8bpp_c: 416.2
vp9_tm_8x8_8bpp_rvv_i32: 86.0
vp9_tm_16x16_8bpp_c: 1665.5
vp9_tm_16x16_8bpp_rvv_i32: 187.2
vp9_tm_32x32_8bpp_c: 6974.2
vp9_tm_32x32_8bpp_rvv_i32: 625.7
---
libavcodec/riscv/vp9_intra_rvv.S | 123
Le tiistaina 14. toukokuuta 2024, 20.57.17 EEST flow gg a écrit :
> Why is it unnecessary to reset the vector configuration every time? I think
> it is necessary to reset e16/e8 each time.
I misread the placement of .endm
OTOH, it seems that you could just write the tm_sum32 with a single paramet
Why is it unnecessary to reset the vector configuration every time? I think
it is necessary to reset e16/e8 each time.
Rémi Denis-Courmont 于2024年5月15日周三 01:46写道：
> Le maanantaina 13. toukokuuta 2024, 19.59.21 EEST u...@foxmail.com a
> écrit :
> > From: sunyuechi
> >
> > C908:
> > vp9_tm_4x4_8bp
Le maanantaina 13. toukokuuta 2024, 19.59.21 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908:
> vp9_tm_4x4_8bpp_c: 116.5
> vp9_tm_4x4_8bpp_rvv_i32: 43.5
> vp9_tm_8x8_8bpp_c: 416.2
> vp9_tm_8x8_8bpp_rvv_i32: 86.0
> vp9_tm_16x16_8bpp_c: 1665.5
> vp9_tm_16x16_8bpp_rvv_i32: 187.2
> vp9_tm_
AAC uses an unconventional system to send scalefactors
(the volume+quantization value for each band).
Each window is split into either 1 or 8 blocks (long vs short),
and transformed separately from one another, with the coefficients
for each being also completely independent. The scalefactors
sligh
Okay, learned it
Rémi Denis-Courmont 于2024年5月15日周三 01:00写道：
> Le tiistaina 14. toukokuuta 2024, 7.45.29 EEST flow gg a écrit :
> > I am locally using:
> > if (bpp == 8 && (flags & AV_CPU_FLAG_RVI) && (flags &
> > AV_CPU_FLAG_RVB_ADDR)) {
>
> There is no point testing the I flag if you test a
Using this will give output `if (bpp == 8 && (flags & AV_CPU_FLAG_RVI)) {`
Did you comment out the MISALIGNED flag check but not add RVI, resulting in
no output?
Rémi Denis-Courmont 于2024年5月15日周三 01:02写道：
> Le tiistaina 14. toukokuuta 2024, 7.44.55 EEST flow gg a écrit :
> > I am locally using:
Am 14.05.24 um 19:14 schrieb J. Dekker:
Thilo Borgmann via ffmpeg-devel writes:
---
This text including the link is also meant to be published via our socal media.
src/index | 8
1 file changed, 8 insertions(+)
diff --git a/src/index b/src/index
index d035ffa..83cc9bf 100644
---
Thilo Borgmann via ffmpeg-devel writes:
> ---
> This text including the link is also meant to be published via our socal
> media.
>
> src/index | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/index b/src/index
> index d035ffa..83cc9bf 100644
> --- a/src/index
> +++ b/src/
---
This text including the link is also meant to be published via our socal media.
src/index | 8
1 file changed, 8 insertions(+)
diff --git a/src/index b/src/index
index d035ffa..83cc9bf 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,14 @@
News
+ May 13th, 2024, Sover
Le tiistaina 14. toukokuuta 2024, 7.44.55 EEST flow gg a écrit :
> I am locally using:
> if (bpp == 8 && (flags & AV_CPU_FLAG_RVI)) {
> this performs better on k230/banana_f3 than C.
> For email, refer to [FFmpeg-devel] [PATCH 2/2] lavc/vp8dsp: restrict RVI
> optimisations and change it to
>
Le tiistaina 14. toukokuuta 2024, 7.45.29 EEST flow gg a écrit :
> I am locally using:
> if (bpp == 8 && (flags & AV_CPU_FLAG_RVI) && (flags &
> AV_CPU_FLAG_RVB_ADDR)) {
There is no point testing the I flag if you test any other flag. The I flag is
always set (since we don't, and probably nev
Le lauantaina 11. toukokuuta 2024, 17.41.52 EEST Rémi Denis-Courmont a écrit :
> Not all C run-times support this, and even then, it will be a while
> before distributions provide recent enough versions thereof.
Merged. The FATE box should now have working hardware detection.
--
レミ・デニ-クールモン
http
Christian Bartnik:
> From: Thomas Siedel
>
> Add external encoder VVenC for H266/VVC encoding.
> Register new encoder libvvenc.
> Add libvvenc to wrap the vvenc interface.
> libvvenc implements encoder option: preset,qp,period,subjopt,
> vvenc-params,levelidc,tier.
> Enable encoder by adding --en
On 14/05/2024 17:09, Christian Bartnik wrote:
From: Thomas Siedel
Add external decoder VVdeC for H266/VVC decoding.
Register new decoder libvvdec.
Add libvvdec to wrap the vvdec interface.
Enable decoder by adding --enable-libvvdec in configure step.
Co-authored-by: Christian Bartnik chris1031
Devin Heitmueller writes:
> On Wed, Apr 24, 2024 at 10:10 AM J. Dekker wrote:
>>
>> Signed-off-by: J. Dekker
>> ---
>> tests/checkasm/h264dsp.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
>> index 0f484e
From: Thomas Siedel
Add external decoder VVdeC for H266/VVC decoding.
Register new decoder libvvdec.
Add libvvdec to wrap the vvdec interface.
Enable decoder by adding --enable-libvvdec in configure step.
Co-authored-by: Christian Bartnik chris1031...@gmail.com
Signed-off-by: Christian Bartnik
From: Thomas Siedel
Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,period,subjopt,
vvenc-params,levelidc,tier.
Enable encoder by adding --enable-libvvenc in configure step.
C
This patchset is based on the latest patchset from Thomas Siedel
(thomas...@spin-digital.com).
Since almost all changes from the patchset but libvvenc and libvvdec has been
merged this patch only implements the libvvenc and libvvdec wrapper
implementation.
As ffmpeg already has it´s own vvc decoder
Shiqi Zhu:
> Signed-off-by: Shiqi Zhu
> ---
> libavformat/pcmdec.c | 37 +++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
> index 2f6508b75a..d879aefaad 100644
> --- a/libavformat/pcmdec.c
> +++
Signed-off-by: Shiqi Zhu
---
libavformat/pcmdec.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index 2f6508b75a..d879aefaad 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -36
Le 14 mai 2024 10:37:20 GMT+03:00, "Tomas Härdin" a écrit :
>Formal methods would be better than the heuristics coverity uses.
That sounds like wishful thinking, or at least a distant pipe dream. Lets stick
to what is possible and realistic today, please.
And I don't think that it would be re
On Mon, May 13, 2024 at 8:32 PM wrote:
> From: Wu Jianhua
>
> Perforamnce Test (fps):
> clip before after delta
> Tango2_3840x2160_60_10_420_27_LD.266 56 115 105.36%
> RitualDance_1920x1080_60_10_420_32_LD.266 272 481 76.83%
> RitualDance_1
Deprecate the option 'draw_bars' in favor of the new option
'signal_loss_action',
which controls the behavior when the input signal is not available
(including the behavior previously available through draw_bars).
The default behavior remains unchanged to be backwards compatible.
The new option is
Hi,
This patch adds the possibility to specify an action to be taken when a signal
loss is detected on a decklink device.
Version 3 of this patch fixes a memory leak present in v2. Thanks to Marton
Balint for reviewing the patch.
Kind regards,
Michael
Michael Riedl (1):
libavdevice/decklink
Stop gap solution. I don't know enough about mpegvideo_enc to provide a
proper implementation, nor do I have access to NDI hardware to feel
comfortable with it. This patch at least prevents us from outputting
files that we know are broken
/Tomas
From 9dd76f9ec153c3d10374a2a4a74348dc39458c07 Mon Se
>
>> Deprecate the option 'draw_bars' in favor of the new option
>> 'signal_loss_action',
>> which controls the behavior when the input signal is not available
>> (including the behavior previously available through draw_bars).
>> The default behavior remains unchanged to be backwards compatible.
I forgot to mention it is possible to go even further with ||izing the
decoder by separating VLC decode from IDCT. This would affect serial
performance however, since all coefficients would likely not fit in the
innermost cache. For 4k yuv444p this is 51 MiB. Even 1080p yuv420p is
still 6 MiB. For
Formal methods would be better than the heuristics coverity uses. At
the moment such methods are still too expensive for general use except
for the most safety critical applications (aerospace etc). But perhaps
in time the tooling and SMT solvers will improve sufficiently to make
it commonplace.
F
60 matches
Mail list logo
