Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Quoting Thilo Borgmann via ffmpeg-devel (2023-11-11 08:22:19) > Hi, > > in [1] JB listed his list of authorized voters for the "GA voters list > updates" > vote. > > This list does not correlate with the list Josh provided in [2]. The word 'correlate' does not mean what you seem to think it means. The list does correlate. > Neither does this list of 51 people [1] correlate to the 54 authorized voters > (distinct email addresses) the CIVS system actually counted, see [3]. > > This can mean only one of two things, either some people on the list in [1] > did > receive more than one ballot, or JB failed to list all the authorized voters > and > ballots have been given to unknown people. Both possibilities are unacceptable > flaws for a democratic vote. > > As the admin responsible of the votes it is my duty to have supervision of all > polls and thus it is my duty to declare this vote null and void for the flaws > given above. I am not aware of anyone having given you the right to do this. > mich...@niedermayer.cc > one...@gmail.com > jamr...@gmail.com > andreas.rheinha...@gmail.com > s...@jkqxz.net > c...@passwd.hu > ceffm...@gmail.com > barryjz...@tencent.com > liuq...@kuaishou.com > lance.lmw...@gmail.com > martin.vign...@gmail.com > ffm...@gyani.pro > a...@tmm1.net > mar...@martin.st > di...@biurrun.de > lizhong1...@gmail.com > d...@lynne.ee > nfx...@googlemail.com > an...@khirnov.net > atomnu...@gmail.com > t...@rothenpieler.org > u...@pkh.me > geo...@nsup.org > yejun@intel.com > linjie...@intel.com > kaustubh.ra...@imgtec.com > stebb...@jetheaddev.com > phil...@overt.org > andriy.gel...@gmail.com > vittorio.giov...@gmail.com > jerome.borsb...@carpalis.nl > derek.buitenh...@gmail.com > pr...@xvid.org > j...@itanimul.li > kjeya...@akamai.com > dalecur...@chromium.org > jee...@gmail.com > t.r...@noa-archive.com > vdi...@akamai.com > zhiliz...@tencent.com > matthieu.bou...@gmail.com > yinshiyou...@loongson.cn > z...@zanevaniperen.com > ruiling.s...@intel.com > kjeya...@akamai.com > hwr...@126.com > modma...@google.com > c...@gmx.com > fooba...@gmail.com > baptiste.coudur...@gmail.com This list contains at least two duplicates, easily found by inspection. This gives me zero confidence that any hypothetical new vote would be any more reliable than the old one. Also as I said before, option A won its contests against options B/C/D by 17/7, 23/1, and 17/7, respectively. You would thus need to change 10 votes to have any chance of a different result. As the number of disputed voters is nowhere near 10, there is no point in repeating anything. -- Anton Khirnov ___ 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".
[FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Hi, in [1] JB listed his list of authorized voters for the "GA voters list updates" vote. This list does not correlate with the list Josh provided in [2]. Neither does this list of 51 people [1] correlate to the 54 authorized voters (distinct email addresses) the CIVS system actually counted, see [3]. This can mean only one of two things, either some people on the list in [1] did receive more than one ballot, or JB failed to list all the authorized voters and ballots have been given to unknown people. Both possibilities are unacceptable flaws for a democratic vote. As the admin responsible of the votes it is my duty to have supervision of all polls and thus it is my duty to declare this vote null and void for the flaws given above. This vote will be repeated from Sun 12th of November to Sunday 19th of November so we don't have to move the following votes yet another time. It will be using the list given by Josh [2] as it seems to be the closest to the truth we can get. The old extra members of the GA have become void according to [4] and will not be included. Furthermore, I patched the voting system to log all authorized voters in the future to prevent this situation in the future. The authorized voters for the repeated vote [2] reads as follows: mich...@niedermayer.cc one...@gmail.com jamr...@gmail.com andreas.rheinha...@gmail.com s...@jkqxz.net c...@passwd.hu ceffm...@gmail.com barryjz...@tencent.com liuq...@kuaishou.com lance.lmw...@gmail.com martin.vign...@gmail.com ffm...@gyani.pro a...@tmm1.net mar...@martin.st di...@biurrun.de lizhong1...@gmail.com d...@lynne.ee nfx...@googlemail.com an...@khirnov.net atomnu...@gmail.com t...@rothenpieler.org u...@pkh.me geo...@nsup.org yejun@intel.com linjie...@intel.com kaustubh.ra...@imgtec.com stebb...@jetheaddev.com phil...@overt.org andriy.gel...@gmail.com vittorio.giov...@gmail.com jerome.borsb...@carpalis.nl derek.buitenh...@gmail.com pr...@xvid.org j...@itanimul.li kjeya...@akamai.com dalecur...@chromium.org jee...@gmail.com t.r...@noa-archive.com vdi...@akamai.com zhiliz...@tencent.com matthieu.bou...@gmail.com yinshiyou...@loongson.cn z...@zanevaniperen.com ruiling.s...@intel.com kjeya...@akamai.com hwr...@126.com modma...@google.com c...@gmx.com fooba...@gmail.com baptiste.coudur...@gmail.com -Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316594.html [2] https://www.irccloud.com/pastebin/KNrvxILA/Votes_2020.txt [3] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf [4] https://ffmpeg.org/community.html#General-Assembly-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 "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On 11/10/2023 11:24 PM, Michael Niedermayer wrote: On Thu, Nov 09, 2023 at 11:58:29PM +0100, Jean-Baptiste Kempf wrote: On Thu, 9 Nov 2023, at 23:49, Michael Niedermayer wrote: On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote: On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote: On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote: Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit : [...] If you think some people should be added, as far as I am concerned, you are of course welcome to nudge them via private message to friendly remind them that they can nominate themselves. so what i will do then is If a developer was in the GA before || are just under the threshold but active || are part of the infra teams and packaging i will leave them in the list to be added (that is also what jb suggested) Of course, this seems reasonable. I will contact them and ask if they want to be in the GA and You should contact who you want, or think is necessary. But they should step forward and say so publicly that they are candidates. [...] Also, at that time, I did not bring a list of 20 candidates who are, for the most part, inactive. While asking "trust me, I will get their approval in private, but they will not speak on the mailing list". ok, maybe we should just slow down a bit delay the vote by a few days and discuss this to reduce peoples anxiety? :) Lets take a step back and look at what i suggested and discuss this a bit first I also have to say that this looks a bit like Xenophobia to me to be honest. How did you even get to that conclusion? I hope that word has no political connotation ohh well, i guess iam now some right or left extremist whatever is attached to the word ATM. And i can certainly CC someone like anton to verify what i send to people and what they reply. If people think i suddenly grew sozial skills to manipulate people or that i would be dishonest. (thx for the accusation btw) So we have a founder who own and pays the domain. is someone against it if he is nominated for the GA ? No one would be against that, at all. If people demand he posts in public and asks to be nominated i will not ask him as i am pretty sure he will not do that. I still think our GA should contain our founder because, hell he is our founder. As others have pointed out, any of us can nominate anyone we think would be good in the GA, but if they don't personally want to be in it or care to be in it, does it make sense to add them to begin with? Will they vote at all, or will they consider the Condorcet emails as spam? I don't mind us adding people nominated if the rest agree with said nomination. But adding people that we know or suspect don't care about the project anymore will just increase the amount of votes where a big percentage of enabled voters don't participate. Also by trying to limit the GA to a closed circle the GA is not very general and it becomes questionable if that GA can speak for FFmpeg. What iam trying to say is, if you have a group of active developers that group can speak for what the active developers want but not what the authors of FFmpeg want. OTOH if you include the main authors, founder and so on the general assembly actually is a general assembly. I agree with this. But i insist on the above. then there are teh people who publically replied Alexander, Reimar, Hendrik then there are people who run or pay our infra Baptiste Coudurier (Pays for our fate server since forever, maintains 15 things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in FFmpeg) Nikolay(root admin, he has helped with uncountable many things around the server, upgrades, backups, ...) Ok, they will clearly participate, so they are good nominations. then there are people who are active in the last 36 month but just dont make the threshold or people from the 2020-GA We did send them vote mails multiple times already Aman Karmani (17 authored commits in 2020-2023, recently active in 2023-June and work all over the codebase) Moritz Barsnick(Member of the 2020 GA but was not on jbs list) Lauri Kasanen (Linux / PowerPC maintainer) Dale Curtis(14 commits in 2020 was in the 2020-GA) foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) Huiwen Ren (8 matches in the codebase of his name, avs2* and related things maintainer) Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 entries in MAINTAINERs, 25 in copyrights) Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various bits of code, last active in git in 2020) John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 copyright match) Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in the source, last commit May
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 09, 2023 at 11:58:29PM +0100, Jean-Baptiste Kempf wrote: > On Thu, 9 Nov 2023, at 23:49, Michael Niedermayer wrote: > > On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote: > >> > >> > >> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote: > >> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote: > >> >> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a > >> >> écrit : > >> > [...] > >> >> If you think some people should be added, as far as I am concerned, you > >> >> are of > >> >> course welcome to nudge them via private message to friendly remind > >> >> them that > >> >> they can nominate themselves. > >> > > >> > so what i will do then is > >> > If a developer was in the GA before || are just under the threshold but > >> > active || are part of the infra teams and packaging > >> > i will leave them in the list to be added (that is also what jb > >> > suggested) > >> > >> Of course, this seems reasonable. > >> > >> > I will contact them and ask if they want to be in the GA and > >> > >> You should contact who you want, or think is necessary. > >> But they should step forward and say so publicly that they are candidates. [...] > Also, at that time, I did not bring a list of 20 candidates who are, for the > most part, inactive. > While asking "trust me, I will get their approval in private, but they will > not speak on the mailing list". ok, maybe we should just slow down a bit delay the vote by a few days and discuss this to reduce peoples anxiety? :) Lets take a step back and look at what i suggested and discuss this a bit first I also have to say that this looks a bit like Xenophobia to me to be honest. I hope that word has no political connotation ohh well, i guess iam now some right or left extremist whatever is attached to the word ATM. And i can certainly CC someone like anton to verify what i send to people and what they reply. If people think i suddenly grew sozial skills to manipulate people or that i would be dishonest. (thx for the accusation btw) So we have a founder who own and pays the domain. is someone against it if he is nominated for the GA ? If people demand he posts in public and asks to be nominated i will not ask him as i am pretty sure he will not do that. I still think our GA should contain our founder because, hell he is our founder. Also by trying to limit the GA to a closed circle the GA is not very general and it becomes questionable if that GA can speak for FFmpeg. What iam trying to say is, if you have a group of active developers that group can speak for what the active developers want but not what the authors of FFmpeg want. OTOH if you include the main authors, founder and so on the general assembly actually is a general assembly. then there are teh people who publically replied Alexander, Reimar, Hendrik then there are people who run or pay our infra Baptiste Coudurier (Pays for our fate server since forever, maintains 15 things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in FFmpeg) Nikolay(root admin, he has helped with uncountable many things around the server, upgrades, backups, ...) then there are people who are active in the last 36 month but just dont make the threshold or people from the 2020-GA We did send them vote mails multiple times already Aman Karmani (17 authored commits in 2020-2023, recently active in 2023-June and work all over the codebase) Moritz Barsnick(Member of the 2020 GA but was not on jbs list) Lauri Kasanen (Linux / PowerPC maintainer) Dale Curtis(14 commits in 2020 was in the 2020-GA) foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) Huiwen Ren (8 matches in the codebase of his name, avs2* and related things maintainer) Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 entries in MAINTAINERs, 25 in copyrights) Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various bits of code, last active in git in 2020) John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 copyright match) Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in the source, last commit May 2023) Then for who remains, i think it depends on what people demand. If the demand is that they must post in public, I will rest my suggestion to add people beyond above (who neeed no public post) as noone who was inactive for years is likely going to come back to ask for membership in the GA in their comeback mail. OTOH if some other request system can be agreed on then i will contact them Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, 70 copyright line matches) Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright
[FFmpeg-devel] [PATCH] lavc/sbrdsp: R-V V hf_apply_noise functions
This is restricted to 128-bit vectors as larger vector sizes could read
past the end of the noise array. Support for future hardware with larger
vector sizes is left for some other time.
hf_apply_noise_0_c: 2319.7
hf_apply_noise_0_rvv_f32: 1229.0
hf_apply_noise_1_c: 2539.0
hf_apply_noise_1_rvv_f32: 1244.7
hf_apply_noise_2_c: 2319.7
hf_apply_noise_2_rvv_f32: 1232.7
hf_apply_noise_3_c: 2541.2
hf_apply_noise_3_rvv_f32: 1244.2
---
libavcodec/riscv/sbrdsp_init.c | 17 +
libavcodec/riscv/sbrdsp_rvv.S | 67 ++
2 files changed, 84 insertions(+)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index e5736452ec..2ed46153ea 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -21,6 +21,7 @@
#include "config.h"
#include "libavutil/attributes.h"
#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
#include "libavcodec/sbrdsp.h"
void ff_sbr_sum64x5_rvv(float *z);
@@ -32,6 +33,14 @@ void ff_sbr_hf_gen_rvv(float (*X_high)[2], const float
(*X_low)[2],
float bw, int start, int end);
void ff_sbr_hf_g_filt_rvv(float (*Y)[2], const float (*X_high)[40][2],
const float *g_filt, int m_max, intptr_t ixh);
+void ff_sbr_hf_apply_noise_0_rvv(float (*Y)[2], const float *s,
+ const float *f, int n, int kx, int max);
+void ff_sbr_hf_apply_noise_1_rvv(float (*Y)[2], const float *s,
+ const float *f, int n, int kx, int max);
+void ff_sbr_hf_apply_noise_2_rvv(float (*Y)[2], const float *s,
+ const float *f, int n, int kx, int max);
+void ff_sbr_hf_apply_noise_3_rvv(float (*Y)[2], const float *s,
+ const float *f, int n, int kx, int max);
av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
{
@@ -44,6 +53,14 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
c->sum_square = ff_sbr_sum_square_rvv;
c->hf_gen = ff_sbr_hf_gen_rvv;
c->hf_g_filt = ff_sbr_hf_g_filt_rvv;
+if (ff_get_rv_vlenb() <= 16) {
+c->hf_apply_noise[0] = ff_sbr_hf_apply_noise_0_rvv;
+c->hf_apply_noise[2] = ff_sbr_hf_apply_noise_2_rvv;
+if (flags & AV_CPU_FLAG_RVB_BASIC) {
+c->hf_apply_noise[1] = ff_sbr_hf_apply_noise_1_rvv;
+c->hf_apply_noise[3] = ff_sbr_hf_apply_noise_3_rvv;
+}
+}
}
c->autocorrelate = ff_sbr_autocorrelate_rvv;
}
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index 43fab1f65f..02feb6451e 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -243,3 +243,70 @@ func ff_sbr_hf_g_filt_rvv, zve32f
ret
endfunc
+
+.macro hf_apply_noise n
+lla a6, ff_sbr_noise_table
+fmv.s.x ft0, zero
+addia6, a6, 8
+1:
+.if \n & 1
+min t0, t0, a5 // preserve parity of t0 for v4 sign injector
+vsetvli zero, t0, e32, m4, ta, mu
+.else
+vsetvli t0, a5, e32, m4, ta, mu
+.endif
+sh3add t6, a3, a6
+vle32.v v8, (a1) // s_m
+sub a5, a5, t0
+vle32.v v12, (a2) // q_filt
+sh2add a1, t0, a1
+vmfeq.vf v0, v8, ft0 // s_m == 0.f
+vlseg2e32.v v24, (t6) // ff_sbr_noise_table
+sh2add a2, t0, a2
+.if \n == 2
+vfneg.v v8, v8
+.endif
+.if \n & 1
+vfsgnjx.vv v8, v8, v4 // could equivalent use vxor.vv
+.endif
+add a3, t0, a3
+vlseg2e32.v v16, (a0) // Y
+andia3, a3, 0x1ff
+.if \n & 1
+vfmul.vv v28, v12, v28
+vfmacc.vv v16, v12, v24, v0.t
+vmerge.vvm v28, v8, v28, v0
+vfadd.vv v20, v20, v28
+.else
+vfmul.vv v24, v12, v24
+vfmacc.vv v20, v12, v28, v0.t
+vmerge.vvm v24, v8, v24, v0
+vfadd.vv v16, v16, v24
+.endif
+vsseg2e32.v v16, (a0)
+sh3add a0, t0, a0
+bneza5, 1b
+
+ret
+.endm
+
+func ff_sbr_hf_apply_noise_0_rvv, zve32f
+hf_apply_noise 0
+endfunc
+
+func ff_sbr_hf_apply_noise_3_rvv, zve32f
+ not a4, a4 // invert parity of kx
+ // fall through
+endfunc
+
+func ff_sbr_hf_apply_noise_1_rvv, zve32f
+vsetvli t0, zero, e32, m4, ta, ma
+vid.v v4
+vxor.vx v4, v4, a4
+vsll.vi v4, v4, 31 // v4[i] = (kx & 1) ? -0.f : +0.f
+hf_apply_noise 1
+endfunc
+
+func ff_sbr_hf_apply_noise_2_rvv, zve32f
+hf_apply_noise 2
+endfunc
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH] checkasm: test the noise case of sbrdsp.hf_apply_noise
The tested functions treat s_m[i] == 0 as a special case. Other than
that, the functions are slightly complicated vector additions.
This actually makes the zero case happen pseudorandomly.
---
tests/checkasm/sbrdsp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 5cc3b33215..d6c10853af 100644
--- a/tests/checkasm/sbrdsp.c
+++ b/tests/checkasm/sbrdsp.c
@@ -233,7 +233,10 @@ static void test_hf_apply_noise(const SBRDSPContext
*sbrdsp)
int kx, int m_max);
randomize((INTFLOAT *)ref, 128 * 2);
-randomize((INTFLOAT *)s_m, 128);
+
+for (int i = 0; i < 128; i++)
+s_m[i] = (rnd() & 1) ? ((INTFLOAT)rnd() / UINT_MAX) : (INTFLOAT)0;
+
randomize((INTFLOAT *)q_filt, 128);
for (i = 0; i < 4; i++) {
--
2.42.0
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, Nov 10, 2023 at 2:31 PM Michael Niedermayer wrote: > On Fri, Nov 10, 2023 at 02:24:23PM +0200, Rémi Denis-Courmont wrote: > > > [...] or at least allow people to resign from the GA discretionarily. > > I think this makes alot more sense > > Asking "I want to be in the GA" fully in public is something thats a very > high bar for some people. It certainly is a very low bar for others yes > > If we imaginge every citizen in a country would have to publically demand > in front of the whole citizenship their vote right, explain why they should > have the right and then be voted on by all before receiving the right. > Thats not something normally required to receive voting rights. > No, that is not required at all, but what is required is for people willing to vote is to register, and you cannot register someone else, unless for election fraud. Am I missing something or am I taking crazy pills? I think this bar is too high. Especially for a project that just a moment > ago complained about sustainability. > We should welcome everyone who wants to participate not setup barriers But we are welcoming everyone! And having a reliable process like it's being established *is* a way to being more sustainable. At the same time, we also need to get stuff done, so while the community noted your feedback and has taken proper action for it (delaying the vote and inviting people to candidate themselves) there is nothing else to be done about it in my opinion, so I'd suggest moving on. -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: use SDL_WaitEvent instead of SDL_PeepEvents while paused
On Fri, 10 Nov 2023, Bolshoy Toster wrote:
Currently, when ffplay is paused, it still constantly polls for events at the
REFRESH_RATE (100 times per second). This leads to a high (5-10% on the
latest
commit, using SDL2 2.28.5-1) CPU usage, when it should be idle.
This commit changes this behaviour to use SDL_WaitEvent while paused,
allowing
ffplay to use less (0-5% under X11) CPU time while paused on supported
platforms
(windows, X11 and wayland) with SDL versions >=2.0.16.
This has the side effect of only running the refresh loop when there's an
event,
preventing the cursor from being hidden while paused.
Was this always this way? Or upstream SDL changed something making the
Pump/GetEvent more resource intensive? Polling like 100 times per
second should not cause 10% cpu usage...
ALso, can this patch be made less intrusive? E.g. changing current code
around av_usleep(remainig time) to:
if (*remainig_time > 0.0) {
if (is->paused)
SDL_WaitEventTimeout(NULL, 100);
else
av_usleep()
}
Regards,
Marton
Signed-off-by: bolshoytoster
---
fftools/ffplay.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index d8c69e1..7814589 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3221,20 +3221,29 @@ static void toggle_audio_display(VideoState *is)
}
}
+static void refresh(VideoState *is, double *remaining_time) {
+if (!cursor_hidden && av_gettime_relative() - cursor_last_shown >
CURSOR_HIDE_DELAY) {
+SDL_ShowCursor(0);
+cursor_hidden = 1;
+}
+if (*remaining_time > 0.0)
+av_usleep((int64_t)(*remaining_time * 100.0));
+*remaining_time = REFRESH_RATE;
+if (is->show_mode != SHOW_MODE_NONE && (!is->paused ||
is->force_refresh))
+video_refresh(is, remaining_time);
+}
+
static void refresh_loop_wait_event(VideoState *is, SDL_Event *event) {
double remaining_time = 0.0;
-SDL_PumpEvents();
-while (!SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_FIRSTEVENT,
SDL_LASTEVENT)) {
-if (!cursor_hidden && av_gettime_relative() - cursor_last_shown
CURSOR_HIDE_DELAY) {
-SDL_ShowCursor(0);
-cursor_hidden = 1;
-}
-if (remaining_time > 0.0)
-av_usleep((int64_t)(remaining_time * 100.0));
-remaining_time = REFRESH_RATE;
-if (is->show_mode != SHOW_MODE_NONE && (!is->paused ||
is->force_refresh))
-video_refresh(is, _time);
+if (is->paused) {
+refresh(is, _time);
+SDL_WaitEvent(event);
+} else {
SDL_PumpEvents();
+while (!SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_FIRSTEVENT,
SDL_LASTEVENT)) {
+refresh(is, _time);
+SDL_PumpEvents();
+}
}
}
-- 2.42.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 "unsubscribe".
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, Nov 10, 2023 at 09:42:19PM +0200, Martin Storsjö wrote: > On Fri, 10 Nov 2023, Michael Niedermayer wrote: > > > If we imaginge every citizen in a country would have to publically demand > > in front of the whole citizenship their vote right, explain why they should > > have the right and then be voted on by all before receiving the right. > > Nobody said that there needs to be a long explanation of why oneself should > be considered. Just a "hi, please include me in the vote for extra GA > members" on the mailing list is certainly enough. If one says nothing about themselfs, who would vote for them ? Or do you commonly vote for people who just say "hi iam X please vote for me" ? only famous people can pull that off thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, 10 Nov 2023, Michael Niedermayer wrote: If we imaginge every citizen in a country would have to publically demand in front of the whole citizenship their vote right, explain why they should have the right and then be voted on by all before receiving the right. Nobody said that there needs to be a long explanation of why oneself should be considered. Just a "hi, please include me in the vote for extra GA members" on the mailing list is certainly enough. // Martin ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, Nov 10, 2023 at 02:24:23PM +0200, Rémi Denis-Courmont wrote: > [...] or at least allow people to resign from the GA discretionarily. I think this makes alot more sense Asking "I want to be in the GA" fully in public is something thats a very high bar for some people. It certainly is a very low bar for others yes If we imaginge every citizen in a country would have to publically demand in front of the whole citizenship their vote right, explain why they should have the right and then be voted on by all before receiving the right. Thats not something normally required to receive voting rights. I think this bar is too high. Especially for a project that just a moment ago complained about sustainability. We should welcome everyone who wants to participate not setup barriers thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] [PATCH] fftools/ffplay: use SDL_WaitEvent instead of SDL_PeepEvents while paused
Currently, when ffplay is paused, it still constantly polls for events
at the
REFRESH_RATE (100 times per second). This leads to a high (5-10% on the
latest
commit, using SDL2 2.28.5-1) CPU usage, when it should be idle.
This commit changes this behaviour to use SDL_WaitEvent while paused,
allowing
ffplay to use less (0-5% under X11) CPU time while paused on supported
platforms
(windows, X11 and wayland) with SDL versions >=2.0.16.
This has the side effect of only running the refresh loop when there's
an event,
preventing the cursor from being hidden while paused.
Signed-off-by: bolshoytoster
---
fftools/ffplay.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index d8c69e1..7814589 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3221,20 +3221,29 @@ static void toggle_audio_display(VideoState *is)
}
}
+static void refresh(VideoState *is, double *remaining_time) {
+if (!cursor_hidden && av_gettime_relative() - cursor_last_shown >
CURSOR_HIDE_DELAY) {
+SDL_ShowCursor(0);
+cursor_hidden = 1;
+}
+if (*remaining_time > 0.0)
+av_usleep((int64_t)(*remaining_time * 100.0));
+*remaining_time = REFRESH_RATE;
+if (is->show_mode != SHOW_MODE_NONE && (!is->paused ||
is->force_refresh))
+video_refresh(is, remaining_time);
+}
+
static void refresh_loop_wait_event(VideoState *is, SDL_Event *event) {
double remaining_time = 0.0;
-SDL_PumpEvents();
-while (!SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_FIRSTEVENT,
SDL_LASTEVENT)) {
-if (!cursor_hidden && av_gettime_relative() - cursor_last_shown
> CURSOR_HIDE_DELAY) {
-SDL_ShowCursor(0);
-cursor_hidden = 1;
-}
-if (remaining_time > 0.0)
-av_usleep((int64_t)(remaining_time * 100.0));
-remaining_time = REFRESH_RATE;
-if (is->show_mode != SHOW_MODE_NONE && (!is->paused ||
is->force_refresh))
-video_refresh(is, _time);
+if (is->paused) {
+refresh(is, _time);
+SDL_WaitEvent(event);
+} else {
SDL_PumpEvents();
+while (!SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_FIRSTEVENT,
SDL_LASTEVENT)) {
+refresh(is, _time);
+SDL_PumpEvents();
+}
}
}
-- 2.42.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 "unsubscribe".
Re: [FFmpeg-devel] [PATCH] web: add release notes for version 6.1
On Fri, Nov 10, 2023 at 6:51 AM Gyan Doshi wrote: > > > On 2023-11-10 11:09 am, Lynne wrote: > > Nov 10, 2023, 05:08 by ffm...@gyani.pro: > > > >> > >> On 2023-11-10 03:23 am, Lynne wrote: > >> > >>> Contents: > >>> > >>> + November 10th, 2023, FFmpeg 6.1 "Heaviside" > >>> + > >>> +FFmpeg 6.1 "Heaviside", a > new > >>> +major release, is now available! Some of the highlights: > >>> + > >>> + > >>> +libaribcaption decoder > >>> +Playdate video decoder and demuxer > >>> +Extend VAAPI support for libva-win32 on Windows > >>> +afireqsrc audio source filter > >>> +arls filter > >>> +ffmpeg CLI new option: -readrate_initial_burst > >>> +zoneplate video source filter > >>> +command support in the setpts and asetpts filters > >>> +Vulkan decode hwaccel, supporting H264, HEVC and AV1 > >>> +color_vulkan filter > >>> +bwdif_vulkan filter > >>> +nlmeans_vulkan filter > >>> +RivaTuner video decoder > >>> +xfade_vulkan filter > >>> +vMix video decoder > >>> +Essential Video Coding parser, muxer and demuxer > >>> +Essential Video Coding frame merge bsf > >>> +bwdif_cuda filter > >>> +Microsoft RLE video encoder > >>> +Raw AC-4 muxer and demuxer > >>> +Raw VVC bitstream parser, muxer and demuxer > >>> +Bitstream filter for editing metadata in VVC streams > >>> +Bitstream filter for converting VVC from MP4 to Annex B > >>> +scale_vt filter for videotoolbox > >>> +transpose_vt filter for videotoolbox > >>> +support for the P_SKIP hinting to speed up libx264 > encoding > >>> +Support HEVC,VP9,AV1 codec in enhanced flv format > >>> +apsnr and asisdr audio filters > >>> +OSQ demuxer and decoder > >>> +Support HEVC,VP9,AV1 codec fourcclist in enhanced rtmp > protocol > >>> +CRI USM demuxer > >>> +ffmpeg CLI '-top' option deprecated in favor of the setfield > filter > >>> +VAAPI AV1 encoder > >>> +ffprobe XML output schema changed to account for multiple > variable-fields elements within the same parent element > >>> +ffprobe -output_format option added as an alias of -of > >>> + > >>> + > >>> +This release had been overdue for at least half a year, but due > to constant activity in the repository, > >>> +had to be delayed, and we were finally able to branch off the > release recently, before some of the large > >>> +changes scheduled for 7.0 were merged. > >>> + > >>> > >> The first clause doesn't sound accurate. 6.0 was released at the end of > Feb. With a 6 month cadence, it's 2 months off schedule. > >> > >> Regards, > >> Gyan > >> > > It is inaccurate as we had planned to do releases every 2 months or so. > Every 2 months? I do not remember that. > > Isn't the schedule 2 releases a year: major in Jan, minor in Jul? > > Regards, > Gyan > > ___ > 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". > ___ 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".
[FFmpeg-devel] [PATCHv2 2/2] sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p
In my personal opinion, we should not need to support unaligned YUY2
pixel maps. They should always be aligned to at least 32 bits, and the
current code assumes just 16 bits. However checkasm does test for
unaligned input bitmaps. QEMU accepts it, but real hardware dose not.
In this particular case, we can at the same time improve performance and
handle unaligned inputs, so do just that.
uyvytoyuv422_c: 104379.0
uyvytoyuv422_c: 104060.0
uyvytoyuv422_rvv_i32: 25284.0 (before)
uyvytoyuv422_rvv_i32: 19303.2 (after)
---
libswscale/riscv/rgb2rgb.c | 6 +++--
libswscale/riscv/rgb2rgb_rvv.S | 47 ++
2 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/libswscale/riscv/rgb2rgb.c b/libswscale/riscv/rgb2rgb.c
index 565f0b77f1..4fa1f5afd9 100644
--- a/libswscale/riscv/rgb2rgb.c
+++ b/libswscale/riscv/rgb2rgb.c
@@ -55,8 +55,10 @@ av_cold void rgb2rgb_init_riscv(void)
shuffle_bytes_1230 = ff_shuffle_bytes_1230_rvv;
shuffle_bytes_3012 = ff_shuffle_bytes_3012_rvv;
interleaveBytes = ff_interleave_bytes_rvv;
-uyvytoyuv422 = ff_uyvytoyuv422_rvv;
-yuyvtoyuv422 = ff_yuyvtoyuv422_rvv;
+if (flags & AV_CPU_FLAG_RVB_BASIC) {
+uyvytoyuv422 = ff_uyvytoyuv422_rvv;
+yuyvtoyuv422 = ff_yuyvtoyuv422_rvv;
+}
}
#endif
}
diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S
index 172f5918dc..21e30ab8bb 100644
--- a/libswscale/riscv/rgb2rgb_rvv.S
+++ b/libswscale/riscv/rgb2rgb_rvv.S
@@ -126,32 +126,35 @@ func ff_deinterleave_bytes_rvv, zve32x
ret
endfunc
-.macro yuy2_to_i422p y_shift
-sllit4, a4, 1 // pixel width -> (source) byte width
+.macro yuy2_to_i422p luma, chroma
+srait4, a4, 1 // pixel width -> chroma width
lw t6, (sp)
+sllit5, a4, 1 // pixel width -> (source) byte width
sub a6, a6, a4
-sraia4, a4, 1 // pixel width -> chroma width
-sub a7, a7, a4
-sub t6, t6, t4
+sub a7, a7, t4
+sub t6, t6, t5
+vsetvli t2, zero, e8, m4, ta, ma
1:
mv t4, a4
addia5, a5, -1
2:
-vsetvlit5, t4, e8, m2, ta, ma
-vlseg2e16.v v16, (a3)
-subt4, t4, t5
-vnsrl.wi v24, v16, \y_shift // Y0
-sh2add a3, t5, a3
-vnsrl.wi v26, v20, \y_shift // Y1
-vnsrl.wi v28, v16, 8 - \y_shift // U
-vnsrl.wi v30, v20, 8 - \y_shift // V
-vsseg2e8.v v24, (a0)
-sh1add a0, t5, a0
-vse8.v v28, (a1)
-adda1, t5, a1
-vse8.v v30, (a2)
-adda2, t5, a2
-bnez t4, 2b
+min t0, t2, t4 // ensure even VL on penultimate iteration
+vsetvli t0, t0, e8, m4, ta, ma
+vlseg2e8.v v16, (a3)
+srlit1, t0, 1
+vsetvli zero, t1, e8, m2, ta, ma
+vnsrl.wi v24, \chroma, 0 // U
+sub t4, t4, t0
+vnsrl.wi v28, \chroma, 8 // V
+sh1add a3, t0, a3
+vse8.v v24, (a1)
+add a1, t1, a1
+vse8.v v28, (a2)
+add a2, t1, a2
+vsetvli zero, t0, e8, m4, ta, ma
+vse8.v \luma, (a0)
+add a0, t0, a0
+bnezt4, 2b
add a3, a3, t6
add a0, a0, a6
@@ -163,9 +166,9 @@ endfunc
.endm
func ff_uyvytoyuv422_rvv, zve32x
-yuy2_to_i422p 8
+yuy2_to_i422p v20, v16
endfunc
func ff_yuyvtoyuv422_rvv, zve32x
-yuy2_to_i422p 0
+yuy2_to_i422p v16, v20
endfunc
--
2.42.0
___
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".
[FFmpeg-devel] [PATCHv2 1/2] sws/rgb2rgb: rework R-V V YUY2 to 4:2:2 planar
This saves three scratch registers and three instructions per line. The performance gains are mostly negligible. The main point is to free up registers for further rework. --- libswscale/riscv/rgb2rgb_rvv.S | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S index 671089c842..172f5918dc 100644 --- a/libswscale/riscv/rgb2rgb_rvv.S +++ b/libswscale/riscv/rgb2rgb_rvv.S @@ -127,31 +127,30 @@ func ff_deinterleave_bytes_rvv, zve32x endfunc .macro yuy2_to_i422p y_shift -addia4, a4, 1 +sllit4, a4, 1 // pixel width -> (source) byte width lw t6, (sp) +sub a6, a6, a4 sraia4, a4, 1 // pixel width -> chroma width +sub a7, a7, a4 +sub t6, t6, t4 1: mv t4, a4 -mv t3, a3 -mv t0, a0 -mv t1, a1 -mv t2, a2 addia5, a5, -1 2: vsetvlit5, t4, e8, m2, ta, ma -vlseg2e16.v v16, (t3) +vlseg2e16.v v16, (a3) subt4, t4, t5 vnsrl.wi v24, v16, \y_shift // Y0 -sh2add t3, t5, t3 +sh2add a3, t5, a3 vnsrl.wi v26, v20, \y_shift // Y1 vnsrl.wi v28, v16, 8 - \y_shift // U vnsrl.wi v30, v20, 8 - \y_shift // V -vsseg2e8.v v24, (t0) -sh1add t0, t5, t0 -vse8.v v28, (t1) -addt1, t5, t1 -vse8.v v30, (t2) -addt2, t5, t2 +vsseg2e8.v v24, (a0) +sh1add a0, t5, a0 +vse8.v v28, (a1) +adda1, t5, a1 +vse8.v v30, (a2) +adda2, t5, a2 bnez t4, 2b add a3, a3, t6 -- 2.42.0 ___ 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".
[FFmpeg-devel] [PATCH] treewide: Spelling fixes
Fix spelling issue as reported by Debian's lintian tool:
accomodate -> accommodate
addtional -> additional
auxillary -> auxiliary
bellow -> below
betweeen -> between
Calulate -> Calculate
coefficents -> coefficients
Defalt -> Default
defaul -> default
higer -> higher
neccesary -> necessary
orignal -> original
ouput -> output
precison -> precision
processsing -> processing
substract -> subtract
Transfered -> Transferred
upto -> up to
Also add several of them to the 'common typos' check in patcheck.
Signed-off-by: Diederik de Haas
---
doc/demuxers.texi | 2 +-
doc/filters.texi | 48 +-
libavcodec/cbs_bsf.h | 2 +-
libavdevice/pulse_audio_enc.c | 2 +-
libavfilter/af_aiir.c | 2 +-
libavfilter/af_surround.c | 2 +-
libavfilter/cuda/load_helper.h | 2 +-
libavfilter/opencl/deshake.cl | 2 +-
libavfilter/vf_dedot.c | 4 +--
libavfilter/vf_transpose_npp.c | 2 +-
libavformat/dashenc.c | 2 +-
libavformat/demux.h| 2 +-
libavformat/scd.c | 2 +-
libavutil/eval.h | 2 +-
libavutil/hwcontext_vulkan.c | 4 +--
tools/enc_recon_frame_test.c | 2 +-
tools/patcheck | 2 +-
17 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index ca1563abb0..e4c5b560a6 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -777,7 +777,7 @@ error or used to store a negative value for dts correction
when treated as signe
the user set an upper limit, beyond which the delta is clamped to 1. Values
greater than the limit if negative when
cast to int32 are used to adjust onward dts.
-Unit is the track time scale. Range is 0 to UINT_MAX. Default is
@code{UINT_MAX - 48000*10} which allows upto
+Unit is the track time scale. Range is 0 to UINT_MAX. Default is
@code{UINT_MAX - 48000*10} which allows up to
a 10 second dts correction for 48 kHz audio streams while accommodating 99.9%
of @code{uint32} range.
@item interleaved_read
diff --git a/doc/filters.texi b/doc/filters.texi
index 12113d7802..f837ea7a0e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2313,7 +2313,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -3685,7 +3685,7 @@ Set order of tilt filter.
@item level
Set input volume level. Allowed range is from 0 to 4.
-Defalt is 1.
+Default is 1.
@end table
@subsection Commands
@@ -3853,7 +3853,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -3950,7 +3950,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -4057,7 +4057,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -4149,7 +4149,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -4590,7 +4590,7 @@ This filter supports the all above options as
@ref{commands}.
@section crystalizer
Simple algorithm for audio noise sharpening.
-This filter linearly increases differences betweeen each audio sample.
+This filter linearly increases differences between each audio sample.
The filter accepts the following options:
@@ -4985,7 +4985,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -5496,7 +5496,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -5856,7 +5856,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -7213,7 +7213,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
@table @option
@item auto
Pick automatic sample format depending on surround filters.
@@ -7303,7 +7303,7 @@ Set transform type of IIR filter.
@end table
@item precision, r
-Set precison of filtering.
+Set precision of filtering.
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, 10 Nov 2023, at 14:16, Michael Niedermayer wrote: >> First, because noone said anything else on that thread to ask for it to be >> public. > >> And then, because people complained after that it was not public, at the >> following meeting. >> So we said that we would do differently the following time. > > Was this a FFmpeg meeting or a (weekly) FFlabs meeting ? An FFmpeg one. > And in that one meeting FFmpeg voting was discussed towards the end of the > meeting. You remember all the contents of all FFmpeg meetings since 2020, including all the calls, the FOSDEM and VDD ones? I don't. I remember someone saying it should be public, I said: "sure, that's a good point" and that's it. If people had asked in the previous thread, that's probably what I would have done. Because I'm normal human being, who understand his limitations. People have asked for people becoming candidates to post publicly on this mailing list, I don't see what the big deal in that. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
Hi On Thu, Nov 09, 2023 at 11:58:29PM +0100, Jean-Baptiste Kempf wrote: > On Thu, 9 Nov 2023, at 23:49, Michael Niedermayer wrote: > > On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote: > >> > >> > >> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote: > >> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote: > >> >> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a > >> >> écrit : > >> > [...] > >> >> If you think some people should be added, as far as I am concerned, you > >> >> are of > >> >> course welcome to nudge them via private message to friendly remind > >> >> them that > >> >> they can nominate themselves. > >> > > >> > so what i will do then is > >> > If a developer was in the GA before || are just under the threshold but > >> > active || are part of the infra teams and packaging > >> > i will leave them in the list to be added (that is also what jb > >> > suggested) > >> > >> Of course, this seems reasonable. > >> > >> > I will contact them and ask if they want to be in the GA and > >> > >> You should contact who you want, or think is necessary. > >> But they should step forward and say so publicly that they are candidates. > > > > last time you collected candidates you said something very different > > > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265348.html > > > > "If you are interested in being a candidate, please mail me in private > > (aka not on the list). > > You can suggest another candidate, but I will validate with them if > > they might agree in the end." > > > > I want to use the exact same process, why you and other people demand > > a higher bar ? > > First, because noone said anything else on that thread to ask for it to be > public. > And then, because people complained after that it was not public, at the > following meeting. > So we said that we would do differently the following time. Was this a FFmpeg meeting or a (weekly) FFlabs meeting ? ive been in only one FFLabs meeting and that must have been years after this. So obviously thats a differnt case ... And in that one meeting FFmpeg voting was discussed towards the end of the meeting. id like to point out that FFlabs is a commercial entity and not the right place to discuss anything about FFmpeg governance or votes. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
Am 10.11.23 um 13:39 schrieb Kieran Kunhya via ffmpeg-devel: The list does not match your list, for example Gautam is on your list but not on joshs So my question is still standing, can you explain how your list was created? or where its from? How was the list of your root admins created? Who decided they would be root? Unhelpful whataboutism. -Thilo ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
Hi! > On 9 Nov 2023, at 13:28, Anton Khirnov wrote: > > Quoting James Almer (2023-11-09 13:24:45) >> Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they >> should be in the GA. > > Right, I did not mean to imply ALL the people in the above list are > inactive. But many are. Yes, I am still active and would be interested in having a voice/vote. But I'll have to bluntly admit I do not have the time or the stomach for many of the discussions on the list, which is why I've not acted on this in the past. Best regards, Reimar ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
> The list does not match your list, for example Gautam is on your list > but not on joshs > > So my question is still standing, can you explain how your list was created? > or where its from? How was the list of your root admins created? Who decided they would be root? Kieran ___ 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".
Re: [FFmpeg-devel] [PATCH] libavfilter/dnn/openvino: Reduce redundant memory allocation
> -Original Message- > From: ffmpeg-devel On Behalf Of > wenbin.chen-at-intel@ffmpeg.org > Sent: Thursday, November 9, 2023 4:13 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH] libavfilter/dnn/openvino: Reduce > redundant memory allocation > > From: Wenbin Chen > > We can directly get data ptr from tensor, so that extral memory allocation can > be removed. LGTM, will push tomorrow, thanks. ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
Le 10 novembre 2023 12:54:30 GMT+02:00, Hendrik Leppkes a écrit : >On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote: >> >> Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit : >> > that said, i checked ML subscribers and found >> > 16 of the people above to be currently subscribed with email addresses >> > that i found by greping their name. (not posting the list due to privacy >> > concerns) >> >> Thing is, if they are subscribed and still don't ask to be added to the GA, I >> don't think they should be "volunteered" by someone else. They are of course >> welcome to apply. >> > >I don't see the big difference here for people that meet an arbitrary >commit threshold, they get automatically added and not asked, but if >you are slightly under you don't. To the extent that the people who are automatically selected committed (most of) their own patches, they should have known that that would cause them to become GA members. There is indeed however a problem that somebody whose patches get merged by a third party could be induced into the GA without even knowing. That's probably concerns few if any contributiors in actual practice fortunately. >By that logic, everyone should step forward and not be "volunteered" >by a script of all things. Actually, kinda yes? The difference though is that those people aren't subject to being voted into the GA. So this can be mostly fixed by just allowing people to confirm that they want to be in the GA, or at least allow people to resign from the GA discretionarily. ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote: > On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote: > > theres a list of voters in 2020 and 2023 > > The list of voters in 2020 comes from the script written by Josh (IIRC?) and > run by Thilo (?) IIRC when Thilo installed CIVS. > It quite matches the gitlog. > > The list was reused for the vote, and now the new list was written by Anton > with the new script. > > Whatever the old script was, and how wrong it was, I don't think it would > change the result of the re-bootstrapping vote. > And now we have a clean list for the extra members of the GA. For the record, josh posted his list on IRC yesterday, the link should be in the logs. For GDPR pickiness ill not post the link here but i think the GDPR allows such investigations without consent of the involved people. thilo: I only have an email from jb with the list I originally sent him as an attachment. https://XXX/Votes_2020.txt The list does not match your list, for example Gautam is on your list but not on joshs So my question is still standing, can you explain how your list was created? or where its from? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 09, 2023 at 11:58:29PM +0100, Jean-Baptiste Kempf wrote: [...] > You want everything public, for everything, even for list of voters, and > emails, and SPI reimbursements, (for things that are something a clear > privacy and GDPR violations). But now, you want to keep private the people > who should be external GA members, while, on THIS very thread, people asked > for publicity and for candidates to speak up for their candidacy. [...] > While asking "trust me, I will get their approval in private, but they will > not speak on the mailing list". these accusations are unacceptable iam not asking for "GDPR violations", nor have i. Maybe we interpret the GDPR differently nor do or did i "want to keep private the people who should be external GA members," thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 1:24 PM James Almer wrote: > > On 11/9/2023 9:21 AM, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-11-09 12:55:25) > >> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote: > >>> As nobody expressed a preference, the vote will start next Monday > >>> (2023-11-13). It should run for a week, and will be followed by TC/CC > >>> elections. > >>> > >>> The only extra GA candidate I see proposed so far is Ronald. If anyone > >>> wants to suggest further people, please do so in this thread ASAP. > >> > >> IMHO the question of the relation of the list of people who could vote > >> in the last GA vote and the people who where in the general assembly > >> in 2020 should be awnsered before further votes. > >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > > > As far as I can tell, the voter list in the last vote should be the same > > as the GA from 2020, except for the extra members whose voting rights > > expire after 2 years. > > > > Do you dispute that? > > > >> If the current GA stays as it is, then i propose the following people > >> (this list was quickly made and certainly has omisions and possibly errors, > >> check anything thats important to you!) > >> > >> The presumed 2020 General assembly as well as people who have subtantial > >> contributions over the lifetime of the project where the source of this > >> list > > > >> Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > > > > He actually is in the GA, but his Intel mailbox bounces. > > > >> Fabrice Bellard(Founder of the project over 600 commits in FFmpeg) > >> Aman Karmani (17 authored commits in 2020-2023, recently active in > >> 2023-June and work all over the codebase) > >> Baptiste Coudurier (Pays for our fate server since forever, maintains 15 > >> things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > >> in FFmpeg) > >> Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > >> Lauri Kasanen (Linux / PowerPC maintainer) > >> Dale Curtis(14 commits in 2020 was in the 2020-GA) > >> Alexander Strasser (Root admin, just recently reported that he could not > >> vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > >> foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > >> Huiwen Ren (8 matches in the codebase of his name, avs2* and > >> related things maintainer) > >> Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > >> hostility) > >> Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > >> 2020-GA but not on jbs list) > >> Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > >> entries in MAINTAINERs, 25 in copyrights) > >> Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > >> various bits of code, last active in git in 2020) > >> John Stebbins (over 100 commits in FFmpeg, last active in git in > >> 2020, 1 copyright match) > >> Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > >> commits in FFmpeg) > >> Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > >> in the source, last commit May 2023) > >> Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > >> commit in Oct 2023, 49 matches for his name in the codebase) > >> Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > >> MAINTAINERs, 70 copyright line matches) > >> Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > >> 4 copyrights, last commit in Jul 2023) > >> Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > >> Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > >> Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > >> 22 copyright matches) > >> Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > >> Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > >> Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > Sending voting emails to people who have not had any contact with the > > project for years, can be regarded as spamming. I think there should be > > some confirmation that these people are actually interested in having > > voting rights. > > Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they > should be in the GA. Do I just reply here and say its OK to be considered, then? I haven't been sending as many patches recently as I did years ago, which happened to just die off in the period considered for the first GA. I still maintain my own open-source project based on ffmpeg, as well as using it in my dayjob. I also host a variety of Windows FATE boxes, and maintain some Windows hwaccel components. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 6:04 PM Rémi Denis-Courmont wrote: > > Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit : > > that said, i checked ML subscribers and found > > 16 of the people above to be currently subscribed with email addresses > > that i found by greping their name. (not posting the list due to privacy > > concerns) > > Thing is, if they are subscribed and still don't ask to be added to the GA, I > don't think they should be "volunteered" by someone else. They are of course > welcome to apply. > I don't see the big difference here for people that meet an arbitrary commit threshold, they get automatically added and not asked, but if you are slightly under you don't. By that logic, everyone should step forward and not be "volunteered" by a script of all things. - Hendrik ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On 09/11/2023 12:55, Michael Niedermayer wrote: On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote: As nobody expressed a preference, the vote will start next Monday (2023-11-13). It should run for a week, and will be followed by TC/CC elections. The only extra GA candidate I see proposed so far is Ronald. If anyone wants to suggest further people, please do so in this thread ASAP. IMHO the question of the relation of the list of people who could vote in the last GA vote and the people who where in the general assembly in 2020 should be awnsered before further votes. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html If the current GA stays as it is, then i propose the following people (this list was quickly made and certainly has omisions and possibly errors, check anything thats important to you!) [...] Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 commits in FFmpeg) I only do small, trivial contributions, with large time gaps in between. Will not propose myself as an extra member of the GA for this vote. Regards, Tobias ___ 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".
