Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
On Sat, Nov 11, 2023 at 7:27 PM Nicolas George wrote: > Paul B Mahol (12023-11-11): > > I waited enough, applied, now for 100% true statement. > > Your teacher called, you forgot your pacifier in class yesterday. > > I am still expecting you to share the test cases you have so that the > bug can be properly fixed. > So all this time you play arrogant moves and expect something out of nothing but just posting cryptic text. The case can be simplified by just using single filter, "trim=.." with same parameters as in script. > > -- > Nicolas George > ___ > 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] [PATCH] lead: support format 0x0
Fixes ticket #10660.
---
thanks to the mysterious 'ami_stuff'.
libavcodec/leaddec.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/libavcodec/leaddec.c b/libavcodec/leaddec.c
index fd2018256d..4f2cc03e65 100644
--- a/libavcodec/leaddec.c
+++ b/libavcodec/leaddec.c
@@ -139,7 +139,7 @@ static int lead_decode_frame(AVCodecContext *avctx, AVFrame
* frame,
{
LeadContext *s = avctx->priv_data;
const uint8_t * buf = avpkt->data;
-int ret, format, yuv20p_half = 0, fields = 1, q, size;
+int ret, format, yuv420p_div = 1, yuv20p_half = 0, fields = 1, q, size;
GetBitContext gb;
int16_t dc_pred[3] = {0, 0, 0};
uint16_t dequant[2][64];
@@ -149,6 +149,10 @@ static int lead_decode_frame(AVCodecContext *avctx,
AVFrame * frame,
format = AV_RL16(buf + 4);
switch(format) {
+case 0x0:
+yuv420p_div = 2;
+avctx->pix_fmt = AV_PIX_FMT_YUV420P;
+break;
case 0x8000:
yuv20p_half = 1;
// fall-through
@@ -192,29 +196,39 @@ static int lead_decode_frame(AVCodecContext *avctx,
AVFrame * frame,
init_get_bits8(&gb, s->bitstream_buf, size);
if (avctx->pix_fmt == AV_PIX_FMT_YUV420P) {
-for (int mb_y = 0; mb_y < (avctx->height + 15) / 16; mb_y++)
+for (int mb_y = 0; mb_y < (avctx->height + (16 / yuv420p_div - 1)) /
(16 / yuv420p_div); mb_y++)
for (int mb_x = 0; mb_x < (avctx->width + 15) / 16; mb_x++)
-for (int b = 0; b < (yuv20p_half ? 4 : 6); b++) {
-int luma_block = yuv20p_half ? 2 : 4;
+for (int b = 0; b < ((yuv420p_div == 2 || yuv20p_half) ? 4 :
6); b++) {
+int luma_block = (yuv420p_div == 2 || yuv20p_half) ? 2 : 4;
const VLCElem * dc_vlc = b < luma_block ?
luma_dc_vlc.table : chroma_dc_vlc.table;
int dc_bits= b < luma_block ? LUMA_DC_BITS :
CHROMA_DC_BITS;
const VLCElem * ac_vlc = b < luma_block ?
luma_ac_vlc.table : chroma_ac_vlc.table;
int ac_bits= b < luma_block ? LUMA_AC_BITS :
CHROMA_AC_BITS;
-int plane = b < luma_block ? 0 : b -
(yuv20p_half ? 1 : 3);
-int x, y;
+int plane = b < luma_block ? 0 : b -
(luma_block - 1);
+int x, y, yclip;
if (b < luma_block) {
-y = 16*mb_y + 8*(b >> 1);
+y = (16 / yuv420p_div)*mb_y + 8*(b >> 1);
x = 16*mb_x + 8*(b & 1);
+yclip = 0;
} else {
-y = 8*mb_y;
+y = (8 / yuv420p_div)*mb_y;
x = 8*mb_x;
+yclip = (yuv420p_div == 2) && y + 8 >= avctx->height /
2;
}
-ret = decode_block(s, &gb, dc_vlc, dc_bits, ac_vlc,
ac_bits,
-dc_pred + plane, dequant[!(b < 4)],
-frame->data[plane] + y*frame->linesize[plane] + x,
-(yuv20p_half && b < 2 ? 2 : 1) *
frame->linesize[plane]);
+if (!yclip) {
+ret = decode_block(s, &gb, dc_vlc, dc_bits, ac_vlc,
ac_bits,
+dc_pred + plane, dequant[!(b < 4)],
+frame->data[plane] + y*frame->linesize[plane] + x,
+(yuv20p_half && b < 2 ? 2 : 1) *
frame->linesize[plane]);
+} else {
+uint8_t tmp[64];
+ret = decode_block(s, &gb, dc_vlc, dc_bits, ac_vlc,
ac_bits,
+dc_pred + plane, dequant[!(b < 4)], tmp, 8);
+for (int yy = 0; yy < 8 && y + yy < avctx->height / 2;
yy++)
+memcpy(frame->data[plane] +
(y+yy)*frame->linesize[plane] + x, tmp + yy, 8);
+}
if (ret < 0)
return ret;
--
2.42.0
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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] lead: support unaligned blocks
Fixed ticket #10656.
---
libavcodec/leaddec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/leaddec.c b/libavcodec/leaddec.c
index ede52fba5a..fd2018256d 100644
--- a/libavcodec/leaddec.c
+++ b/libavcodec/leaddec.c
@@ -192,8 +192,8 @@ static int lead_decode_frame(AVCodecContext *avctx, AVFrame
* frame,
init_get_bits8(&gb, s->bitstream_buf, size);
if (avctx->pix_fmt == AV_PIX_FMT_YUV420P) {
-for (int mb_y = 0; mb_y < avctx->height / 16; mb_y++)
-for (int mb_x = 0; mb_x < avctx->width / 16; mb_x++)
+for (int mb_y = 0; mb_y < (avctx->height + 15) / 16; mb_y++)
+for (int mb_x = 0; mb_x < (avctx->width + 15) / 16; mb_x++)
for (int b = 0; b < (yuv20p_half ? 4 : 6); b++) {
int luma_block = yuv20p_half ? 2 : 4;
const VLCElem * dc_vlc = b < luma_block ?
luma_dc_vlc.table : chroma_dc_vlc.table;
@@ -225,8 +225,8 @@ static int lead_decode_frame(AVCodecContext *avctx, AVFrame
* frame,
}
} else {
for (int f = 0; f < fields; f++)
-for (int j = 0; j < avctx->height / fields / 8; j++)
-for (int i = 0; i < avctx->width / 8; i++)
+for (int j = 0; j < (avctx->height + 7) / fields / 8; j++)
+for (int i = 0; i < (avctx->width + 7) / 8; i++)
for (int plane = 0; plane < 3; plane++) {
const VLCElem * dc_vlc = !plane ? luma_dc_vlc.table :
chroma_dc_vlc.table;
int dc_bits= !plane ? LUMA_DC_BITS :
CHROMA_DC_BITS;
--
2.42.0
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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] [PATCH v28 1/2] avcodec/evc_encoder: Provided support for EVC encoder
On Thu, Nov 9, 2023 at 8:21 AM Rémi Denis-Courmont wrote: > > Hi, > > Le 9 novembre 2023 12:16:28 GMT+02:00, "Dawid Kozinski/Multimedia (PLT) > /SRPOL/Staff Engineer/Samsung Electronics" a écrit : > >Hi, > > > >Both, the implementation of the EVC encoder and decoder for FFmpeg depend on > >external libraries (at least for now). They are just wrappers using external > >libraries, namely libxeve (encoder implementation) and libxevd (decoder > >implementation). > > > >The EVC defines two profiles: the "Baseline Profile" and the "Main Profile". > >For the encoder and decoder, libraries can be built for both main and > >baseline profiles as follows: > >cmake .. -DSET_PROF=BASE && make && make install > >cmake .. -DSET_PROF=MAIN && make && make install > > I guess that the point is that Linux distributions want a single library for > all profiles. You can't have two libraries with the same name, obviously. And > you also don't want two libraries with different SO names, but the > same/conflicting exported symbols and same header and function names. > > You make it sound like you have to choose a profile at compilation time, > which sounds lazy to stay polite. > Actually, no. I am not only fine with this, I *want* this. It makes it very easy for me to strip what I can't ship. But the patch here, as I can tell, requires the main profile that I cannot ship. I would like it to work with only the base profile. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Sat, Nov 11, 2023 at 11:45 PM Michael Niedermayer wrote: > > On Fri, Nov 10, 2023 at 12:39:45PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > > 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? > > while off topic and i think a flame bait. Not off topic at all. You complain about irrelevant minutae of the election and the election process, yet root admin access is controlled entirely by you. And the latter is ok but the former in your mind is not. I do not want to be root. I host quite a bit of other non public facing stuff for the project. Regards, Kieran Kunhya ___ 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
> I think you where root on the trac server you provided and where hosting > for us. > but you kicked FFmpeg out and shut that down around the time of the > vote to ban carl. But its long ago and maybe i misremember. We had a backup > server and recovered with noone noticing the trac server moved. > (now we do not have a backup server anymore) > This is a completely false allegation to make especially if you misremember. Reported to cc. 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] [ANNOUNCE] upcoming vote: extra members for GA
On Fri, Nov 10, 2023 at 12:39:45PM +, Kieran Kunhya via ffmpeg-devel wrote: > > 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? while off topic and i think a flame bait. the reason why iam one of the 6 root admins? Because in the very distant past there was a fork that controlled the server and i had no access and no server so i had to be admin on the new server. (but thats the past and its better to let this rest, the war is long over and both sides have forgotten and forgiven each other, please do not bring this up again, it was agreed by people of both sides IIRC that this subject should be layed to rest!) Also git shortlog -s -n | egrep 'Michael Niedermayer|Kieran Kunhya' 28789 Michael Niedermayer 91 Kieran Kunhya Why arpi ? because he provided the server, and risked his job for years to host it. Not once complaining about the bandwidth. And the only thing he got was hatred from the community. Only when his bosses all left and he was the only one left knowing that this server existed did we had to move. why Reimar ? because the server is hosting ffmpeg and MPlayer and reimar was at the time the main developer / "leader" of MPlayer. And even today decades later reimar is still available, if theres an emergency with the server iam confident he can make some free time to help. I think thats impressive for a 0$ per year payment. Reimar is also a major contributor and author of FFmpeg with over 1400 commits why Alexander ? he has helped with many things, trac related, backups, and same as reimar he is reliable, still around after 10+ years with 0$ per year payment why Nikolay ? He is the guy from the new place that is hosting the new server, he has helped with so many things, i cannot possibly enumerate them. From bringing up patchwork, doing upgrades, the backup system both sw and a seperate system to host them, and also doing all this for 0$ to us. Where else can you find a professional admin doing that ? Why Thresh ? He was and is admin in various places, someone with significant experience. The most recent person to join. and the backup in case everyone else is unavalable. Now i think thats a pretty decent team even if we have to pay people. But they all cost us 0$ Why not you ? I think you where root on the trac server you provided and where hosting for us. but you kicked FFmpeg out and shut that down around the time of the vote to ban carl. But its long ago and maybe i misremember. We had a backup server and recovered with noone noticing the trac server moved. (now we do not have a backup server anymore) You have extensive knowledge in the broadcast area, and i have often found your tweets funny. Iam not sure why you are sometimes so aggressive/hostile The thing is if everyone currently in FFmpeg would be working together not only would we all enjoy working in FFmpeg alot more it just would be better thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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] [PATCH] ffmpeg CLI multithreading
On Sat, Nov 04, 2023 at 08:56:09AM +0100, Anton Khirnov wrote: > Hi, > after ~2 years of work and ~700+ preparatory commits, here is finally > the first "fully functional" version of multithreaded ffmpeg CLI. In > quotes because due to the scale of the changes I'm sure some things got > broken and I didn't notice - more testing very much welcome. > > One thing which is most definitely broken is the > -fix_sub_duration_heartbeat option, which in its current form makes > assumptions about synchronization between distant components > (encoders/muxers -> decoders), which makes it fundamentally > non-deterministic when each of these components runs asynchronously > (note that its behaviour is unpredictable even now, it's just > deterministic across runs with the same options). I'm currently > disabling the option in 16/24, better suggestions on what to do with it > are welcome. > > Runtime overhead of the threading seems to be negligible in typical > cases, though it may become significant when there is very little work > per packet. You should see significantly better CPU > utilization/wallclock speedup on multicore systems whenever transcoding > isn't dominated by a a single component and the components aren't > themselves already multithreaded. > > The set is structured similarly to the previous RFC: > * 01-09/24 are preparatory fixes and could be pushed on their own well > before the rest of the series; thanks to Paul for writing 02/24 > * 10-17/24 move the two remaining components (encoding and filtering) > into threads (as before it's "fake" threading where the main thread > waits for the other thread to be done, and is thus not truly parallel) > and do other preparatory changes - these may introduce significant > temporary overhead and/or break some corner cases, so should be pushed > when the whole set is ready; > * 18/24, the biggest individual patch, adds the transcode scheduler; as > of that patch it does not yet do anything; > * 19-24/24 convert the individual components to use the scheduler; the > conversion is split for review purposes, but will have to be squashed > for the final push. > > Some more information is in my recent VDD talk [1]. You can also fetch > the code from the 'ffmpeg_threading' branch in [2]. > > Reviews, testing, and constructive comments are all very much welcome. > > [1] https://youtu.be/Z4DS3jiZhfo?t=1221 > [2] git://git.khirnov.net/libav This one infinite loops: ./ffmpeg -i tickets//383/ranft.m2v -itsoffset -00:00:00.775 -itickets//383/ranft.ac3 -bitexact -target pal-vcd /tmp/vcd.mpg (file should be here: https://trac.ffmpeg.org/raw-attachment/ticket/383/smallfiles.zip) so does this: (files attached just 320bytes) ./ffmpeg -f u8 -ar 8000 -ac 1 -i sync_audio.raw -f rawvideo -framerate 2 -s 192x144 -pix_fmt gray -i sync_video.raw -vcodec mpeg2video -acodec mp2 -y -r 2 /tmp/mpeg2_mp2.mpg These are with your branch merged into master thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire sync.tar.xz Description: application/xz 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] [PATCH] avfilter/buffersrc: switch to activate
On Sat, Nov 11, 2023 at 2:04 PM Nicolas George wrote: > Vittorio Giovara (12023-11-11): > > I said don't reply to me! > > Fortunately you have no authority over me. > I said that to avoid ridiculing yourself any more > > I'm not biased, > > You are. In this message again. > shameless accusation, trying to discredit someone who's tired of this toxic language > > The other person's behavior can be right or wrong depending on the > > interpretation, but using the language you insist on using makes you > wrong > > right away. > > “I don't know what the other did, what you did is obviously wrong” is > the discourse of adults empowering bullies everywhere by punishing the > victims who try to defend themselves. > Nice victimization, but "i'm behaving poorly because the other person is a meanie" is a childish argument > > Please just stop, you cannot have a bad day on the ml every day, it's bad > > for your mental health. > > Oh, so “pacifier” is inappropriate but this is? I hope your are only > engaging in a comedy act. I am genuinely concerned for whatever reason is pushing you to use such an alienating and toxic language, yes. -- 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 v2] treewide: Spelling fixes
On 11/11/2023 4:11 PM, Diederik de Haas via ffmpeg-devel wrote: Fix spelling issue as reported by Debian's lintian tool: accomodate -> accommodate addtional -> additional auxillary -> auxiliary avaliable -> available bellow -> below betweeen -> between Calulate -> Calculate charactor -> character coefficents -> coefficients commerical -> commercial Defalt -> Default defaul -> default higer -> higher neccesary -> necessary orignal -> original ouput -> output overriden -> overridden precison -> precision processsing -> processing streched -> stretched substract -> subtract sucessful -> successful Transfered -> Transferred upto -> up to Also add several of them to the 'common typos' check in patcheck. Signed-off-by: Diederik de Haas --- Changes in v2: - Some additional spelling fixes; now based on 6.1 vs 6.0 previously Will apply, 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".
[FFmpeg-devel] [PATCH v2] treewide: Spelling fixes
Fix spelling issue as reported by Debian's lintian tool:
accomodate -> accommodate
addtional -> additional
auxillary -> auxiliary
avaliable -> available
bellow -> below
betweeen -> between
Calulate -> Calculate
charactor -> character
coefficents -> coefficients
commerical -> commercial
Defalt -> Default
defaul -> default
higer -> higher
neccesary -> necessary
orignal -> original
ouput -> output
overriden -> overridden
precison -> precision
processsing -> processing
streched -> stretched
substract -> subtract
sucessful -> successful
Transfered -> Transferred
upto -> up to
Also add several of them to the 'common typos' check in patcheck.
Signed-off-by: Diederik de Haas
---
Changes in v2:
- Some additional spelling fixes; now based on 6.1 vs 6.0 previously
doc/decoders.texi | 2 +-
doc/demuxers.texi | 2 +-
doc/filters.texi | 52 +-
libavcodec/cbs_bsf.h | 2 +-
libavcodec/h266_metadata_bsf.c | 2 +-
libavcodec/jpeg2000dec.c | 2 +-
libavcodec/vulkan_decode.c | 2 +-
libavcodec/vvc_parser.c| 4 +--
libavdevice/pulse_audio_enc.c | 2 +-
libavfilter/af_aiir.c | 2 +-
libavfilter/af_surround.c | 2 +-
libavfilter/avfilter.h | 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 +--
libavutil/tx_template.c| 2 +-
tools/enc_recon_frame_test.c | 2 +-
tools/patcheck | 2 +-
24 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index f75364166e..016554287f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -426,7 +426,7 @@ default behavior at compilation.
@item -force_outline_text @var{boolean}
Specify whether always render outline text for all characters regardless of
-the indication by charactor style.
+the indication by character style.
The default is @var{false}.
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 13c18a2574..876027c202 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 au
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-11): > I said don't reply to me! Fortunately you have no authority over me. > I'm not biased, You are. In this message again. > reread what you wrote and think > if "pacifier" belongs on a technical mailing list. I agree. > The other person's behavior can be right or wrong depending on the > interpretation, but using the language you insist on using makes you wrong > right away. “I don't know what the other did, what you did is obviously wrong” is the discourse of adults empowering bullies everywhere by punishing the victims who try to defend themselves. > Please just stop, you cannot have a bad day on the ml every day, it's bad > for your mental health. Oh, so “pacifier” is inappropriate but this is? I hope your are only engaging in a comedy act. -- Nicolas George 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: TC/CC elections
On Sat, Nov 11, 2023 at 07:52:24PM +0100, Nicolas George wrote: > Michael Niedermayer (12023-11-11): > > Forming a new CC doesnt prevent teh old one from doing its job > > there is no relation. > > The previous CC had lost its mandate two years before. But that doesnt matter if someone insults people, gets warned insults again, gets warned insults again and the CC asks the admins to ban him the admins will ban him Thea admins can see the history of repeated offenses, they arent blind > > Also, I cannot easily find the list of members (which is a problem in jb thilo james carl dave thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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: TC/CC elections
On Sat, Nov 11, 2023 at 1:52 PM Nicolas George wrote: > itself), but I remember observing that several members were in fact very > biassed. > [citation needed] -- 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] avfilter/buffersrc: switch to activate
On Sat, Nov 11, 2023 at 1:42 PM Nicolas George wrote: > Vittorio Giovara (12023-11-11): > > No, bad Nicolas, stop this language, it's unacceptable and unbecoming. > You > > can ask for more time in a kinder manner. > > No, don't reply to me with insults or excuses, just take a walk outside > and > > reflect on your mistakes. > > Address your reproaches to the person who started the “unacceptable and > unbecoming” behavior. You just shown that you are biassed against me. > I said don't reply to me! I'm not biased, reread what you wrote and think if "pacifier" belongs on a technical mailing list. The other person's behavior can be right or wrong depending on the interpretation, but using the language you insist on using makes you wrong right away. Please just stop, you cannot have a bad day on the ml every day, it's bad for your mental health. -- 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] [ANNOUNCE] upcoming vote: TC/CC elections
Michael Niedermayer (12023-11-11): > Forming a new CC doesnt prevent teh old one from doing its job > there is no relation. The previous CC had lost its mandate two years before. Also, I cannot easily find the list of members (which is a problem in itself), but I remember observing that several members were in fact very biassed. -- Nicolas George 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: TC/CC elections
On Sat, Nov 11, 2023 at 03:37:38PM -0300, James Almer wrote: > On 11/11/2023 3:34 PM, Michael Niedermayer wrote: > > On Sun, Nov 05, 2023 at 11:02:05AM +0100, Anton Khirnov wrote: > > > Hi all, > > > as previously discussed, we need to re-elect the members of the > > > Technical and Community Committees. As a reminder - the Technical > > > Committee (TC) resolves technical disputes, while the Community > > > Committee (CC) resolves personal conflicts and code of conduct > > > violations. > > > > > > Anyone can become a member of either committee - they do not need to be > > > in GA (i.e. have voting rights). One person can also be a member of both > > > committees at once. > > > > > > The vote should start the Monday after the previous vote (extra GA > > > members) finishes - that should be either 2023-11-20 or 2023-11-27 - > > > giving us two or three weeks for discussion and proposing candidates. > > > > > > The candidates so far are: > > >* TC: > > > - Jan Ekström > > > - Anton Khirnov > > > - Lynne > > > - Martin Storsjö > > > - Niklas Haas > > > - Michael Niedermayer > > > - Mark Thompson > > >* CC: > > > - Dave Rice (IIUC it was somebody else who suggested him, so he'd > > >need to be asked whether he wants the position) > > > - James Almer > > > - Jean-Baptiste Kempf > > > - Thilo Borgmann > > > - Steven Liu > > > - Ronald Bultje > > > - Anton Khirnov > > > > > > (proposed at VDD as per Kyle's notes; I've also added myself as a CC > > > candidate). > > > > > > Anyone else wishing to volunteer for TC or CC, please reply to this > > > email. > > > > So many people want to join the CC and ive forwarded so many insults > > to the CC with no reaction and no improvment. So i guess if I complain > > that the CC isnt doing its job, i guess i must at least volunteer > > to do the job better. > > So here is my candidacy, vote for me, i lack sozial skills but > > i recognize an insult when i see one and i can ban people if a friendly > > private reminder is "misunderstood" repeatedly (IFF i have the authority to > > do that) > > If the CC is not acting it's because we're trying to get a new one formed. Forming a new CC doesnt prevent teh old one from doing its job there is no relation. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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] Repeat vote: GA voters list updates
On Sat, Nov 11, 2023 at 2:22 AM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > 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: > > [email list snipped] > > -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 > ___ > This is why we cannot have nice things. -- 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] avfilter/buffersrc: switch to activate
Vittorio Giovara (12023-11-11): > No, bad Nicolas, stop this language, it's unacceptable and unbecoming. You > can ask for more time in a kinder manner. > No, don't reply to me with insults or excuses, just take a walk outside and > reflect on your mistakes. Address your reproaches to the person who started the “unacceptable and unbecoming” behavior. You just shown that you are biassed against me. -- Nicolas George 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 11/11/2023 3:02 PM, Paul B Mahol wrote: On Sat, Nov 11, 2023 at 6:29 PM Michael Niedermayer wrote: On Sat, Nov 11, 2023 at 12:06:03AM -0300, James Almer wrote: 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? There was a swift and defensive reaction from multiple people when i suggested to nominate several of the main authors of FFmpeg to the GA. (Who many people have had no contact with for many years and many probably never had) People who interact regularly even if they dont like each other dont react that way. ive over the last decades seen this behavior commonly occur when one group is confronted with the potential introduction to their territory of another group they have had little recent contact. This seems a fundamental, unconcious and instinctive reaction humans have. I called it Xenophobia, cuz it seemed like a similar concept. Do you disagree ? (not about the term but this sort of behavior is happening) Do not try to input your projections onto us. There is no point to infiltrate your spies into community. You're throwing more fuel to the fire. Your email would have been fine without this line. I asked you to tone things down and you go and write this. Only people that give work to project can vote for project future, no people that left project. If someone nominates them, and said nomination is accepted, then they can participate. But if they left, it's likely that they don't want to participate to begin with. ___ 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] avfilter/buffersrc: switch to activate
On Sat, Nov 11, 2023 at 1:27 PM Nicolas George wrote: > Paul B Mahol (12023-11-11): > > I waited enough, applied, now for 100% true statement. > > Your teacher called, you forgot your pacifier in class yesterday > No, bad Nicolas, stop this language, it's unacceptable and unbecoming. You can ask for more time in a kinder manner. No, don't reply to me with insults or excuses, just take a walk outside and reflect on your mistakes. -- 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] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, Nov 11, 2023 at 05:58:43PM +0100, Nicolas George wrote: > Michael Niedermayer (12023-11-11): > > Also iam not sure resending mails to different addressed when they bounce > > is safe > > Lets just consider i receive a mail at niedermayer.cc, i could construct a > > bounce and > > send it back while still voting with the token in it. If i now get a mail > > at gmx.at > > i could vote twice. > > I am confused: you would get the same token in the second mail, you > would not be able to use it twice. yes, i got 2 emails with the same url with teh same token in it so i can only vote once with that (each token can only vote once) id have to check the CIVS source on how this is achieved. i guess its either storing the emails or hashes of them. or the tokens are computed from the emails so the same email results in the same token thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott 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: TC/CC elections
On 11/11/2023 3:34 PM, Michael Niedermayer wrote: On Sun, Nov 05, 2023 at 11:02:05AM +0100, Anton Khirnov wrote: Hi all, as previously discussed, we need to re-elect the members of the Technical and Community Committees. As a reminder - the Technical Committee (TC) resolves technical disputes, while the Community Committee (CC) resolves personal conflicts and code of conduct violations. Anyone can become a member of either committee - they do not need to be in GA (i.e. have voting rights). One person can also be a member of both committees at once. The vote should start the Monday after the previous vote (extra GA members) finishes - that should be either 2023-11-20 or 2023-11-27 - giving us two or three weeks for discussion and proposing candidates. The candidates so far are: * TC: - Jan Ekström - Anton Khirnov - Lynne - Martin Storsjö - Niklas Haas - Michael Niedermayer - Mark Thompson * CC: - Dave Rice (IIUC it was somebody else who suggested him, so he'd need to be asked whether he wants the position) - James Almer - Jean-Baptiste Kempf - Thilo Borgmann - Steven Liu - Ronald Bultje - Anton Khirnov (proposed at VDD as per Kyle's notes; I've also added myself as a CC candidate). Anyone else wishing to volunteer for TC or CC, please reply to this email. So many people want to join the CC and ive forwarded so many insults to the CC with no reaction and no improvment. So i guess if I complain that the CC isnt doing its job, i guess i must at least volunteer to do the job better. So here is my candidacy, vote for me, i lack sozial skills but i recognize an insult when i see one and i can ban people if a friendly private reminder is "misunderstood" repeatedly (IFF i have the authority to do that) If the CC is not acting it's because we're trying to get a new one formed. But the voting keeps being postponed because of seemingly endless bikeshedding. ___ 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: TC/CC elections
On Sun, Nov 05, 2023 at 11:02:05AM +0100, Anton Khirnov wrote: > Hi all, > as previously discussed, we need to re-elect the members of the > Technical and Community Committees. As a reminder - the Technical > Committee (TC) resolves technical disputes, while the Community > Committee (CC) resolves personal conflicts and code of conduct > violations. > > Anyone can become a member of either committee - they do not need to be > in GA (i.e. have voting rights). One person can also be a member of both > committees at once. > > The vote should start the Monday after the previous vote (extra GA > members) finishes - that should be either 2023-11-20 or 2023-11-27 - > giving us two or three weeks for discussion and proposing candidates. > > The candidates so far are: > * TC: > - Jan Ekström > - Anton Khirnov > - Lynne > - Martin Storsjö > - Niklas Haas > - Michael Niedermayer > - Mark Thompson > * CC: > - Dave Rice (IIUC it was somebody else who suggested him, so he'd > need to be asked whether he wants the position) > - James Almer > - Jean-Baptiste Kempf > - Thilo Borgmann > - Steven Liu > - Ronald Bultje > - Anton Khirnov > > (proposed at VDD as per Kyle's notes; I've also added myself as a CC > candidate). > > Anyone else wishing to volunteer for TC or CC, please reply to this > email. So many people want to join the CC and ive forwarded so many insults to the CC with no reaction and no improvment. So i guess if I complain that the CC isnt doing its job, i guess i must at least volunteer to do the job better. So here is my candidacy, vote for me, i lack sozial skills but i recognize an insult when i see one and i can ban people if a friendly private reminder is "misunderstood" repeatedly (IFF i have the authority to do that) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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] Repeat vote: GA voters list updates
On Sat, 11 Nov 2023, at 17:58, Nicolas George wrote: > Michael Niedermayer (12023-11-11): >> Lets just consider i receive a mail at niedermayer.cc, i could construct a >> bounce and >> send it back while still voting with the token in it. If i now get a mail at >> gmx.at >> i could vote twice. > > I am confused: you would get the same token in the second mail, you > would not be able to use it twice. Nicolas is very correct here: in some of the test voting, some people got the email twice, and could vote only once. TBH, all e-voting systems work like that AFAIK -- 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] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-11): > I waited enough, applied, now for 100% true statement. Your teacher called, you forgot your pacifier in class yesterday. I am still expecting you to share the test cases you have so that the bug can be properly fixed. -- Nicolas George 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
Quoting Michael Niedermayer (2023-11-11 18:28:54) > There was a swift and defensive reaction from multiple people when > i suggested to nominate several of the main authors of FFmpeg to the GA. > (Who many people have had no contact with for many years and many probably > never had) > > People who interact regularly even if they dont like each other dont react > that way. > ive over the last decades seen this behavior commonly occur when one group is > confronted with the potential introduction to their territory of another group > they have had little recent contact. > > This seems a fundamental, unconcious and instinctive reaction humans have. > I called it Xenophobia, cuz it seemed like a similar concept. > > Do you disagree ? (not about the term but this sort of behavior is happening) Consider the following alternative explanation. Our rules say: The General Assembly is made up of active contributors. Many of the people you have proposed for GA are by your own admission inactive. In other words, you are deliberately trying to subvert the intent of the rules. Why should it be surprising that people have a strongly negative reaction to that? Also, you have just implied that people disagreeing with you are unthinking zombies driven by their subconscious insticts. That is a VERY rude thing to say about someone. -- 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] [PATCH] lavc/opusdsp: R-V V deemphasis function
Considering the marginality of the measured performance gains (3-4%),
I suppose that we should not merge this. Furthermore those measurements
are not expected to improve with large vector sizes, since the code
uses only 32 bits per vector no matter what.
deemphasis_c: 7703.2
deemphasis_rvv_f32: 7452.0
---
libavcodec/riscv/opusdsp_init.c | 10 +---
libavcodec/riscv/opusdsp_rvv.S | 43 +
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/libavcodec/riscv/opusdsp_init.c b/libavcodec/riscv/opusdsp_init.c
index 88d8e77f0e..8d363aaf37 100644
--- a/libavcodec/riscv/opusdsp_init.c
+++ b/libavcodec/riscv/opusdsp_init.c
@@ -26,14 +26,18 @@
#include "libavcodec/opusdsp.h"
void ff_opus_postfilter_rvv(float *data, int period, float *g, int len);
+float ff_opus_deemphasis_rvv(float *y, float *x, float coeff, int len);
av_cold void ff_opus_dsp_init_riscv(OpusDSP *d)
{
#if HAVE_RVV
int flags = av_get_cpu_flags();
-if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR) &&
-(flags & AV_CPU_FLAG_RVB_BASIC))
-d->postfilter = ff_opus_postfilter_rvv;
+if (flags & AV_CPU_FLAG_RVV_F32) {
+if ((flags & AV_CPU_FLAG_RVB_ADDR) && (flags & AV_CPU_FLAG_RVB_BASIC))
+d->postfilter = ff_opus_postfilter_rvv;
+if (ff_get_rv_vlenb() >= 8)
+d->deemphasis = ff_opus_deemphasis_rvv;
+}
#endif
}
diff --git a/libavcodec/riscv/opusdsp_rvv.S b/libavcodec/riscv/opusdsp_rvv.S
index 79ae86c30e..839edfa4b0 100644
--- a/libavcodec/riscv/opusdsp_rvv.S
+++ b/libavcodec/riscv/opusdsp_rvv.S
@@ -64,3 +64,46 @@ func ff_opus_postfilter_rvv, zve32f
ret
endfunc
+
+// FIXME: Zvl64b
+func ff_opus_deemphasis_rvv, zve32f
+li t0, 0x3f599a00 // 0.85f
+li t1, 8
+NOHWF fmv.w.x fa0, a2
+NOHWF mv a2, a3
+vsetivli zero, 1, e32, mf2, ta, ma
+vmv.s.x v8, t0
+fmv.w.x ft0, t0
+blt a2, t1, 2f
+1:
+vlseg8e32.v v0, (a1)
+addia2, a2, -8
+vfmacc.vf v0, fa0, v8
+addia1, a1, 8 * 4
+vfmacc.vf v1, ft0, v0
+vfmacc.vf v2, ft0, v1
+vfmacc.vf v3, ft0, v2
+vfmacc.vf v4, ft0, v3
+vfmacc.vf v5, ft0, v4
+vfmacc.vf v6, ft0, v5
+vfmacc.vf v7, ft0, v6
+vfmv.f.s fa0, v7
+vsseg8e32.v v0, (a0)
+addia0, a0, 8 * 4
+bge a2, t1, 1b
+2:
+beqza2, 4f
+3:
+flw fa1, (a1)
+addia2, a2, -1
+fmadd.s fa0, ft0, fa0, fa1
+addia1, a1, 4
+fsw fa0, (a0)
+addia0, a0, 4
+bneza2, 3b
+4:
+ret
+
+NOHWF fmv.x.w a0, fa0
+ret
+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".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
On Wed, Nov 8, 2023 at 7:22 PM Nicolas George wrote: > Paul B Mahol (12023-11-08): > > I did. I simplified it right from start. But I kept it for myself as It > is > > not really relevant. > > It is very relevant for reproducing the problem and reviewing the patch. > Please show what you have, it will save time. > > > With this pace of your debugging it can be expected that universe will > > froze first before you manage to came to any conclusion about the > > "framework". > > Then work on something else. There is no urgency here. > I waited enough, applied, now for 100% true statement. > > -- > Nicolas George > ___ > 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 Sat, Nov 11, 2023 at 6:29 PM Michael Niedermayer wrote: > On Sat, Nov 11, 2023 at 12:06:03AM -0300, James Almer wrote: > > 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? > > There was a swift and defensive reaction from multiple people when > i suggested to nominate several of the main authors of FFmpeg to the GA. > (Who many people have had no contact with for many years and many probably > never had) > > People who interact regularly even if they dont like each other dont react > that way. > ive over the last decades seen this behavior commonly occur when one group > is > confronted with the potential introduction to their territory of another > group > they have had little recent contact. > > This seems a fundamental, unconcious and instinctive reaction humans have. > I called it Xenophobia, cuz it seemed like a similar concept. > > Do you disagree ? (not about the term but this sort of behavior is > happening) > Do not try to input your projections onto us. There is no point to infiltrate your spies into community. Only people that give work to project can vote for project future, no people that left project. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The greatest way to live with honor in this world is to be what we pretend > to be. -- Socrates > ___ > 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 Sat, Nov 11, 2023 at 12:06:03AM -0300, James Almer wrote: > 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? There was a swift and defensive reaction from multiple people when i suggested to nominate several of the main authors of FFmpeg to the GA. (Who many people have had no contact with for many years and many probably never had) People who interact regularly even if they dont like each other dont react that way. ive over the last decades seen this behavior commonly occur when one group is confronted with the potential introduction to their territory of another group they have had little recent contact. This seems a fundamental, unconcious and instinctive reaction humans have. I called it Xenophobia, cuz it seemed like a similar concept. Do you disagree ? (not about the term but this sort of behavior is happening) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 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] Repeat vote: GA voters list updates
Michael Niedermayer (12023-11-11): > Also iam not sure resending mails to different addressed when they bounce is > safe > Lets just consider i receive a mail at niedermayer.cc, i could construct a > bounce and > send it back while still voting with the token in it. If i now get a mail at > gmx.at > i could vote twice. I am confused: you would get the same token in the second mail, you would not be able to use it twice. Regards, -- Nicolas George 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] Recommanded best practice for voting
Hi all CIVS has a feature that allows you to pair a number with your ballot. The more people use this, and check this after the vote, the more certain it is that all votes have been counted correctly! So when you vote, pick a random number and write it down then put it in that field. After the vote check that your ballot with the number is in the list. If you want to abstain from voting, explicitly abstain and vote all choices equal while adding your random number. If everyone does this. Noone in the middle can modify or remove a ballot without being noticed. If on top of that the list of authorized voters is public and the number matches then also no ballots can be added without it being noticed. Yes i know it takes 30sec more time per voter but it makes remote votes not have to trust any intermediate or admin or anything if this is done consistantly. So i do suggest people follow the above suggestion for future 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] Repeat vote: GA voters list updates
Hi jb and everyone else On Sat, Nov 11, 2023 at 10:54:20AM +0100, Jean-Baptiste Kempf wrote: > On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote: > > Neither does this list of 51 people [1] correlate to the 54 authorized > > voters > > (distinct email addresses) the CIVS system actually counted, see [3]. > > And instead of you ASKING for that, you launch another vote? That's your > solution? I cannot speak for thilo, but i did what you suggest here and asked about multiple other inconsistencies in the vote. The replies i got where minimal, slow and at least one was not friendly at all Also IMHO if inconsistencies occure in a vote they should be made public with no one having to ask explicitly. Being reluctant to share information about problems that occured in a vote is not good practice in a open source project IMHO and also it leads to more distrust and more drama (like what started this thread) > > Just as as remark, YOU are running the voting system, and have access to > infra, so YOU can check it. thilo did share the log with me a few days ago, there is very little information in it. So little i can just provide it here with no privacy fears ill provide a summary first: (as its easier to read i think) 4 mails where sent out Mon Oct 30 10:11:20 +-1sec then 20 seconds pass then 47 mails are sent out between 10:11:41 and 10:12:20 with 0-2 seconds between the mails then 11 seconds pass then 2 mails are sent out at 10:12:31 at 10:13:42 2023 the first vote comes in then about 3 minutes pass between 10:16:20 and 10:16:48 53 mails are sent with 0-3 seconds between over 2 hours later at 12:55:40 another mail is sent overall 54 mails sent where distinct but we do not know the addresses, I do believe CIVS will not resend mails to the same address unless asked for and the same address will not be able to vote twice or be counted twice. But anyone who is in there with 2 different addresses could vote twice Now if CIVS can ensure the same address cannot vote twice it must be possible to extract the email addresses, at least before the end of the vote, But i do not know how. CIVS seems to have it as one of its goals to keep the addresses out of the logs it seems thats a mis-feature to me Also iam not sure resending mails to different addressed when they bounce is safe Lets just consider i receive a mail at niedermayer.cc, i could construct a bounce and send it back while still voting with the token in it. If i now get a mail at gmx.at i could vote twice. IMHO it should be ensured that the addresses are working before the vote and not updating them during the vote Mon Oct 30 10:11:19 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:20 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:21 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:41 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:42 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:44 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:45 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:46 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:47 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:47 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:48 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:49 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:51 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:52 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:52 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:53 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:56 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:57 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:57 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:58 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:11:58 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:00 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:01 2023 127.0.0.1 Sending mail to a voter for poll E_029f7195fed7aadf Mon Oct 30 10:12:02 2023 127.0.0.1 Sending mail to a voter f
[FFmpeg-devel] [PATCH] lavc/exrdsp: unroll predictor
With explicit unrolling, we can skip half of the sign bit flips, and
the compiler is then better able to optimise the scalar loop:
predictor_c: 31376.0 (before)
predictor_c: 23703.0 (after)
---
libavcodec/exrdsp.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/libavcodec/exrdsp.c b/libavcodec/exrdsp.c
index 752e1eb553..248cb93c5a 100644
--- a/libavcodec/exrdsp.c
+++ b/libavcodec/exrdsp.c
@@ -40,10 +40,20 @@ static void reorder_pixels_scalar(uint8_t *dst, const
uint8_t *src, ptrdiff_t si
static void predictor_scalar(uint8_t *src, ptrdiff_t size)
{
-ptrdiff_t i;
+/* Unrolled: `src[i + 1] += src[i] - 128;` */
+if ((size & 1) == 0) {
+src[1] += src[0] ^ 0x80;
+src++;
+size--;
+}
+
+for (ptrdiff_t i = 1; i < size; i += 2) {
+uint8_t a = src[i] + src[i - 1];
-for (i = 1; i < size; i++)
-src[i] += src[i-1] - 128;
+src[i] = a;
+src[i + 1] += a;
+src[i] ^= 0x80;
+}
}
av_cold void ff_exrdsp_init(ExrDSPContext *c)
--
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] [PATCH 20/24] fftools/ffmpeg_dec: convert to the scheduler
Quoting Michael Niedermayer (2023-11-04 19:30:39) > On Sat, Nov 04, 2023 at 08:56:29AM +0100, Anton Khirnov wrote: > > --- > > fftools/ffmpeg.c | 22 --- > > fftools/ffmpeg.h | 13 +- > > fftools/ffmpeg_dec.c | 315 ++- > > 3 files changed, 70 insertions(+), 280 deletions(-) > > This or the previous commit (which doesnt build without this) > breaks: > ffmpeg -y -i tickets//1714/fake_mjpeg_stream.wmv -t 1 /tmp/file1714.avi > > (infinite loop) > it can be quit with a "q" press here but with all patches applied it > seems "q" is not enough to kill it > > seems on the samples server here: > ffmpeg-bugs/trac/ticket1714/fake_mjpeg_stream.wmv Should be fixed after v3 of 18/24; updated my branch as well. -- 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] [PATCH v3 18/24] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure
See the comment block at the top of fftools/ffmpeg_sched.h for more
details on what this scheduler is for.
This commit adds the scheduling code itself, along with minimal
integration with the rest of the program:
* allocating and freeing the scheduler
* passing it throughout the call stack in order to register the
individual components (demuxers/decoders/filtergraphs/encoders/muxers)
with the scheduler
The scheduler is not actually used as of this commit, so it should not
result in any change in behavior. That will change in future commits.
---
v3:
Fix infinite loop with sync queues and -t.
Add forgotten AVClasses for SchFilterGraph and SchEnc.
v2:
keep setting OutputStream.{max_muxing_queue_size,muxing_queue_data_threshold}
until they are removed in 23/24
---
fftools/Makefile |1 +
fftools/ffmpeg.c | 18 +-
fftools/ffmpeg.h | 24 +-
fftools/ffmpeg_dec.c | 10 +-
fftools/ffmpeg_demux.c| 46 +-
fftools/ffmpeg_enc.c | 13 +-
fftools/ffmpeg_filter.c | 37 +-
fftools/ffmpeg_mux.c | 17 +-
fftools/ffmpeg_mux.h | 11 +
fftools/ffmpeg_mux_init.c | 85 +-
fftools/ffmpeg_opt.c | 22 +-
fftools/ffmpeg_sched.c| 2084 +
fftools/ffmpeg_sched.h| 461
13 files changed, 2773 insertions(+), 56 deletions(-)
create mode 100644 fftools/ffmpeg_sched.c
create mode 100644 fftools/ffmpeg_sched.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 56820e6bc8..d6a8913a7f 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -18,6 +18,7 @@ OBJS-ffmpeg += \
fftools/ffmpeg_mux.o\
fftools/ffmpeg_mux_init.o \
fftools/ffmpeg_opt.o\
+fftools/ffmpeg_sched.o \
fftools/objpool.o \
fftools/sync_queue.o\
fftools/thread_queue.o \
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f2293e0250..1a58bf98cf 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -99,6 +99,7 @@
#include "cmdutils.h"
#include "ffmpeg.h"
+#include "ffmpeg_sched.h"
#include "ffmpeg_utils.h"
#include "sync_queue.h"
@@ -1123,7 +1124,7 @@ static int transcode_step(OutputStream *ost, AVPacket
*demux_pkt)
/*
* The following code is the main loop of the file converter
*/
-static int transcode(int *err_rate_exceeded)
+static int transcode(Scheduler *sch, int *err_rate_exceeded)
{
int ret = 0, i;
InputStream *ist;
@@ -1261,6 +1262,8 @@ static int64_t getmaxrss(void)
int main(int argc, char **argv)
{
+Scheduler *sch = NULL;
+
int ret, err_rate_exceeded;
BenchmarkTimeStamps ti;
@@ -1278,8 +1281,14 @@ int main(int argc, char **argv)
show_banner(argc, argv, options);
+sch = sch_alloc();
+if (!sch) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+
/* parse options and open all input/output files */
-ret = ffmpeg_parse_options(argc, argv);
+ret = ffmpeg_parse_options(argc, argv, sch);
if (ret < 0)
goto finish;
@@ -1297,7 +1306,7 @@ int main(int argc, char **argv)
}
current_time = ti = get_benchmark_time_stamps();
-ret = transcode(&err_rate_exceeded);
+ret = transcode(sch, &err_rate_exceeded);
if (ret >= 0 && do_benchmark) {
int64_t utime, stime, rtime;
current_time = get_benchmark_time_stamps();
@@ -1317,5 +1326,8 @@ finish:
ret = 0;
ffmpeg_cleanup(ret);
+
+sch_free(&sch);
+
return ret;
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index c954ed5ebf..5833f85ab5 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -27,6 +27,7 @@
#include
#include "cmdutils.h"
+#include "ffmpeg_sched.h"
#include "sync_queue.h"
#include "libavformat/avformat.h"
@@ -713,7 +714,8 @@ int parse_and_set_vsync(const char *arg, int *vsync_var,
int file_idx, int st_id
int check_filter_outputs(void);
int filtergraph_is_simple(const FilterGraph *fg);
int init_simple_filtergraph(InputStream *ist, OutputStream *ost,
-char *graph_desc);
+char *graph_desc,
+Scheduler *sch, unsigned sch_idx_enc);
int init_complex_filtergraph(FilterGraph *fg);
int copy_av_subtitle(AVSubtitle *dst, const AVSubtitle *src);
@@ -736,7 +738,8 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational t
*/
int ifilter_parameters_from_dec(InputFilter *ifilter, const AVCodecContext
*dec);
-int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost);
+int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost,
+ unsigned sched_idx_enc);
/**
* Create a new filtergraph in the global filtergraph list.
@@ -744,7 +747,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost);
* @param graph_desc Graph description; an av_malloc()ed string, filtergraph
* takes ownership of it.
*/
-int fg_create(FilterGraph **pfg, char *graph_desc);
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC/CC elections
Le sunnuntaina 5. marraskuuta 2023, 12.02.05 EET Anton Khirnov a écrit : > Anyone else wishing to volunteer for TC or CC, please reply to this > email. I hereby "volunteer" for the CC. For those who don't know me, I am a research engineer in system software working for a large telecommunication equipment vendor. (My work is mostly proprietary, but I also have contributions to QEMU and academic publishing.) I have over twenty years experience in the open-source ecosystem. I am a maintainer for VLC and (nominally) for the Linux kernel, and the other people involved with VideoLAN here know that I am anything but a yes-person for JB. Lets build back better an FFmpeg community. Vote 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".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 11/11/2023 4:22 AM, Thilo Borgmann via ffmpeg-devel wrote: 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. Neither of these happened. It was already explained what happened. 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. No, this is completely unacceptable. 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. As others pointer out, not only would such a vote not give a different result if run with the list you shared in this email, as it's the same people + duplicate addresses, but a repeated vote knowing the result beforehand might affect people's choice, or outright have people not bother voting at all. So again, this is not ok at all and it damages the credibility of the entire system. ___ 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] Repeat vote: GA voters list updates
Le lauantaina 11. marraskuuta 2023, 13.15.37 EET Nicolas George a écrit : > Rémi Denis-Courmont (12023-11-11): > > 1) As far as was communicated, the total of alleged discrepancies in the > > voter list could not affect the result. That makes the vote valid in my > > book, and also in the legal or predecential standards in democracies: if > > elections were overturned for every inconsequential irregularities, they > > would practically never be valid. > > Except in democracies, it is not the same electoral commission that will > both make the mistakes that can be suspected to be fraud and declare > these mistakes are unimportant. This is veering very off-topic and I think we should leave personal perceptions of country politics out of ffmpeg-devel. With that said, I have been both a voting booth attendant and a vote counter in official country election. There are plenty of honest and inconsequential mistakes made, mostly by the voters, occasionally by the volunteers like myself. As for the willful violations, such as ballot stuffing or breaking in, they also do tend to take place at voting stations. Point being, the mistakes are not typically made by the commission. > I must say, my trust in some of the people running this thing is sinking > rapidly. I sympathetise with the feeling but we can't have it both ways: a remote system with automatically determined voting eligibility, and a transparent trustworthy verifiable system. The alternative is that people have to go to FOSDEM or VDD to vote in person. I guess that Michael, you and a number of other voters would not want that... -- 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".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-11): > 1) As far as was communicated, the total of alleged discrepancies in the > voter > list could not affect the result. That makes the vote valid in my book, and > also in the legal or predecential standards in democracies: if elections were > overturned for every inconsequential irregularities, they would practically > never be valid. Except in democracies, it is not the same electoral commission that will both make the mistakes that can be suspected to be fraud and declare these mistakes are unimportant. I must say, my trust in some of the people running this thing is sinking rapidly. -- Nicolas George 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] Repeat vote: GA voters list updates
Le lauantaina 11. marraskuuta 2023, 9.22.19 EET Thilo Borgmann via ffmpeg-devel a écrit : > 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. As noted several times by several people: 1) As far as was communicated, the total of alleged discrepancies in the voter list could not affect the result. That makes the vote valid in my book, and also in the legal or predecential standards in democracies: if elections were overturned for every inconsequential irregularities, they would practically never be valid. 2) As Lynne already pointed out, at this point, after results were published and voters expressed their frustration with your attempt to recall it, and forcing a vote amounts to nothing but manipulation - even if this is perhaps not your intention. If people would vote the same way they did, the result would be the same (as per the first point), regardless fo extra voters. So redoing the vote only makes sense if you expect to achieve different results by changing people's opinion or getting them to abstain. 3) As Anton already pointed out, you do not seem to have standing to declare a vote null in the first place. You were trusted to operate the voting system, not to determine the validaty of the vote. 4) As a consequence (of the previous point), this is an attempt to abuse your privileges as an adminstrator. This will be reported to the CC. 5) You are spreading more unnecessary discredit on the community and its processes, and just creatied a new convenient pretext for people to claim that the GA, CC and TC have no authority. (Previously the pretext was that the later two had expired.) This makes it an attack against the community as a whole. 6) That is yet another indirect attack against new developers (including but not limited to myself). I do very much take offense. I declare your mail null and void for all purposes other than the CC investigating your potential violations of applicable rules. It should go without spelling it out but such community-hostile attitude seems very ill-advised to me for somebody who is running for CC election or reelection. -- 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".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Sat, 11 Nov 2023, at 08:22, Thilo Borgmann via ffmpeg-devel wrote > 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 You have been told, now, several times, that a list of email is a collection of Private Information, according to a GDPR and that you are a process of this PI, and therefore liable to the law. However, neither YOU nor the legal owner FFmpeg.org explain how you will retain this information, process it further, OR, as the most important part, remove it from this mailing lists archive, when requested or when the time is over. This is illegal. -- 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] Repeat vote: GA voters list updates
Nov 11, 2023, 08:58 by an...@khirnov.net: > 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. > The voting wouldn't be genuine either, as the results have been revealed and everyone knows how much each option voted, which would allow for manipulation. Given how much time these discussions took out of coding, and making a release, and given that the list has just been refreshed, I think we should carry on with it, particularly as it will change every 6 months anyway, giving everyone a chance to participate. ___ 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] Repeat vote: GA voters list updates
> -Original Message- > From: ffmpeg-devel On Behalf Of Anton > Khirnov > Sent: 2023年11月11日 15:58 > To: FFmpeg development discussions and patches > Subject: 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. I abstain if there will another vote. I can't believe how much time have been taken on this than do some real work, like coding and patch review, and improve the situation of patch review. ___ 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".
