Le 31 mai 2024 00:56:21 GMT+03:00, James Almer a écrit :
>On 5/30/2024 12:58 PM, Rémi Denis-Courmont wrote:
>> Also restrict length to even values as per (questionable) assumption in
>> the reference C code.
>> ---
>> tests/checkasm/lpc.c | 59 +---
>>
Doesn't this break the build? Ditto the AVR-32 patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscr
Hi,
I agree that the platform is dead but doesn't this at least deserve an
explanatory sentence or two?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ff
Le 31 mai 2024 03:41:40 GMT+03:00, Michael Niedermayer
a écrit :
>On Thu, May 30, 2024 at 10:54:46AM +0300, Rémi Denis-Courmont wrote:
>> Can't we just use the compiler built-ins here? AFAIK, they (GCC, LLVM) use
>> the same algorithm if the CPU doesn't support native CTZ. And they will pick
On 30/05/2024 03:04, James Almer wrote:
On 5/29/2024 10:01 PM, Lynne via ffmpeg-devel wrote:
On 29/05/2024 23:46, James Almer wrote:
Signed-off-by: James Almer
---
fftools/ffmpeg.h | 7 +++
fftools/ffmpeg_demux.c | 16
fftools/ffmpeg_filter.c | 11 +++
On Thu, May 30, 2024 at 06:38:42PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 30. toukokuuta 2024, 18.32.19 EEST Tomas Härdin a écrit :
> > Are you saying that UB is acceptable?
>
no, thats not what Remi meant IIUC
> Are you imitating Thilo and grand-standing by putting words in my mouth?
Hi,
On Thu, May 30, 2024 at 10:03 AM Tomas Härdin wrote:
> tor 2024-05-30 klockan 16:06 +0300 skrev Rémi Denis-Courmont:
> >
> >
> > Le 30 mai 2024 12:50:05 GMT+03:00, "Tomas Härdin" a
> > écrit :
> > > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont:
> > > > Can't we just use the
On Thu, May 30, 2024 at 10:54:46AM +0300, Rémi Denis-Courmont wrote:
> Can't we just use the compiler built-ins here? AFAIK, they (GCC, LLVM) use
> the same algorithm if the CPU doesn't support native CTZ. And they will pick
> the right instruction if CPU does have CTZ.
>
> I get it that maybe i
On Thu, May 30, 2024 at 12:14:23AM +0200, Tomas Härdin wrote:
>
> intmath.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 5ae92c415924602aeca4e0fcb3bf886a4c1911f1
> 0004-lavu-intmath.h-Fix-UB-in-ff_ctz_c-and-ff_ctzll_c.patch
> From f9a12089bc98dde0ccc2487d1442ec6ddb7705f6 Mo
On Thu, May 30, 2024 at 12:14:09AM +0200, Tomas Härdin wrote:
>
> common.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 1fdb9cd4a83522921c2b15a1e76ff2f65ef61f57
> 0003-lavu-common.h-Fix-UB-in-av_clip_uintp2_c.patch
> From f81730f8facc54ef23df79ac8d33075403b4f76f Mon Sep 17
On Thu, May 30, 2024 at 12:15:27AM +0200, Tomas Härdin wrote:
> This doesn't really fix anything, it just makes the value analysis
> easier. I don't feel strongly about it.
if it doesnt fix anything and it doesnt make the code faster
for our usecases, then i would say that it shouldnt be in a
prod
---
libavutil/avr32/bswap.h| 44
libavutil/avr32/intreadwrite.h | 182 -
2 files changed, 226 deletions(-)
delete mode 100644 libavutil/avr32/bswap.h
delete mode 100644 libavutil/avr32/intreadwrite.h
diff --git a/libavutil/avr32/bswap.h b/libavu
On Thu, May 30, 2024 at 07:38:36PM +, Wang Cao via ffmpeg-devel wrote:
> It is possible that the actual audio data only occupy part of the last audio
> frame. This can be signaled by duration in the "trun" atom. We should respect
> the metadata of file and set the duration correctly.
> ---
>
Signed-off-by: James Almer
---
fftools/ffmpeg.h| 7 +++
fftools/ffmpeg_demux.c | 16
fftools/ffmpeg_filter.c | 10 ++
fftools/ffmpeg_opt.c| 3 +++
4 files changed, 36 insertions(+)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index fe75706afd..f908
On Wed, May 29, 2024 at 06:46:31PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg.h| 7 +++
> fftools/ffmpeg_demux.c | 16
> fftools/ffmpeg_filter.c | 11 +++
> fftools/ffmpeg_opt.c| 3 +++
> 4 files changed, 37 insertions
Michael Niedermayer:
> On Thu, May 30, 2024 at 09:33:51PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
Michael Niedermayer:
> On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
>> Micha
On 5/30/2024 12:58 PM, Rémi Denis-Courmont wrote:
Also restrict length to even values as per (questionable) assumption in
the reference C code.
---
tests/checkasm/lpc.c | 59 +---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/tests/check
On Thu, May 30, 2024 at 09:33:51PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> >
These values are aliases in SDL, but "best" is a more intuitive name.
---
doc/ffplay.texi | 2 +-
fftools/ffplay.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 60f883e159..e7ff62ae16 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.
---
doc/ffplay.texi | 2 ++
fftools/ffplay.c | 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 93f77eeece..60f883e159 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -72,6 +72,8 @@ as 100.
Force format.
@item -window_title @v
On Mon, May 13, 2024 at 06:52:19PM +0300, radu.taraib...@gmail.com wrote:
> Previous observations:
>
> - Inconsistent code style with other filters. (Mostly using AVFilterLink*
> link instead of AVFilterLink *link).
> I hope it's fine now.
>
> - Unrelated changes, please split trivial unrelate
On Thu, May 30, 2024 at 5:20 PM Ramiro Polla wrote:
>
> ---
> libavcodec/libxvid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
> index b9ac39429d..a490f16b3f 100644
> --- a/libavcodec/libxvid.c
> +++ b/libavcodec/libxvid
---
Changelog| 1 +
libavcodec/alpha/Makefile| 10 -
libavcodec/alpha/asm.h | 153 --
libavcodec/alpha/blockdsp_alpha.c| 49 -
libavcodec/alpha/hpeldsp_alpha.c | 213 ---
libavcodec/alpha/hpeldsp_alph
---
libavcodec/bfin/README | 6 --
libavcodec/sh4/README | 6 --
libavcodec/sparc/README | 6 --
3 files changed, 18 deletions(-)
delete mode 100644 libavcodec/bfin/README
delete mode 100644 libavcodec/sh4/README
delete mode 100644 libavcodec/sparc/README
diff --git a/libavcodec
---
libavcodec/libxvid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index b9ac39429d..a490f16b3f 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -422,13 +422,13 @@ static av_cold int xvid_encode_init(AVCodecCo
Hi Andreas,
On Thu, May 30, 2024 at 2:33 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> toq...@outlook.com:
> > From: Wu Jianhua
> >
> > Some tests fails with certain seeds
> >
> > tests/checkasm/checkasm 2325607578 --test=vvc_alf
> > checkasm: using random seed 2325607578
> >
Le torstaina 30. toukokuuta 2024, 22.43.05 EEST averne a écrit :
> These files are taken with minimal modifications from nvidia's Linux4Tegra
> (L4T) tree. nvmap enables management of memory-mapped buffers for hardware
> devices. nvhost enables interaction with different hardware modules
> (multime
Le torstaina 30. toukokuuta 2024, 22.43.03 EEST averne a écrit :
> This is useful eg. for memory-mapped buffers that need page-aligned memory,
> when dealing with hardware devices
>
> Signed-off-by: averne
> ---
> libavutil/buffer.c | 31 +++
> libavutil/buffer.h | 7
Le torstaina 30. toukokuuta 2024, 22.43.04 EEST averne a écrit :
> HorizonOS (HOS) is the operating system of the Nintendo Switch.
> This patch enables integration with the homebrew toolchain developped by the
> devkitPro team. Its two main components are devkitA64 (common toolchain for
> aarch64 t
I would appreciate your review.
Just to clarify: The information I provided is coming from AMF and driver
developers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
Andreas Rheinhardt:
> 发件人: ffmpeg-devel 代表 Andreas Rheinhardt
>
> 发送时间: 2024年5月30日 11:33
> 收件人: ffmpeg-devel@ffmpeg.org
> 主题: Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/x86/vvc/vvc_alf: fix integer
> overflow
>
> toq...@outlook.com:
> > From: Wu Jianhua
> >
> > Some tests fails with certain se
Signed-off-by: averne
---
configure| 2 +
libavcodec/Makefile | 1 +
libavcodec/hwaccels.h| 1 +
libavcodec/nvtegra_vp8.c | 334 +++
libavcodec/vp8.c | 6 +
5 files changed, 344 insertions(+)
create mode 100644 libavcod
Same remark as for h264. In addition, a number of bits to be skipped must be
calculated. This is done in the main header parsing routine, instead of
reimplementing it in the hwaccel backend.
On the tegra 210, this is the only hardware codec that can output 10-bit data.
Signed-off-by: averne
---
Due to the hardware modus operandi, dpb references must stay at a fixed slot
for their entire lifetime.
Signed-off-by: averne
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/h264_slice.c | 6 +-
libavcodec/h264dec.c | 3 +
libavcodec/hwaccels.h
This hardware block was based on/licensed from the hantro implementation (as
evidenced by the identical structures). Relevant V4L2 kernel code was
referenced when implementing backward entropy updates.
Signed-off-by: averne
---
configure| 2 +
libavcodec/Makefile | 1 +
This uses NVJPG, a hardware engine separate from NVDEC. On the tegra 210 (and
possibly later hardware), it has the specificity of being unable to decode to
tiled surfaces, along with some quirks that have been observed to hang the
hardware.
Signed-off-by: averne
---
configure
Since L4T does not hook up the vc1 code to a user-facing library, this was
written solely based on static reverse engineering.
Signed-off-by: averne
---
configure| 3 +
libavcodec/Makefile | 1 +
libavcodec/hwaccels.h| 2 +
libavcodec/nvtegra_vc1.c | 455 +
Signed-off-by: averne
---
configure | 2 +
libavcodec/Makefile| 1 +
libavcodec/h263dec.c | 6 +
libavcodec/hwaccels.h | 1 +
libavcodec/mpeg4videodec.c | 3 +
libavcodec/nvtegra_mpeg4.c | 344 +
6 files changed, 35
This is probably the most straightforward codec to implement on NVDEC. Since
mpeg2 is a superset of mpeg1, both are supported by the same backend.
Signed-off-by: averne
---
configure | 4 +
libavcodec/Makefile | 2 +
libavcodec/hwaccels.h | 2 +
libavcodec/
This includes decode common de/initialization code, decode-job management, and
constraint checks.
Signed-off-by: averne
---
configure | 1 +
libavcodec/Makefile | 2 +
libavcodec/hwconfig.h | 2 +
libavcodec/nvtegra_decode.c | 517 ++
To save on energy, the clock speed of multimedia engines should be adapted to
their workload.
Signed-off-by: averne
---
libavutil/hwcontext_nvtegra.c | 165 ++
libavutil/hwcontext_nvtegra.h | 7 ++
2 files changed, 172 insertions(+)
diff --git a/libavutil/hwco
This includes hwdevice and hwframes objects.
As the multimedia engines work with tiled surfaces (block linear in nvidia
jargon), two frame transfer methods are implemented.
The first makes use of the VIC to perform the copy. Since some revisions of the
VIC (such as the one found in the tegra X1)
This includes a new pixel format for nvtegra hardware frames, and several
objects for interaction with hardware blocks.
In particular, this contains code for channels (handles to hardware engines),
maps (memory-mapped buffers shared with engines), and command buffers
(abstraction for building co
These files are taken with minimal modifications from nvidia's Linux4Tegra
(L4T) tree.
nvmap enables management of memory-mapped buffers for hardware devices.
nvhost enables interaction with different hardware modules (multimedia engines,
display engine, ...), through a common block, host1x.
Sig
HorizonOS (HOS) is the operating system of the Nintendo Switch.
This patch enables integration with the homebrew toolchain developped by the
devkitPro team. Its two main components are devkitA64 (common toolchain for
aarch64 targets) and libnx (library implementing interaction with the HOS
kerne
This is useful eg. for memory-mapped buffers that need page-aligned memory,
when dealing with hardware devices
Signed-off-by: averne
---
libavutil/buffer.c | 31 +++
libavutil/buffer.h | 7 +++
2 files changed, 38 insertions(+)
diff --git a/libavutil/buffer.c b
Hi all,
This patch series implements a hardware decoding backend for nvidia
Tegra devices, notably the Nintendo Switch. It was primarily written
for HorizonOS (Nintendo Switch OS), but also supports nvidia's
Linux4Tegra distro. As for hardware, all Tegras later than the X1
(T210) should be support
It is possible that the actual audio data only occupy part of the last audio
frame. This can be signaled by duration in the "trun" atom. We should respect
the metadata of file and set the duration correctly.
---
libavformat/mov.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-
Michael Niedermayer:
> On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
Michael Niedermayer:
> On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
>> Forgo
On Mon, May 27, 2024 at 04:52:22PM -0300, James Almer wrote:
> On 5/27/2024 4:50 PM, Michael Niedermayer wrote:
> > On Mon, May 27, 2024 at 04:33:21PM -0300, James Almer wrote:
> > > On 5/27/2024 4:31 PM, Michael Niedermayer wrote:
> > > > On Mon, May 27, 2024 at 09:20:55PM +0200, Michael Niedermay
On 5/30/2024 4:31 PM, Rémi Denis-Courmont wrote:
Le torstaina 30. toukokuuta 2024, 22.06.55 EEST Rémi Denis-Courmont a écrit :
The function pointer is appended to the structure for backward binary
compatibility. Fortunately, this is allocated by libavutil, not by the
user, so increasing the stru
Le torstaina 30. toukokuuta 2024, 22.06.55 EEST Rémi Denis-Courmont a écrit :
> The function pointer is appended to the structure for backward binary
> compatibility. Fortunately, this is allocated by libavutil, not by the
> user, so increasing the structure size is safe.
> ---
> libavutil/float_d
On 5/30/2024 4:21 PM, Rémi Denis-Courmont wrote:
Le torstaina 30. toukokuuta 2024, 22.10.28 EEST James Almer a écrit :
Why are you adding this to the doxy for scalarproduct_float()? Those
constrains are not correct for it. They are for scalarproduct_double()
which you're adding now.
Because co
On Thu, May 30, 2024 at 08:07:48PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
> Forgotten in 65ddc74988245a01
Le torstaina 30. toukokuuta 2024, 22.10.28 EEST James Almer a écrit :
> Why are you adding this to the doxy for scalarproduct_float()? Those
> constrains are not correct for it. They are for scalarproduct_double()
> which you're adding now.
Because copy-paste error.
--
Rémi Denis-Courmont
http:/
Le torstaina 30. toukokuuta 2024, 22.07.13 EEST Michael Niedermayer a écrit :
> If the function doesnt get called with values triggering UB then its not UB.
As Tomas pointed out, that statement is actually false. Specifically, if the
compiler can prove that the function can be called with values
On 5/30/2024 4:06 PM, Rémi Denis-Courmont wrote:
The function pointer is appended to the structure for backward binary
compatibility. Fortunately, this is allocated by libavutil, not by the
user, so increasing the structure size is safe.
---
libavutil/float_dsp.c | 12
libavutil/f
On Thu, May 30, 2024 at 08:49:12PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit :
> > > > Are you saying that UB is acceptable? You know the compiler is free
> > > > to
> > > > assume signed arithmetic doesn't overflow, right? If so then w
C908:
scalarproduct_double_c: 39.2
scalarproduct_double_rvv_f64: 10.5
X60:
scalarproduct_double_c: 35.0
scalarproduct_double_rvv_f64: 5.2
---
libavutil/riscv/float_dsp_init.c | 3 +++
libavutil/riscv/float_dsp_rvv.S | 21 +
2 files changed, 24 insertions(+)
dif
---
libavfilter/aap_template.c | 14 +-
libavfilter/anlms_template.c | 16 ++--
libavfilter/arls_template.c | 14 +-
3 files changed, 4 insertions(+), 40 deletions(-)
diff --git a/libavfilter/aap_template.c b/libavfilter/aap_template.c
index ea9c815a89..0e05
The function pointer is appended to the structure for backward binary
compatibility. Fortunately, this is allocated by libavutil, not by the
user, so increasing the structure size is safe.
---
libavutil/float_dsp.c | 12
libavutil/float_dsp.h | 31 ++-
2 fi
---
tests/checkasm/float_dsp.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tests/checkasm/float_dsp.c b/tests/checkasm/float_dsp.c
index cadfa65e2a..296db1cff9 100644
--- a/tests/checkasm/float_dsp.c
+++ b/tests/checkasm/float_dsp.c
@@ -278,6 +278,22 @@ static void tes
---
libavutil/lls.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavutil/lls.c b/libavutil/lls.c
index c1e038daf1..1096ae69d5 100644
--- a/libavutil/lls.c
+++ b/libavutil/lls.c
@@ -30,6 +30,7 @@
#include "config.h"
#include "attributes.h"
+#include "float_dsp.
Andreas Rheinhardt:
> This was one of the few decoders incompatible with the flag.
> Also only call free_sequence_buffers(), dirac_decode_flush()
> in dirac_decode_end().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/diracdec.c | 10 +-
> 1 file changed, 5 insertions(+), 5 del
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/vc2enc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
> index 365d43146d..b496f67d3a 100644
> --- a/libavcodec/vc2enc.c
> +++ b/libavcodec/vc2enc.c
toq...@outlook.com:
> From: Wu Jianhua
>
> Some tests fails with certain seeds
>
> tests/checkasm/checkasm 2325607578 --test=vvc_alf
> checkasm: using random seed 2325607578
> AVX2:
> vvc_alf_filter_luma_120x20_12_avx2 (vvc_alf.c:104)
> vvc_alf_filter_luma_120x24_12_avx2 (vvc_alf.c:104)
Hi,
On Thu, May 30, 2024 at 12:28 PM wrote:
> From: Wu Jianhua
>
> Some tests fails with certain seeds
>
> tests/checkasm/checkasm 2325607578 --test=vvc_alf
> checkasm: using random seed 2325607578
> AVX2:
> vvc_alf_filter_luma_120x20_12_avx2 (vvc_alf.c:104)
> vvc_alf_filter_luma_120x24
Michael Niedermayer:
> On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
Forgotten in 65ddc74988245a01421a63c5cffa4d900c47117c.
Signed-off-by: Andreas Rheinhardt
--
On Thu, May 30, 2024 at 07:53:42PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
> >> Forgotten in 65ddc74988245a01421a63c5cffa4d900c47117c.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/nutd
Michael Niedermayer:
> On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
>> Forgotten in 65ddc74988245a01421a63c5cffa4d900c47117c.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/nutdec.c | 14 --
>> 1 file changed, 4 insertions(+), 10 deletions(-)
>>
>
Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit :
> > > Are you saying that UB is acceptable? You know the compiler is free
> > > to
> > > assume signed arithmetic doesn't overflow, right? If so then what
> > > other
> > > UB might we accept?
> >
> > He did not say that... He
On Thu, May 30, 2024 at 02:14:20AM +0200, Andreas Rheinhardt wrote:
> Forgotten in 65ddc74988245a01421a63c5cffa4d900c47117c.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nutdec.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/nu
On 30/05/2024 18:06, Dmitrii Ovchinnikov wrote:
DX12 and Vulkan native encoders will expose less features compare to
AMF,
at least in foreseeable feature. The missing features include low
latency,
That's plainly not true.
PreAnalysis including look-ahead etc. AMF context on Windows
tor 2024-05-30 klockan 12:42 -0300 skrev James Almer:
> On 5/30/2024 12:32 PM, Tomas Härdin wrote:
> > tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
> > >
> > >
> > > Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin"
> > > a
> > > écrit :
> > > > > We should depend on punning as
Ronald S. Bultje:
> 发件人: Ronald S. Bultje
> 发送时间: 2024年5月29日 13:56
> 收件人: Wu Jianhua
> 抄送: FFmpeg development discussions and patches; Nuo Mi; James Almer
> 主题: Re: [FFmpeg-devel] [PATCH 1/3] avcodec/x86/vvc/vvc_alf: fix integer
> overflow
>
> Hi,
>
> On Wed, May 29, 2024 at 3:44 PM Wu Jianhua
From: Wu Jianhua
>From Benjamin Bross:
> for ALF where functions are in increments of 4 while 8 should be sufficient
> according to the spec.
Signed-off-by: Wu Jianhua
---
tests/checkasm/vvc_alf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/vvc_a
From: Wu Jianhua
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvc_alf.asm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/x86/vvc/vvc_alf.asm b/libavcodec/x86/vvc/vvc_alf.asm
index f7b3e2a6cc..b35dd9b0e9 100644
--- a/libavcodec/x86/vvc/vvc_alf.asm
+++
From: Wu Jianhua
Some tests fails with certain seeds
tests/checkasm/checkasm 2325607578 --test=vvc_alf
checkasm: using random seed 2325607578
AVX2:
vvc_alf_filter_luma_120x20_12_avx2 (vvc_alf.c:104)
vvc_alf_filter_luma_120x24_12_avx2 (vvc_alf.c:104)
vvc_alf_filter_luma_120x28_12_avx2
Le keskiviikkona 29. toukokuuta 2024, 19.59.56 EEST Sean McGovern a écrit :
> Hi,
>
> It is not likely we will get anyone to step up to do DSP work for arguably
> dead architectures like SPARC, Blackfin, etc.
Super-H and Alpha.
> Maybe is it time to remove those directories that just contain a R
DX12 and Vulkan native encoders will expose less features compare to AMF,
at least in foreseeable feature. The missing features include low latency,
PreAnalysis including look-ahead etc. AMF context on Windows allows fully
enable SAV - ability to utilize VCNs in dGPU and APU in a single session.
Also restrict length to even values as per (questionable) assumption in
the reference C code.
---
tests/checkasm/lpc.c | 59 +---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..f9f
Le keskiviikkona 29. toukokuuta 2024, 23.52.20 EEST James Almer a écrit :
> On 5/29/2024 4:42 PM, Rém
> > void checkasm_check_lpc(void)
> > {
> >
> > LPCContext ctx;
> >
> > -int len = rnd() % 5000;
> > +int len = 2000 + (rnd() % 1500) * 2;
>
> Instead of changing how len is
Well.. because scalar registers are limited, the direct unrolling will be
like this for now. We can handle different lengths separately in the future
flow gg 于2024年5月30日周四 23:36写道：
> I directly copied the VP9 modifications over... Since len <= 16, it seems
> like it can be improved a bit more
>
On 5/30/2024 12:32 PM, Tomas Härdin wrote:
tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a
écrit :
We should depend on punning as long as it conforms to the
standard.
My mistake, I forgot type punning is allowed in C. It's U
Le torstaina 30. toukokuuta 2024, 18.32.19 EEST Tomas Härdin a écrit :
> Are you saying that UB is acceptable?
Are you imitating Thilo and grand-standing by putting words in my mouth?
Yes and so -1 for you.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
I directly copied the VP9 modifications over... Since len <= 16, it seems
like it can be improved a bit more
于2024年5月30日周四 23:27写道：
> From: sunyuechi
>
> Since len < 64, the registers are sufficient, so it can be
> directly unrolled (a4 is even).
>
> Another benefit of unrolling is that it redu
tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a
> écrit :
> > > We should depend on punning as long as it conforms to the
> > > standard.
> >
> > My mistake, I forgot type punning is allowed in C. It's UB in C++
> >
> > >
From: sunyuechi
Since len < 64, the registers are sufficient, so it can be
directly unrolled (a4 is even).
Another benefit of unrolling is that it reduces one load operation
vertically compared to horizontally.
old new
>>I do not see a configure dependency of your AMF decoders on AMF
Thanks, apparently I always put it together with the encoder and therefore
did not get such an error. I'll fix the dependencies and check the options
without AMF.
___
ffmpeg-devel mailing l
On 30/05/2024 15:08, Dmitrii Ovchinnikov wrote:
Adds hwcontext_amf, which allows to use shared AMF
context for the encoder, decoder and AMF-based filters,
without copy to the host memory.
It will also allow you to use some optimisations in
the interaction of components (for example, SAV) and make
>>This seems to have forgotten to actually allocate anything?
I made an empty allocation here, since in fact all allocation
takes place in the decoder.
>>This makes it look like you really wanted to implement map_from,
not transfer_data_from.
These functions were conceived specifically for transfe
Le 30 mai 2024 17:03:09 GMT+03:00, "Tomas Härdin" a écrit :
>> I don't get how that prevents using the GCC and Clang builtins (on
>> GCC and Clang).
>
>Does MSVC have builtins for these?
I don't know, but insofar as MSVC is used for x86, it should use x86
instructions rather than the complex f
Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a écrit :
>> We should depend on punning as long as it conforms to the standard.
>
>My mistake, I forgot type punning is allowed in C. It's UB in C++
>
>> > The standard compliant way
>> > is to use memcpy()
>>
>> That's way worse than union in
Dmitrii Ovchinnikov:
> In the new version, I removed unnecessary includes and cleaned up the code
> (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11968).
> It didn't seem to help. On my local computer build is successful in all
> configurations that I have tried.
> The file mentioned in
Ping
This stops us from producing broken output
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsub
Ping
Will push in a couple of days
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
In the new version, I removed unnecessary includes and cleaned up the code
(https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11968).
It didn't seem to help. On my local computer build is successful in all
configurations that I have tried.
The file mentioned in the error is also already used
tor 2024-05-30 klockan 14:50 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 12:40:20 GMT+03:00, "Tomas Härdin" a
> écrit :
> > tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
> > > Hi,
> > >
> > > Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin"
> > > a
> > > écrit :
> >
Dmitrii Ovchinnikov:
> Adds hwcontext_amf, which allows to use shared AMF
> context for the encoder, decoder and AMF-based filters,
> without copy to the host memory.
> It will also allow you to use some optimisations in
> the interaction of components (for example, SAV) and make a more
> manageabl
tor 2024-05-30 klockan 16:06 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 12:50:05 GMT+03:00, "Tomas Härdin" a
> écrit :
> > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont:
> > > Can't we just use the compiler built-ins here? AFAIK, they (GCC,
> > > LLVM) use the same algo
1 - 100 of 120 matches
Mail list logo
