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 it wasn't working so well 20 years ago, but we've increased
compiler version re
On Thu, May 30, 2024 at 01:30:09AM +0200, Michael Niedermayer wrote:
> Hi all
>
> It seems the security update (https://ubuntu.com/security/notices/USN-6793-1)
> broke public git
>
> We use gitolite that runs under its own user and serve git through apache
> which runs under a different user.
> A
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 :
> > The entire patchset passes FATE
>
> Is the version in riscv/intmath.h safe? It looks to me that the GCC
> codegen for not only RV64 but also AArch{32,64} and
tor 2024-05-30 klockan 00:31 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > */
> > static av_always_inline av_const int32_t av_clipl_int32_c(int64_t
> > a)
> > {
> > - if ((a+0x8000u) & ~UINT64_C(0x)) return
> > (int32_t)((a>>63) ^ 0x7FFF);
> > - else
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 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 it wasn't
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 :
>> > The entire patchset passes FATE
>>
>> Is the version in riscv/intmath.h safe? It looks to
On Thu, May 30, 2024 at 11:50 AM Tomas Härdin wrote:
>
> 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 algorithm if the CPU doesn't support native CTZ.
> > And they will pick the right instr
On Thu, May 30, 2024 at 10:27:31AM +0100, Andrew Sayers wrote:
> On Thu, May 30, 2024 at 01:30:09AM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > It seems the security update
> > (https://ubuntu.com/security/notices/USN-6793-1)
> > broke public git
> >
> > We use gitolite that runs under
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 algorithm if the CPU doesn't support native CTZ.
>> And they will pick the right in
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
manageable and optimal setup for using GPU
From: Evgeny Pavlov
Added AMF based h264, hevc, av1 decoders.
Co-authored-by: Dmitrii Ovchinnikov
v2: added encoder reinitialisation
v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before)
---
libavcodec/Makefile| 7 +-
libavcodec/allcodecs.c | 3 +
libavcodec/amfdec.c
From: Michael Fabian 'Xaymar' Dirks
added 10 bit support for amf hevc.
before:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output - Format of input frames context (p010le) is not supported by
From: nyanmisaka
v2: fixes for indentation
---
libavcodec/amfenc.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0bd15dd812..068bb53002 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
From: Evgeny Pavlov
v2: refactored after review
Signed-off-by: Evgeny Pavlov
Co-authored-by: Araz Iusubov
---
libavcodec/amfenc.c | 2 ++
libavcodec/amfenc_av1.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0
From: Araz Iusubov
Implemented gpu driver check.
10-bit patch works incorrectly on driver version lower than 23.30.
Signed-off-by: Araz Iusubov
---
libavcodec/amfenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 49dd91c4e0..510050e282
From: Evgeny Pavlov
This commit adds two AMF filters: vpp_amf & sr_amf.
Both filters are using AMF hardware acceleration.
vpp_amf supports simple scaling algorithms & color conversion.
sr_amf supports advanced scaling algorithms such as FSR & can
be used for upscaling only.
---
configure
From: Evgeny Pavlov
This commit adds option for enabling SmartAccess Video (SAV)
in AMF encoders. SAV is an AMD hardware-specific feature which
enables the parallelization of encode and decode streams across
multiple Video Codec Engine (VCN) hardware instances.
Signed-off-by: Evgeny Pavlov
---
From: Evgeny Pavlov
Signed-off-by: Evgeny Pavlov
---
doc/filters.texi | 238 +++
1 file changed, 238 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index f5bf475d13..78e87ff5f7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -
Co-authored-by: Evgeny Pavlov
v3: cleanup code
---
libavcodec/amfenc.c | 573 +++
libavcodec/amfenc.h | 32 +--
libavcodec/amfenc_av1.c | 8 +-
libavcodec/amfenc_h264.c | 8 +-
libavcodec/amfenc_hevc.c | 14 +-
5 files changed, 176 insertions(+
> -Original Message-
> From: ffmpeg-devel On Behalf Of Zhao
> Zhili
> Sent: Wednesday, May 8, 2024 12:08 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhao Zhili
> Subject: [FFmpeg-devel] [PATCH v4 10/11] avfilter/dnn: Remove a level of
> dereference
>
> From: Zhao Zhili
>
> For code such
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
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 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 :
> >
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
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".
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
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
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
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
>>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
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
>>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
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
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++
> >
> > >
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
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/
___
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
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
>
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
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
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.
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
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
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
>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
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
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
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
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
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
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(-)
>>
>
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 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
--
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
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)
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
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
---
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.
---
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
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
---
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
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
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
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
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
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:/
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
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
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: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
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
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
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(-
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
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
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
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
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
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)
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 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 ++
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/
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
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 +
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
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 +
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
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
---
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
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
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,
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
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.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
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
> >
---
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
---
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
---
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
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
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
1 - 100 of 120 matches
Mail list logo
