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
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.r
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
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_
tware multimedia component essential to bringing audio and video to
billions around the world everyday."
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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".
@@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the
tcode_find_candidate_rvv;
+# endif
#endif
}
diff --git a/libavcodec/riscv/startcode_rvv.S b/libavcodec/riscv/startcode_rvv.S
new file mode 100644
index 00..7c43b1d7f3
--- /dev/null
+++ b/libavcodec/riscv/startcode_rvv.S
@@ -0,0 +1,44 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * Redistri
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:
C V before V after
1 48.0214.7 95.2
2
Le keskiviikkona 15. toukokuuta 2024, 20.33.04 EEST flow gg a écrit :
> Is the test result missing here?
fate-h264 and fate-vc1, yes.
IMO, passing tests is implied and I don't think it worth mentioning.
--
Rémi Denis-Courmont
http://www.re
This is pretty much the same as for lpc16, though it only improves half
as large prediction orders. With 128-bit vectors, this gives:
C V old V new
1 69.2 181.5 95.5
2 107.7 180.7 95.2
3 145.5 180.0 103.5
4 183.0 179.2 102.7
5 220.7 178.5 128.0
6 257.7 194.0 127.5
7
to hold checkasm tests off because of broken legacy code.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
Le keskiviikkona 31. tammikuuta 2024, 19.58.55 EET flow gg a écrit :
> Fixed the rv32 break in this reply
It looks like widening add would avoid the sign extension.
Although you'd need as many instructions, since V lacks signed to unsigned
clipping.
--
Rémi Denis-Courm
Le perjantaina 2. helmikuuta 2024, 3.14.39 EET flow gg a écrit :
> Ok, updated it in the reply
Sorry I meant directive, not macro. .rept is just fine here.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
Hi,
I think you cna use vwadd here?
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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
Hi,
To avoid repeating the code, you can either use .repr or .irp. You can even
use assembler conditionals to elide the redundant code on the last iteration.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
Hi,
Le 13 février 2024 18:22:46 GMT+02:00, Nicolas George a écrit
:
>Martin Storsjo (12024-02-13):
>> The main arguments raised were about API consistency, prevention of
>> accidental inclusions, as well as explicitness in marking a field as
>> public or private.
>
>Too bad the committee negle
Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit :
> As a TC member who is part of the disagreement, I believe your
> participation is recused.
Obviously not. We don't want to get into a situation whence TC members have an
incentive not to participate in regular code reviews jus
Le sunnuntaina 18. helmikuuta 2024, 18.27.35 EET Andreas Rheinhardt a écrit :
> 1. The function is called aligned_alloc (how did you test this?).
> 2. C11: "The value of alignment shall be a valid alignment supported by
> the implementation and the value of size shall be an integral multiple
> of a
lloc may already allocate sufficiently aligned buffers
> +if (ALIGN > _Alignof(max_align_t))
If you ever try to reintroduce something like this, you would need
here, and thus you should use alignof rather than _Alignof (which
was already deprecated by C23 deprecated).
> +ptr = al
Le sunnuntaina 18. helmikuuta 2024, 18.29.32 EET James Almer a écrit :
> Removing all the different target specific allocation functions in favor
> of the standard one. But your second point makes it moot, so patch
> withdrawn.
If you want to get code closer to standards for dealing with alignment
Le sunnuntaina 18. helmikuuta 2024, 2.43.14 EET Michael Niedermayer a écrit :
> > > You clearly are one of the parties to the disagreement, and "recuse
> > > themselves from the decision" is self-explanatory.
> >
> > Such a maximalist interpretation makes no sense - why should my opinion
> > becom
Le sunnuntaina 18. helmikuuta 2024, 20.40.14 EET Nicolas George a écrit :
> The world is “involves”, its meaning is inherently maximalist.
The wording is very clear (emphasis added): "If the disagreement involves a
member of the TC, that member SHOULD recuse themselves from the decision."
I trus
Le sunnuntaina 18. helmikuuta 2024, 14.27.56 EET flow gg a écrit :
> ping
Patch does not apply here.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffm
Le 20 février 2024 16:01:11 GMT+02:00, Michael Niedermayer
a écrit :
>On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>[...]
>> their preferred wording, and then we can have the GA vote on it.
>
>Before this GA vote, we need another extra member discussion/vote.
>Because the last
are worried about conflict of interests, the most
effective way around them is to keep diverse membership in the TC to counter-
balance conflicted members.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@f
repeating the 8 regular loads, and it won't work
if you need calculations between rows.
I may be missing something but I don't understand what purpose the header file
serves here?
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-d
Le tiistaina 6. helmikuuta 2024, 17.56.32 EET flow gg a écrit :
>
Did you try to compute integral absolute values with the ad-hoc (floating
point) instruction instead of vneg/vmax? It should work since the sign is in
the same place, though I don't know if it will be faster.
--
レミ・デニ-クールモン
htt
Le 22 février 2024 05:04:58 GMT+02:00, flow gg a écrit :
>.macro vabsaddu dst src tmp
>- vneg.v \tmp, \src
>- vmax.vv \tmp, \src, \tmp
>+ vfabs.v \tmp, \src
>vwaddu.wv \dst, \dst, \tmp
>.endm
>
>After making this change, the test
Le tiistaina 6. helmikuuta 2024, 17.56.59 EET flow gg a écrit :
>
Use 'static' functions where possible.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To u
Hi,
+
+.macro bilin_h_load dst len
+.ifc \len,4
+vsetivlizero, 5, e8, mf2, ta, ma
Don't use fractional multipliers if you don't mix element widths.
+.elseif \len == 8
+vsetivlizero, 9, e8, m1, ta, ma
+.else
+vsetivlizero, 17, e8, m2, ta, ma
+.endif
t_bilin4_h_rvv_i32: 158.7 193.7
>vp8_put_bilin4_hv_rvv_i32: 255.7 302.7
>vp8_put_bilin8_h_rvv_i32: 318.7 358.7
>vp8_put_bilin8_hv_rvv_i32: 528.7 569.7
>
>Rémi Denis-Courmont 于2024年2月24日周六 01:18写道：
>
>> Hi,
>>
>> +
>> +.macro bilin_h_load dst len
Le maanantaina 26. helmikuuta 2024, 21.48.03 EET Ronald S. Bultje a écrit :
> Hi,
>
> On Mon, Feb 26, 2024 at 2:17 PM Anton Khirnov wrote:
> > Quoting Ronald S. Bultje (2024-02-26 19:12:45)
> >
> > > That's essentially what I was suggesting: run a GA vote on your proposed
> > > amendment, and th
Le keskiviikkona 28. helmikuuta 2024, 19.55.11 EET James Almer a écrit :
> > The last commit which actually changed the codec was
> > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10
> > years ago. For an experimental codec I think it's pretty safe to say
> > that developmen
Le lauantaina 24. helmikuuta 2024, 10.31.36 EET flow gg a écrit :
> Okay, Thanks for clarifying.
>
> I have used many fractional multipliers, mostly not for correctness, but
> often for performance improvements (though I don't know why),
> and there are no obvious downsides, How about leaving this
Le lauantaina 2. maaliskuuta 2024, 9.42.06 EET flow gg a écrit :
>
You would need a lot fewer if/else if you passed the order/bit-width instead
of the size as macro parameter.
Similarly, this can be folded as a single .else:
+.elseif \type == 127
+li t1, 127
+.elseif \type ==
t creates fodder for future accusations of bad faith,
hypocrisy, misjudgement against TC decisions. While the sentence is meaning
well, it adds absolutely nothing of value.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-d
Le tiistaina 27. helmikuuta 2024, 0.44.37 EET Michael Niedermayer a écrit :
> Signed-off-by: Michael Niedermayer
> ---
> doc/community.texi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/community.texi b/doc/community.texi
> index 8a38c6aca0..fc22a8fa61 100644
> --- a/doc/commun
Le perjantaina 23. helmikuuta 2024, 16.45.46 EET flow gg a écrit :
>
Looks like this needs rebasing, or otherwise does not apply.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Le sunnuntaina 3. maaliskuuta 2024, 3.59.00 EET flow gg a écrit :
> updated a little improve in this reply
As noted eaerlier, I don't understand why you have two size parameters. It
seems that \size is always either the same as (1 << (\size2 - 1)) a.k.a. ((1
<< \size2) / 2), or unused. The assem
y, especially one so small and so
specific that it is very unlikely to be shipped by the vast majority of
FFmpeg's downstreams.
(sigv4 is just three thousand lines of C, and most of that is just
boilerplate.)
--
Rémi Denis-Courmont
http://www.remlab.net/
___
cies on the address registers may help. I mean, avoid using as address
operand a value that was calculated by the immediate previous instruction.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
Le 8 mars 2024 02:45:46 GMT+02:00, flow gg a écrit :
>> Isn't it also faster to max LMUL for the adds here?
>
>It requires the use of one more vset, making the time slightly longer:
>147.7 (m1), 148.7 (m8 + vset).
A variation of 0.6% on a single set of kernels will end up below measurement
noi
Le jeudi 14 mars 2024, 11:22:40 EET Ignjatović, Lazar (RS) a écrit :
> avformat: enable UDP IPv6 multicast interface selection
>
> localaddr option now properly works with IPv6 addresses. Properly resolved
> interface index in places where default 0 interface index is used (marked
> with TODO: wit
Le 16 mars 2024 13:58:23 GMT-07:00, James Almer a écrit :
>> Seems the conflict comes from
>> https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287
>> and
>> https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6
>>
>
Le 17 mars 2024 10:29:39 GMT-07:00, Andreas Rheinhardt
a écrit :
>Rémi Denis-Courmont:
>>
>>
>> Le 16 mars 2024 13:58:23 GMT-07:00, James Almer a écrit :
>>>> Seems the conflict comes from
>>>> https://code.videolan.org/videolan/libbluray/-/
Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler a
écrit :
>On 17.03.2024 18:37, Rémi Denis-Courmont wrote:
>>
>>
>> Le 17 mars 2024 10:29:39 GMT-07:00, Andreas Rheinhardt
>> a écrit :
>>> Rémi Denis-Courmont:
>>>>
>>>&
Le 17 mars 2024 18:21:23 GMT-07:00, Timo Rothenpieler a
écrit :
>On 18.03.2024 01:32, Rémi Denis-Courmont wrote:
>>
>>
>> Le 17 mars 2024 14:13:18 GMT-07:00, Timo Rothenpieler
>> a écrit :
>>> On 17.03.2024 18:37, Rémi Denis-Courmont wrote:
>>>
Same fundamental problem as previous version, AFAICT.
-1
___
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 "unsu
Le 20 mars 2024 13:09:15 GMT+02:00, "Ignjatović, Lazar (RS)"
a écrit :
>
>This message has been marked as Public on 03/20/2024 11:09Z.
>On Wednesday, March 20, 2024 11:51 AM Rémi Denis-Courmont wrote:
>
>> Same fundamental problem as previous version, AFAICT.
>
Le 20 mars 2024 13:45:10 GMT+02:00, "Ignjatović, Lazar (RS)"
a écrit :
>
>This message has been marked as Public on 03/20/2024 11:45Z.
>On Wednesday, March 20, 2024 12:30 PM Rémi Denis-Courmont wrote:
>
>> You're not supposed to guess the link ID from the l
Le 20 mars 2024 14:35:28 GMT+02:00, "Ignjatović, Lazar (RS)"
a écrit :
> Specifying egress interface is done by setting the
> setsockopt(IPV6_MULTICAST_IF) to the value of the interface, not address. On
> the other hand v4 for the similar option setsockopt(IP_MULTICAST_IF) sets it
> by defin
eter
(ping6) or prepending the interface name after a percent sign (glibc).
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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".
Le 22 mars 2024 11:31:28 GMT+02:00, "Ignjatović, Lazar (RS)"
a écrit :
>>> I've compared ffmpeg 5.1.2 against my MR on IPv6 multicast. Here are
>>> the
>>> results:
>>
>> I don't care. That does not make your MR any less counter-sensical.
>
>If I may cite Marton Balint
I am not answerable for
Le 31 juillet 2023 00:07:37 GMT+07:00, Andrey Turkin
a écrit :
>вс, 30 июл. 2023 г. в 16:04, Nicolas George :
>
>> Kieran Kunhya (12023-07-28):
>> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
>> > WiFi protocol etc etc. Different layers are delegated to different
>> > p
have even been cited.
As far as FFmpeg(-devel) is concerned, I can't think how it could/should
reasonably get any more specific than that.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
To whom it may concern,
It has come to Remlab Tmi's attention that the FATE samples suite has recently
been abused to contain non-multimedia files. This is a breach of your trust and
we feel that this is totally inappropriate. The FATE instances were explicitly
setup and sponsored by Tmi Remlab
Le tiistaina 8. elokuuta 2023, 18.22.49 EEST Michael Niedermayer a écrit :
> > > That is missing that people suggest a path forward but
> > > with too few details to easily walk that path.
> >
> > Uh, I hate to state the patently obvious, but if "no path forward is
> > needed", then there should l
Le 9 août 2023 15:02:45 GMT+03:00, David Rosca a écrit :
>Support for allocating frames with x2rgb10 format was added
>in c00264f5013, this adds support for importing DMA-BUFs.
>---
> libavutil/hwcontext_vaapi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/libavutil/hwcontext_vaapi.
AV_READ_TIME has no side effects. It does not need to be volatile.
---
libavutil/riscv/timer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/timer.h b/libavutil/riscv/timer.h
index c2465a4524..b418d13a26 100644
--- a/libavutil/riscv/timer.h
+++ b/libavutil
So far, AV_READ_TIME would return the cycle counter. This posed two
problems:
1) On recent systems, it would just raise an illegal instruction
exception. Indeed RDCYCLE is blocked in user space to ward off some
side channel attacks. In particular, this would cause the random
number generat
---
libavutil/riscv/timer.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/riscv/timer.h b/libavutil/riscv/timer.h
index b418d13a26..df1a730b5e 100644
--- a/libavutil/riscv/timer.h
+++ b/libavutil/riscv/timer.h
@@ -48,6 +48,7 @@ static inline uint64_t ff_read_time(void)
}
#defin
-$(CONFIG_IDCTDSP) += riscv/idctdsp_init.o
diff --git a/libavcodec/riscv/g722dsp_init.c b/libavcodec/riscv/g722dsp_init.c
new file mode 100644
index 00..77e29bfb56
--- /dev/null
+++ b/libavcodec/riscv/g722dsp_init.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file
ne AVUTIL_EXECUTOR_H
> +
> +typedef struct AVExecutor AVExecutor;
> +typedef struct AVTask AVTask;
> +
> +struct AVTask {
> +AVTask *next;
> +};
> +
> +typedef struct AVTaskCallbacks {
> +void *user_data;
> +
> +int local_context_size;
> +
> +
Le torstaina 24. elokuuta 2023, 22.56.14 EEST Michael Niedermayer a écrit :
> Suggested text is from Anton
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 0c2f2cd7d1..38
Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit :
> > And then sometimes an argument has been argued to death previously and
> > there is really no point to rehash it again and again. If people cannot
> > agree, they should refer to the TC, not brute force the review through
>
No
Le 27 août 2023 17:43:13 GMT+03:00, Tmc Tmc a écrit :
>Hi All,
>I found a bug in ffmpeg's RTSP implementation.
>
>The workflow is as follows:
>
>1. Have a RTSP server that supports Pause.
>2. Have ffmpeg play a video from that server (rtsp://:...).
>3. Pause the video in ffmpeg.
>4. ffmpeg do
Le torstaina 31. elokuuta 2023, 18.28.48 EEST Stefano Sabatini a écrit :
> On date Tuesday 2023-08-29 10:34:45 +0200, Anton Khirnov wrote:
> > Quoting Stefano Sabatini (2023-08-27 14:38:44)
> >
> > > Il sab 26 ago 2023, 20:08 Anton Khirnov ha scritto:
> > > > Document our longstanding de facto po
Le lauantaina 2. syyskuuta 2023, 23.03.32 EEST Michael Niedermayer a écrit :
> > And yes, UB is a very well known accronym in this context. In my
> > experience, people who don't know the accronym don't know the concept
> > either, so spelling it out wouldn't even help.
>
> "Undefined behavior" ca
Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit :
> In the past, most developers in FFmpeg where primarly FFmpeg developers. But
> as FFmpeg is used by almost everyone now, that has changed and many
> developers in FFmpeg today are primarly developer of 3rd party project
Le keskiviikkona 6. syyskuuta 2023, 2.26.29 EEST Kacper Michajłow a écrit :
> Other C++ standard libraries exist. Also, this is not a proper way to
> link the standard library anyway. Instead when a C++ dependency is
> detected, switch to the C++ compiler driver to properly link everything.
>
> Si
Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit :
> benchmark:
> fcmul_add_c: 19.7
> fcmul_add_rvv_f32: 6.7
Nit: please pad mnemonics to at least 8 columns for consistency.
I'm a bit surprised that the performance improves this much, considering that
the C910 is notoriously bad at
Le tiistaina 26. syyskuuta 2023, 21.40.12 EEST Paul B Mahol a écrit :
> On Tue, Sep 26, 2023 at 8:35 PM Rémi Denis-Courmont wrote:
> > Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit :
> > > benchmark:
> > > fcmul_add_c: 19.7
> > > fcmul_add_r
Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit :
> benchmark:
> fcmul_add_c: 19.7
> fcmul_add_rvv_f32: 6.7
+li t1, 4
+vsetvli t0, t1, e32, m1, ta, ma
vsetivli t0, 4, ...
But really, DO NOT use a fixed vector length here. At best, you're wasting half
the vector width. Yo
Le torstaina 21. syyskuuta 2023, 21.56.52 EEST Michael Niedermayer a écrit :
> Hi
>
> On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel
wrote:
> > On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
> >
> > wrote:
> > > OTOH If a majority of people are against the SDR cod
Le lauantaina 23. syyskuuta 2023, 9.49.47 EEST Neal Gompa a écrit :
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
>
> wrote:
> > > What does this mean? Does this mean an FFmpeg release containing code
> > > that
> > > interfaces with your SDR library? Or does it mean the library fully
>
have not tested on C910 recently
so maybe it's just how it is). But in any case, performance metrics from C
code compiled with -O0 are worthless.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
It does not make much sense to me, but GCC somehow optimises the
inline assembler way even when the output are very obviously used.
This reverts commit 09731fbfc3a914ec4f6ffad60aa9062db6a8f6aa.
---
libavutil/riscv/timer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib
Le keskiviikkona 27. syyskuuta 2023, 4.47.26 EEST flow gg a écrit :
> >>> please pad mnemonics to at least 8 columns for consistency
>
> okay, changed
>
> >>> It seems that you could just as well use vlseg2 without register
>
> stride, no?
>
> yes, vlseg will better, changed
>
> >>> Note that
could be improved regardless.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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 wit
fcmul_add_rvv_f32: 4.2
> - af_afir.fcmul_add [OK]
>fcmul_add_c: 4.7
>fcmul_add_rvv_f32: 3.5
>
>
>Rémi Denis-Courmont 于2023年9月28日周四 00:41写道：
>
>> Le tiistaina 26. syyskuuta 2023, 12.24.58 EEST flow gg a écrit :
>> > benchmark:
>> > fcmul_add_c: 19.7
&
Le keskiviikkona 27. syyskuuta 2023, 23.18.29 EEST Michael Niedermayer a écrit
:
> And you can repeat it as often as you want, iam not interrested.
> Why do you not understand this ?
You can repeat the contrary as much as you want, we do not believe that your
SDR code fits in FFmpeg. Why do you
cluding SDR-outside-FFmpeg. He can stick to spending his "time on
boring things" if/when he gets paid.
That will add incentives for big tech corps to actually fund FFmpeg. This
community, and presumably Michael in particular, are way too good at doing
those "boring things
audiodsp.vector_clip_int32_c: 17500.7
audiodsp.vector_clip_int32_rvv_i32: 8404.7 (m1)
audiodsp.vector_clip_int32_rvv_i32: 2689.9 (m8)
audiodsp.vector_clipf_c: 33679.7
audiodsp.vector_clipf_rvf: 7019.7
audiodsp.vector_clipf_rvv_f32: 8328.0 (m1)
audiodsp.vector_clipf_rvv_f32: 2209.4 (m
Le torstaina 28. syyskuuta 2023, 18.33.33 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Strange, I thought FFmpeg really became popular as a back-end library for
> > mplayer, before it was picked up by all other OSS multimedia at the time
> > (gstr
Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > You can repeat the contrary as much as you want, we do not believe that
> > your SDR code fits in FFmpeg. Why do you not understand this?
>
> We understand that
Le torstaina 28. syyskuuta 2023, 19.13.37 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Thanks for making my point.
>
> Stealing the other person rhetoric device does not make you right.
>
> > That does not change the fact that it won't
Le torstaina 28. syyskuuta 2023, 19.32.44 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Err, it is very much an issue w.r.t. "catching on".
>
> Moving the goalpost much.
I think obviously not, considering the original quote (EMPHASIS ADDED):
&g
Le torstaina 28. syyskuuta 2023, 19.41.06 EEST Nicolas George a écrit :
> (1) There was no violations in my message. Calling your arguments
> bullshit is not a personal attack, by definition.
Calling BBB, Kieran and myself dishonest is.
> (2) Even if there were any violation, there is nobody to r
Le torstaina 28. syyskuuta 2023, 19.43.57 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Calling BBB, Kieran and myself dishonest is.
>
> I call your arguments dishonest.
You almost had me doubting my recollection for a minute. But:
Michael wrote:
> &g
e number of cases _should_ be low enough that
year-on-year statistics should not be very meaningful. Also that seems like
useless paperwork added on top of what is already free and not particularly
fun community service.
--
Rémi Denis-Cour
Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer
a écrit :
>On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-09-23 18:43:44)
>> > Is a seperate library really the right choice for SDR in FFmpeg at this
>> > stage ?
>> >
>> > Also
Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-09-29):
>> And as a downstream OSS application developer, I'd really rather
>> postproc be officially and properly dropped, so I can justify dropping
>> it downstream a
Le 29 septembre 2023 10:03:13 GMT+03:00, Nicolas George a
écrit :
>Well, I think this makes it obvious why I think people representing
>downstream projects should have very little influence on the future of
>FFmpeg.
First, I don't *represent* any downstream. I just happen to be one of several
Le 29 septembre 2023 14:43:11 GMT+03:00, Nicolas George a
écrit :
>Anton Khirnov (12023-09-29):
>> What does anybody gain from it being in our source tree, as opposed to a
>> separate library?
>
>Not having to maintain yet another packaging and build system.
Talk about flimsy "scraps of the bo
Remove some useless vector splat.
---
libavcodec/riscv/aacpsdsp_rvv.S | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index b581383f77..b85a5cc92c 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/l
---
libavcodec/riscv/aacpsdsp_rvv.S | 46 -
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index b85a5cc92c..1a92fed515 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/r
---
libavcodec/riscv/aacpsdsp_rvv.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index f552d50e23..007002de70 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/riscv/aacpsdsp_rvv.S
@@ -168,10 +
---
libavcodec/riscv/aacpsdsp_rvv.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index 1a92fed515..f552d50e23 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/riscv/aacpsdsp_rvv.S
@@ -38,14 +3
---
libavcodec/riscv/aacpsdsp_rvv.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index 007002de70..fe250cd83b 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/riscv/aacpsdsp_rvv.S
@@ -203,12 +
---
libavcodec/riscv/fmtconvert_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/riscv/fmtconvert_rvv.S
b/libavcodec/riscv/fmtconvert_rvv.S
index 51365753d9..d0e2f106d5 100644
--- a/libavcodec/riscv/fmtconvert_rvv.S
+++ b/libavcodec/riscv/fmtconvert_rvv.S
@@ -2
601 - 700 of 1181 matches
Mail list logo
