Re: [FFmpeg-devel] [RFC] github assembly course ?
On Mon, 11 Nov 2024, Timo Rothenpieler wrote: On 11/11/2024 15:02, Ronald S. Bultje wrote: Hi, On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer wrote: Hi I have been given recordings of VDD by the Reconnaissance General Bureau. (didnt listen to all yet) IIUC there was a talk where it was suggested (by kieran?) to have some assembly langauge course on FFmpeg github. IMO thats a great idea. Who intends to work on that? What do i need to setup on github for that and what permission he/she needs? Actually, one of the infra questions asked was "who controls the ffmpeg github project", so does this mean the answer is you? https://github.com/orgs/FFmpeg/people Note that if you're not one of those members it seems like you don't see the individual access levels, you only see who have some sort of access privileges. In practice, out of the 4 members, 1 has level "owner" and 3 have got the level "member". (In my case it's so that I can have write access to the gas-preprocessor repo.) // 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] SIMD Motion Compensation Optimizations
On Monday, November 11th, 2024 at 3:12 AM, Rémi Denis-Courmont wrote: > > I recently read a news article about impressive AVX-512 optimizations > > of Motion Compensation functions and I'd like to learn more. > > Unfortunately, the article merely linked the post on X, which > > included a screenshot and little else. > > > > https://x.com/FFmpeg/status/1852542388851601913 > > That's a screenshot of dav1d's checkasm, so you'll find the code in dav1d, > not FFmpeg. Thanks for the pointer. I'd like to alert folks that the only way I could reproduce performance numbers similar to theirs is when I built it with '-Dbuildtype=debug'. Otherwise, the SIMD versions are all within the typical order of magnitude vs. the generic C implementations you'd normally expect. Again, I'm lacking any context concerning the original screen grab. However, the actual text of the tweet appears to be highly misleading. "A 94x speed improvement demonstrated using handwritten assembly" ___ 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] [RFC] github assembly course ?
On 11/11/2024 15:02, Ronald S. Bultje wrote: Hi, On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer wrote: Hi I have been given recordings of VDD by the Reconnaissance General Bureau. (didnt listen to all yet) IIUC there was a talk where it was suggested (by kieran?) to have some assembly langauge course on FFmpeg github. IMO thats a great idea. Who intends to work on that? What do i need to setup on github for that and what permission he/she needs? Actually, one of the infra questions asked was "who controls the ffmpeg github project", so does this mean the answer is you? https://github.com/orgs/FFmpeg/people Ronald ___ 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] [RFC] dormant git accounts
On Mon, 11 Nov 2024 17:00:42 + Derek Buitenhuis wrote: > This only convinces me further that it this whole setup ins't for for > purpose, and is being run by people who have no concept of actual > security. This is totally insane. I think it would be wiser to point to other administration of other projects , especially ones that list infrastructure in some public facing document. rather than 1. asking for a list of developers with write access 2. asking for a list of admins 3. when finding some unused developer or admin account, call the whole thing insane and blame the current admin 4. point at the lack of x, y and z as evidence the current admin is bad if your goal is to change ffmpeg admins, then just say so. if your goal is to take maintaining of ffservers so that michael can focus on code instead of admin, then just say that. if your goal is to have the GA run things, then why not have the GA vote on the plans to run ffmpeg? the GA can vote on admins, they can vote on how to fund the server, they can vote on if they want bulgaria to host ffmpeg, they can vote on all of these things and prepare what the GA wants into a plan. and then the GA can present the plan and vote yay or nay on the plan. i tried to ask the developers at vdd about this in the meeting but its possible that i didnt phrase it correctly. i apologize for that. i asked jb and jb said that videolan is one group that can host ffmpeg, at least. so thats an option for the GA to consider, should they not like our bulgarian host. if your goal is to endlessly argue , well thats ok too. what is your goal? thanks -compn ___ 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] [RFC] What to do with 15k euro from STF?
Hi Marton On Mon, Nov 11, 2024 at 08:44:32AM +0100, Marton Balint wrote: > > > On Mon, 11 Nov 2024, Michael Niedermayer wrote: > > > Hi all > > > > as we will likely have 15k available from STF "2024" for another > > task/project > > what should it be used for ? > > > > I think the obvious options are: > > > > 1. gitlab / forgeyo setup + hw + maintaince on our infrastructure > >(this was often requested by people in the last years and vittorio > > also asked about it again in the STF 2025 thread) > > > > 2. Maintainancenace of lynnes GPU based FFv1 encoder (if noone else funds > > it) > > > > 3. a small amount for patchwork maintaince for Andriy Gelman > > > > the 15k should be enough for more than one of the above > > > > PS: please be nice if you reply, we dont want to scare developers away > > from future grants. > > If somebody could go through the trac tickets and do some cleanup on them > that would be nice. Closing invalid ones, getting additional info from users > where needed, reproducing them, tracking down commits which caused a > regression, fixing severities (regressions and crashes supposed to be > important), adding fate tests where it makes sense. This is actually > continous work, which Carl Eugen did relentlessly some time ago, but it > seems nobody does it now. I agree but i dont think 15k is enough for this work we have ATM ~3000 open and new tickets. If we assume that one could do 2 tickets per hour (obtaining test samples, discussion with user, bisect, ...) which honestly iam not sure one can do 2 per hour. Some will be very quick but some will take much more time. and at lets say 120€ per hour thats about a order of magnitude more than 15k I dont think my quick guess is off by that much. Even if iam off by a factor of 2 its still quite abit more than 15k. Something like this can and should be part of STF 2025 though. For the exact cost of such issue cleanup work, I think whoever is willing to do it has to say what (s)he needs the payment for it to be. If more than one person wants to do it, the cheaper person gets the task. Of course if someone wants to cleanup 3000 tickets for 15k, iam not against that. It just seems to me too little for the amount of work thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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] ffmpeg/fftools: Set activeCodePage as UTF-8 on Windows
Recent changes in MSYS2 have changed the default console code page, which was discussed here: https://github.com/msys2/MINGW-packages/issues/22462 This results in FFMpeg compiled with that toolchain no longer accepting UTF-8 paths, unless the UTF-8 codepage is actively selected through fftools.manifest. --- fftools/fftools.manifest | 1 + 1 file changed, 1 insertion(+) diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest index f2708ecb13..eaef6cacf1 100644 --- a/fftools/fftools.manifest +++ b/fftools/fftools.manifest @@ -4,6 +4,7 @@ http://schemas.microsoft.com/SMI/2005/WindowsSettings";>true http://schemas.microsoft.com/SMI/2016/WindowsSettings";>PerMonitorV2 + http://schemas.microsoft.com/SMI/2019/WindowsSettings";>UTF-8 -- 2.47.0.windows.2 ___ 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/fftools: Set activeCodePage as UTF-8 on Windows
On Mon, 11 Nov 2024, Lars Weber wrote: Recent changes in MSYS2 have changed the default console code page, which was discussed here: https://github.com/msys2/MINGW-packages/issues/22462 This results in FFMpeg compiled with that toolchain no longer accepting UTF-8 paths, unless the UTF-8 codepage is actively selected through fftools.manifest. This description seems inaccurate to me. There hasn't been any change in default console code page. On Windows, the command line string used to launch each process is a unicode string. If the called executable isn't built in unicode mode, the command line string gets converted to the active code page, with a best-fit conversion. If that conversion isn't exact (i.e. it does a best-fit adaptation to the current code page), this can lead to security issues in some cases. The linked mingw-w64 commit therefore changed so that process startup errors out if the unicode command line can't be exactly converted to the current active code page. By flagging an executable as using utf8 as active code page, the vast majority of unicode command lines can be converted to the active code page, reducing the cases where the error occurs. The mechanisms around this change are still being discussed on the mingw-w64-public mailing list, so the current form isn't necessarily final yet. // 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] [RFC] github assembly course ?
Hi, On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer wrote: > Hi > > I have been given recordings of VDD by the Reconnaissance General Bureau. > (didnt listen to all yet) > > IIUC there was a talk where it was suggested (by kieran?) to have some > assembly langauge course on FFmpeg github. IMO thats a great idea. > > Who intends to work on that? > What do i need to setup on github for that and what permission he/she > needs? > Actually, one of the infra questions asked was "who controls the ffmpeg github project", so does this mean the answer is you? Ronald ___ 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] enc_recon_frame_test: don't print an error on EOF.
Hi,
On Fri, Nov 8, 2024 at 10:38 AM Ronald S. Bultje wrote:
> Before:
> $ make tools/enc_recon_frame_test
> $ tools/enc_recon_frame_test ~/Movies/cif/bus_cif.y4m libx264 'tune=psnr'
> Error submitting a frame for encoding
>
> After:
> All 150 encoded frames match
> ---
> tools/enc_recon_frame_test.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/enc_recon_frame_test.c b/tools/enc_recon_frame_test.c
> index c6da6750fe..83cc8343d3 100644
> --- a/tools/enc_recon_frame_test.c
> +++ b/tools/enc_recon_frame_test.c
> @@ -178,6 +178,8 @@ static int process_frame(DecodeContext *dc, AVFrame
> *frame)
> }
>
> ret = avcodec_send_frame(pd->enc, frame);
> +if (ret == AVERROR_EOF && !frame)
> +return 0;
> if (ret < 0) {
> fprintf(stderr, "Error submitting a frame for encoding\n");
> return ret;
> --
> 2.43.1
>
Will apply by Wednesday.
Ronald
___
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] SIMD Motion Compensation Optimizations
On Mon, 11 Nov 2024 14:07:21 + AV Muppet via ffmpeg-devel wrote: > On Monday, November 11th, 2024 at 3:12 AM, Rémi Denis-Courmont > wrote: > > > > I recently read a news article about impressive AVX-512 > > > optimizations of Motion Compensation functions and I'd like to > > > learn more. Unfortunately, the article merely linked the post on > > > X, which included a screenshot and little else. > > > > > > https://x.com/FFmpeg/status/1852542388851601913 > > > > That's a screenshot of dav1d's checkasm, so you'll find the code in > > dav1d, not FFmpeg. > > Thanks for the pointer. > > I'd like to alert folks that the only way I could reproduce > performance numbers similar to theirs is when I built it with > '-Dbuildtype=debug'. Otherwise, the SIMD versions are all within the > typical order of magnitude vs. the generic C implementations you'd > normally expect. > > Again, I'm lacking any context concerning the original screen grab. > However, the actual text of the tweet appears to be highly misleading. > > "A 94x speed improvement demonstrated using handwritten assembly" are you trying to say that ffmpeg should take down the tweet? well you can come on #ffmpeg-devel irc too, if you dont like twitter. -compn ___ 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 for libx265 memory leak
From 4067c58be8e719a55d89e68aaa9d3db19b88b32f Mon Sep 17 00:00:00 2001
From: Chen
Date: Fri, 8 Nov 2024 22:21:19 -0800
Subject: [PATCH] Fix memory leak in the libx265
---
libavcodec/libx265.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 63cc497..60e84d1 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -143,8 +143,10 @@ static av_cold int libx265_encode_close(AVCodecContext
*avctx)
rd_release(ctx, i);
av_freep(&ctx->rd);
-if (ctx->encoder)
+if (ctx->encoder) {
+ctx->api->cleanup();
ctx->api->encoder_close(ctx->encoder);
+}
ff_dovi_ctx_unref(&ctx->dovi);
--
2.35.1.windows.2
0001-Fix-memory-leak-in-the-libx265.patch
Description: Binary data
___
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] [RFC] github assembly course ?
On Mon, Nov 11, 2024 at 04:25:00PM +0200, Martin Storsjö wrote: > On Mon, 11 Nov 2024, Timo Rothenpieler wrote: > > > > > > > On 11/11/2024 15:02, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer > > > > > wrote: > > > > > > > Hi > > > > > > > > I have been given recordings of VDD by the Reconnaissance General > > > > Bureau. > > > > (didnt listen to all yet) > > > > > > > > IIUC there was a talk where it was suggested (by kieran?) to have some > > > > assembly langauge course on FFmpeg github. IMO thats a great idea. > > > > > > > > Who intends to work on that? > > > > What do i need to setup on github for that and what permission he/she > > > > needs? > > > > > > > > > > Actually, one of the infra questions asked was "who controls the ffmpeg > > > github project", so does this mean the answer is you? > > > > https://github.com/orgs/FFmpeg/people > > Note that if you're not one of those members it seems like you don't see the > individual access levels, you only see who have some sort of access > privileges. In practice, out of the 4 members, 1 has level "owner" and 3 > have got the level "member". (In my case it's so that I can have write > access to the gas-preprocessor repo.) github is a little messy it seems. We have a members team that gives write access to 5 repositories but even though we have 3 "members" only one was in the members team, sorry about that. everyone on github should now have write access to teh repositories (if they did not have already). btbn has further admin access as he needed that for some things That said, if we add more people to github then I need to split members from who runs a script to update the mirrors. (aka makes the mirrors read only to members) and have a seperate team for who wants to keep the mirrors up to date thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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] avcodec/cbs_h266: Fix regression in DVB clip introduced by 93281630a71c06642adfebebb0d4b105a4e02e91
On Mon, Nov 11, 2024 at 4:27 AM Frank Plowman wrote:
>
>
> On 10/11/2024 12:13, Nuo Mi wrote:
> > This commit introduced a regression to
> VVC_HDR_UHDTV1_OpenGOP_3840x2160_50fps_HLG10_mosaic.ts.
> >
> > Root Cause:
> > The AV_CEIL_RSHIFT(a, b) macro uses bit tricks that work only when -a is
> a negative value.
> > However, due to integer promotion rules, this behavior does not extend
> to the unsigned int type.
> >
> > See "6.3.1.1 Boolean, characters, and integers" in the "ISO/IEC 9899"
> for details.
> >
> > Reported-by: Frank Plowman
> > ---
> > libavcodec/cbs_h266_syntax_template.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> > index b21d07491b..6b2d6534ef 100644
> > --- a/libavcodec/cbs_h266_syntax_template.c
> > +++ b/libavcodec/cbs_h266_syntax_template.c
> > @@ -1162,7 +1162,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> > for (i = 1; i <= current->sps_num_subpics_minus1; i++) {
> > if (!current->sps_subpic_same_size_flag) {
> > if (current->sps_pic_width_max_in_luma_samples >
> ctb_size_y) {
> > -const unsigned int win_right_edge =
> > +const int win_right_edge =
> > current->sps_pic_width_max_in_luma_samples
> >- current->sps_conf_win_right_offset *
> sub_width_c;
> > us(wlen, sps_subpic_ctu_top_left_x[i], 0,
> > @@ -1172,7 +1172,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> > infer(sps_subpic_ctu_top_left_x[i], 0);
> > if (current->sps_pic_height_max_in_luma_samples >
> > ctb_size_y) {
> > -const unsigned int win_bottom_edge =
> > +const int win_bottom_edge =
> > current->sps_pic_height_max_in_luma_samples
> >- current->sps_conf_win_bottom_offset *
> sub_height_c;
> > us(hlen, sps_subpic_ctu_top_left_y[i], 0,
> > @@ -1183,9 +1183,9 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> > if (i < current->sps_num_subpics_minus1 &&
> > current->sps_pic_width_max_in_luma_samples >
> > ctb_size_y) {
> > -const unsigned int win_left_edge =
> > +const int win_left_edge =
> > current->sps_conf_win_left_offset *
> sub_width_c;
> > -const unsigned int win_left_edge_ctus =
> > +const int win_left_edge_ctus =
> > AV_CEIL_RSHIFT(win_left_edge,
> ctb_log2_size_y);
> > us(wlen, sps_subpic_width_minus1[i],
> > win_left_edge_ctus >
> current->sps_subpic_ctu_top_left_x[i]
> > @@ -1200,9 +1200,9 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
> RWContext *rw,
> > if (i < current->sps_num_subpics_minus1 &&
> > current->sps_pic_height_max_in_luma_samples >
> > ctb_size_y) {
> > -const unsigned int win_top_edge =
> > +const int win_top_edge =
> > current->sps_conf_win_top_offset *
> sub_height_c;
> > -const unsigned int win_top_edge_ctus =
> > +const int win_top_edge_ctus =
> > AV_CEIL_RSHIFT(win_top_edge,
> ctb_log2_size_y);
> > us(hlen, sps_subpic_height_minus1[i],
> > win_top_edge_ctus >
> current->sps_subpic_ctu_top_left_y[i]
>
> LGTM!
>
Thank you. Frank.
Merged and backported to 7.1 with help from James
> ___
> 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] [RFC] dormant git accounts
On Mon, Nov 11, 2024 at 10:02:27AM +, Derek Buitenhuis wrote: > On 11/10/2024 2:59 PM, Michael Niedermayer wrote: > > Its there since a long time: > > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt > > [...] > > > If something is missing, its not going to improve on its own. > > Someone will have to say _what_ is missing and work toward filling it in. > > Pretty hard to list infra you don't know exists. > > For example, I only recently noticed ffmpeg.org goes through avcodec.org DNS: > > ns1.avcodec.org - telepoint.bg > ns2.avcodec.org - KIFU (Government Info Tech Development Agency) > ns3.avcodec.org - CDLAN SpA > > Who owns avcodec.org? Who runs these DNS servers? Who has access? Who has > contacts? > > It's a supply chain attack risk - you could hijack ffmpeg.org per IP or Geo. Publically listing which developer provides which part of the DNS infra makes it easier to attack not harder. That said, i suspect who provides what was mentioned in the past already If an attacker doesnt know who provides a server then the attacker can only attack the server directly via its name and IP. If an attacker knows who owns the server then he can perform a wide range of additional attacks. For example Impersonating that developer towards the server hoster, or if the attacker can figure out the phone number of the developer then sim swaping becomes possible. From that various other accounts can then be taken over and Once an attacker is in control of phone and email of someone further account compromises become increasingly easy. I do not think we would be doing FFmpeg a service or improve security by listing everyones names in a public file. Even if most of this probably was said publically already, having it in one single place makes it even easier for an attacker thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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] [RFC] dormant git accounts
On Mon, Nov 11, 2024 at 5:31 PM compn wrote: > > On Mon, 11 Nov 2024 17:00:42 + > Derek Buitenhuis wrote: > > > This only convinces me further that it this whole setup ins't for for > > purpose, and is being run by people who have no concept of actual > > security. This is totally insane. > > I think it would be wiser to point to other administration of other > projects , especially ones that list infrastructure in some public > facing document. > > rather than > > 1. asking for a list of developers with write access > 2. asking for a list of admins > 3. when finding some unused developer or admin account, call the whole > thing insane and blame the current admin > 4. point at the lack of x, y and z as evidence the current admin is bad > > if your goal is to change ffmpeg admins, then just say so. > > if your goal is to take maintaining of ffservers so that michael can > focus on code instead of admin, then just say that. > > if your goal is to have the GA run things, then why not have the GA > vote on the plans to run ffmpeg? the GA can vote on admins, they can > vote on how to fund the server, they can vote on if they want bulgaria > to host ffmpeg, they can vote on all of these things and prepare what > the GA wants into a plan. and then the GA can present the plan and vote > yay or nay on the plan. > > i tried to ask the developers at vdd about this in the meeting but its > possible that i didnt phrase it correctly. i apologize for that. i > asked jb and jb said that videolan is one group that can host ffmpeg, > at least. so thats an option for the GA to consider, should they not > like our bulgarian host. > > if your goal is to endlessly argue , well thats ok too. > > what is your goal? > > thanks > -compn Here are some quotes presented without comment: "FFmpeg belongs to the FFmpeg developers and the FFmpeg community!" "what about root, git admin roles, ...? Well iam happy to pass them on to whoever the community chooses and trusts. But please be very carefull who you choose! until someone else is choosen i can continue doing the basic things like security updates and opening git accounts, aka theres no urgency in choosing someone, rather please choose wise than quick." "FFmpeg is yours, that is everyones. try your best to make FFmpeg be the best. Post patches, review patches, apply patches, discuss code and design. Report bugs, bisect, debug and fix bugs, add features, help users. Do friendly merges, and if you like do hostile merges. Its all up to you now!" Regards, 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 v5 12/12] avfilter/vf_scale: switch to new swscale API
On Mon, Nov 11, 2024 at 08:56:16AM +0100, Niklas Haas wrote: > From: Niklas Haas > > Most logic from this filter has been co-opted into swscale itself, > allowing the resulting filter to be substantially simpler as it no > longer has to worry about context initialization, interlacing, etc. > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Niklas Haas > --- > libavfilter/vf_scale.c | 354 + > 1 file changed, 72 insertions(+), 282 deletions(-) seems to break fate: --- ./tests/ref/pixfmt/rgb24-gray 2024-11-08 22:48:59.100234070 +0100 +++ tests/data/fate/pixfmt-rgb24-gray 2024-11-12 02:05:05.919310631 +0100 @@ -1,2 +1,2 @@ -f4d49bf8321d4348d900a947ff6122b4 *tests/data/pixfmt/rgb24-gray.yuv +4a02ab9881f8815926da9574218a8e50 *tests/data/pixfmt/rgb24-gray.yuv 7603200 tests/data/pixfmt/rgb24-gray.yuv Test pixfmt-rgb24-gray failed. Look at tests/data/fate/pixfmt-rgb24-gray.err for details. make: *** [tests/Makefile:311: fate-pixfmt-rgb24-gray] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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 v5 12/12] avfilter/vf_scale: switch to new swscale API
On 11/11/2024 10:47 PM, Michael Niedermayer wrote: On Mon, Nov 11, 2024 at 08:56:16AM +0100, Niklas Haas wrote: From: Niklas Haas Most logic from this filter has been co-opted into swscale itself, allowing the resulting filter to be substantially simpler as it no longer has to worry about context initialization, interlacing, etc. Sponsored-by: Sovereign Tech Fund Signed-off-by: Niklas Haas --- libavfilter/vf_scale.c | 354 + 1 file changed, 72 insertions(+), 282 deletions(-) seems to break fate: --- ./tests/ref/pixfmt/rgb24-gray 2024-11-08 22:48:59.100234070 +0100 +++ tests/data/fate/pixfmt-rgb24-gray 2024-11-12 02:05:05.919310631 +0100 @@ -1,2 +1,2 @@ -f4d49bf8321d4348d900a947ff6122b4 *tests/data/pixfmt/rgb24-gray.yuv +4a02ab9881f8815926da9574218a8e50 *tests/data/pixfmt/rgb24-gray.yuv 7603200 tests/data/pixfmt/rgb24-gray.yuv Test pixfmt-rgb24-gray failed. Look at tests/data/fate/pixfmt-rgb24-gray.err for details. make: *** [tests/Makefile:311: fate-pixfmt-rgb24-gray] Error 1 It's more than just that one: https://patchwork.ffmpeg.org/check/110887/ OpenPGP_signature.asc Description: OpenPGP digital 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 v5 03/12] swscale/internal: group user-facing options together
On 11/11/2024 4:56 AM, Niklas Haas wrote: From: Niklas Haas This is a preliminary step to separating these into a new struct. This commit contains no functional changes, it is a pure search-and-replace. Sponsored-by: Sovereign Tech Fund Signed-off-by: Niklas Haas --- libswscale/aarch64/swscale.c | 28 +- libswscale/aarch64/swscale_unscaled.c | 34 +- libswscale/alphablend.c | 16 +- libswscale/arm/swscale_unscaled.c | 24 +- libswscale/input.c| 2 +- libswscale/loongarch/input_lasx.c | 2 +- libswscale/loongarch/input_lsx.c | 2 +- libswscale/loongarch/output_lasx.c| 10 +- libswscale/loongarch/output_lsx.c | 10 +- libswscale/loongarch/swscale_init_loongarch.c | 24 +- https://patchwork.ffmpeg.org/check/110873/ OpenPGP_signature.asc Description: OpenPGP digital 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] [RFC] dormant git accounts
On 11/10/2024 2:59 PM, Michael Niedermayer wrote: > Its there since a long time: > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt [...] > If something is missing, its not going to improve on its own. > Someone will have to say _what_ is missing and work toward filling it in. Pretty hard to list infra you don't know exists. For example, I only recently noticed ffmpeg.org goes through avcodec.org DNS: ns1.avcodec.org - telepoint.bg ns2.avcodec.org - KIFU (Government Info Tech Development Agency) ns3.avcodec.org - CDLAN SpA Who owns avcodec.org? Who runs these DNS servers? Who has access? Who has contacts? It's a supply chain attack risk - you could hijack ffmpeg.org per IP or Geo. And this is just one example. - Derek ___ 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] lavc/x86/videodsp: Fix clobbered FPU state on x86-32
On 10/11/2024 23:57, James Almer wrote:
> On 11/10/2024 3:38 PM, Frank Plowman wrote:
>> These assembly optimisations can use MMX. They failed to reset the
>> floating-point state when they are done, hence subsequent floating-point
>> operations return nonsense values.
>>
>> This fixes the FATE failure for vvc-output-ref on x86-32, e.g.
>> https://fate.ffmpeg.org/report.cgi?slot=x86_32-uubuntu-mingw32-
>> gcc&time=20241110053421
>>
>> Signed-off-by: Frank Plowman
>> ---
>> libavcodec/x86/videodsp.asm | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
>> index 3cc07878d3..6144f13fca 100644
>> --- a/libavcodec/x86/videodsp.asm
>> +++ b/libavcodec/x86/videodsp.asm
>> @@ -313,6 +313,7 @@ cglobal emu_edge_vfix %+ %%n, 1, 5, 1, dst, src,
>> start_y, end_y, bh
>> jnz .bottom_loop ; }
>> .end:
>> + emms
>
> This needs to be added only for the MMX version, not the SSE one, so
> wrap it in a %if mmsize == 8 check.
>
I thought the same before submitting this patch, and tried only adding
the line conditionally based on the mmsize, but found neither wrapping
it in an a) mmsize == 8, nor b) mmsize != 8 block alone worked.
Seemingly the line cannot be run conditionally based on mmsize. I'm not
quite sure of the mechanism behind this, there's a lot of preprocessor
macros to untangle in {READ,WRITE}_NUM_BYTES.
Cheers,
Frank
___
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] root access voting
On 11/6/2024 2:48 PM, Michael Niedermayer wrote: > do i unilaterally decide who i trust as root, maybe. Q.E.D. That, along with Fabrice's control of ffmpeg.org and French trademark, despite not havign contributed in 20 years, purely for ego reasons, mean we can never move to a truly community run set or project infra. If you are so concerned about stuff like GA stacking and people having a say (see: democracy), consider that the memebrs of the GA *are* FFmpeg. They make up the project and its code and its community. Not you, and not some weird set of old mplayer people who are 'trustworthy'. If I am honest, the way I read this whole saga is you desperately trying retain what singular control you have left, along with some paranoid delusions of a VideoLAN takeover, or something. I don't say this to be rude, but I think you can benefit from speaking to a professional for some help - this isn't healthy. - Derek ___ 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] lavc/vvc: Remove floating point logic
On Mon, Nov 11, 2024 at 4:24 AM Frank Plowman wrote:
> This was the only floating point logic in the native VVC decoder.
>
👍, applied.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/intra_utils.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vvc/intra_utils.c b/libavcodec/vvc/intra_utils.c
> index 8c40eb1b16..7229222b95 100644
> --- a/libavcodec/vvc/intra_utils.c
> +++ b/libavcodec/vvc/intra_utils.c
> @@ -184,13 +184,13 @@ int ff_vvc_intra_pred_angle_derive(const int
> pred_mode)
> return intra_pred_angle;
> }
>
> -#define ROUND(f) (int)(f < 0 ? -(-f + 0.5) : (f + 0.5))
> int ff_vvc_intra_inv_angle_derive(const int intra_pred_angle)
> {
> -float inv_angle;
> -av_assert0(intra_pred_angle);
> -inv_angle = 32 * 512.0 / intra_pred_angle;
> -return ROUND(inv_angle);
> +av_assert2(intra_pred_angle != 0);
> +if (intra_pred_angle > 0)
> +return ROUNDED_DIV(32*512, intra_pred_angle);
> +else
> +return -ROUNDED_DIV(32*512, -intra_pred_angle);
> }
>
> //8.4.5.2.7 Wide angle intra prediction mode mapping proces
> --
> 2.47.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 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] x86/vvc: Fix build error for arch x86_32
On Sat, Nov 2, 2024 at 1:27 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> There were static functions which built for x86_32, but the simd
> functions they reference only available for x86_64.
>
Thank you, Zhili,
Merged
> ---
> libavcodec/x86/vvc/vvcdsp_init.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c
> b/libavcodec/x86/vvc/vvcdsp_init.c
> index f3e2e3a27b..7b6aa50676 100644
> --- a/libavcodec/x86/vvc/vvcdsp_init.c
> +++ b/libavcodec/x86/vvc/vvcdsp_init.c
> @@ -30,6 +30,8 @@
> #include "libavcodec/vvc/dsp.h"
> #include "libavcodec/x86/h26x/h2656dsp.h"
>
> +#if ARCH_X86_64
> +
> #define PUT_PROTOTYPE(name, depth, opt) \
> void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
> uint8_t *src, ptrdiff_t srcstride, int height, const int8_t *hf, const
> int8_t *vf, int width);
>
> @@ -356,6 +358,9 @@ int ff_vvc_sad_avx2(const int16_t *src0, const int16_t
> *src1, int dx, int dy, in
> #define SAD_INIT() c->inter.sad = ff_vvc_sad_avx2
> #endif
>
> +
> +#endif // ARCH_X86_64
> +
> void ff_vvc_dsp_init_x86(VVCDSPContext *const c, const int bd)
> {
> #if ARCH_X86_64
> --
> 2.34.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] SIMD Motion Compensation Optimizations
Hi, Le 11 novembre 2024 04:11:22 GMT+02:00, AV Muppet via ffmpeg-devel a écrit : >Dear ffmpeg developers, > >I recently read a news article about impressive AVX-512 optimizations >of Motion Compensation functions and I'd like to learn more. >Unfortunately, the article merely linked the post on X, which >included a screenshot and little else. > >https://x.com/FFmpeg/status/1852542388851601913 That's a screenshot of dav1d's checkasm, so you'll find the code in dav1d, not FFmpeg. ___ 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] fate/jpeg2000dec: add missing ISO/IEC 15444-4 conformance tests
I have confirmed that these failures in FATE were due to the insufficient floating point precision of a 32-bit environment. The commit 82467b635efced67c1767cb810af1f3c31a2e493 introduces the improved dequantization in FF_DWT97_INT path and makes FFmpeg compliant for ISO/IEC 15444-4 (Conformance testing.) Actually, both 64 and 32-bit FFmpeg with the commit pass the conformance testing. Current FATE tests for JPEG 2000 are to check the CRC of reconstructed images. Checking CRC is unsuitable for lossy codestream because even a patch that can improve the quality of a reconstructed image cannot pass the FATE. Passing FATE is, of course, important, but passing the official (ISO's) conformance tests is essential, too. I recommend introducing a way to allow some tolerance in FATE tests for JPEG 2000 lossy codestreams. For example, including the original files and using the PSNR value in FATE will be an option. > On Nov 10, 2024, at 10:40, Michael Niedermayer wrote: > > On Fri, Nov 08, 2024 at 01:09:34PM -0800, p...@sandflow.com wrote: >> From: Pierre-Anthony Lemieux >> >> --- >> tests/fate/jpeg2000.mak | 122 ++- >> tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_02_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_03_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_03_b12 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_04_b9 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_05_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-ds1_ht_06_b11 | 6 ++ >> tests/ref/fate/jpeg2000dec-hifi_ht1_02 | 6 ++ >> tests/ref/fate/jpeg2000dec-hifi_p1_02| 6 ++ >> tests/ref/fate/jpeg2000dec-p1_01 | 6 ++ >> tests/ref/fate/jpeg2000dec-p1_02 | 6 ++ >> tests/ref/fate/jpeg2000dec-p1_03 | 6 ++ >> tests/ref/fate/jpeg2000dec-p1_04 | 6 ++ >> tests/ref/fate/jpeg2000dec-p1_05 | 6 ++ >> tests/ref/fate/jpeg2000dec-p1_06 | 6 ++ >> 41 files changed, 361 insertions(+), 1 deletion(-) >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_hm_15_b8 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_02_b12 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_03_b14 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_04_b12 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_05_b12 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b15 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_07_b16 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b15 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_08_b16 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_09_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_10_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_11_b10 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_12_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_14_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_15_b14 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds0_ht_16_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b11 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_01_b12 >> create mode 100644 tests/ref/fate/jpeg2000dec-ds1_ht_02_b11 >> create
Re: [FFmpeg-devel] [PATCH v7] avcodec/jpeg2000: Fix FF_DWT97_INT to pass the conformance testing defined in ISO/IEC 15444-4
Thanks. I found the cause of these UBSAN errors. I will send a patch to fix those soon. > On Nov 10, 2024, at 0:54, James Almer wrote: > > On 11/8/2024 2:23 AM, Pierre-Anthony Lemieux wrote: >> Ok will merge the patch below. > > src/libavcodec/jpeg2000dec.c:1972:117: runtime error: left shift of 1 by 31 > places cannot be represented in type 'int' > > https://fate.ffmpeg.org/report.cgi?time=20241109021127&slot=x86_64-archlinux-gcc-ubsan > ___ > 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] avcodec/jpeg2000: Fix undefined behaviour in left shift operations
This patch fixes undefined behaviour error in left shift
operations in jpeg2000dec.c and jpeg2000htdec.c.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 6 +++---
libavcodec/jpeg2000htdec.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index c9d8b025b1..8054129589 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1886,10 +1886,10 @@ static void decode_sigpass(Jpeg2000T1Context *t1, int
width, int height,
if (ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
ff_jpeg2000_getsigctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
bandno))) {
int xorbit, ctxno =
ff_jpeg2000_getsgnctxno(t1->flags[(y+1) * t1->stride + x+1] & flags_mask,
&xorbit);
if (t1->mqc.raw) {
-t1->data[(y) * t1->stride + x] |=
ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) << 31;
+t1->data[(y) * t1->stride + x] |=
(int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno)) << 31);
t1->data[(y) * t1->stride + x] |= mask;
} else {
-t1->data[(y) * t1->stride + x] |=
(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
+t1->data[(y) * t1->stride + x] |=
(int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit)
<< 31);
t1->data[(y) * t1->stride + x] |= mask;
}
ff_jpeg2000_set_significance(t1, x, y,
@@ -1969,7 +1969,7 @@ static void decode_clnpass(const Jpeg2000DecoderContext
*s, Jpeg2000T1Context *t
int xorbit;
int ctxno = ff_jpeg2000_getsgnctxno(t1->flags[(y + 1) *
t1->stride + x + 1] & flags_mask,
&xorbit);
-t1->data[(y) * t1->stride + x] |= (ff_mqc_decode(&t1->mqc,
t1->mqc.cx_states + ctxno) ^ xorbit) << 31;
+t1->data[(y) * t1->stride + x] |=
(int)((uint32_t)(ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + ctxno) ^ xorbit)
<< 31);
t1->data[(y) * t1->stride + x] |= mask;
ff_jpeg2000_set_significance(t1, x, y, t1->data[(y) *
t1->stride + x] & INT32_MIN);
}
diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
index 186a6873ac..b4bb6dcf33 100644
--- a/libavcodec/jpeg2000htdec.c
+++ b/libavcodec/jpeg2000htdec.c
@@ -1070,7 +1070,7 @@ static void jpeg2000_process_stripes_block(StateVars
*sig_prop, int i_s, int j_s
uint8_t *state_p = block_states + (i + 1) * stride + (j + 1);
if ((state_p[0] >> HT_SHIFT_REF) & 1) {
bit = jpeg2000_peek_bit(sig_prop, magref_segment,
magref_length);
-*sp |= (int32_t)bit << 31;
+*sp |= (int32_t)((uint32_t)bit << 31);
}
}
}
@@ -1160,7 +1160,7 @@ jpeg2000_decode_magref_segment( uint16_t width, uint16_t
block_height, const int
jpeg2000_modify_state(i, j, stride, 1 << HT_SHIFT_REF_IND,
block_states);
bit = jpeg2000_import_magref_bit(&mag_ref, magref_segment,
magref_length);
tmp = 0xFFFE | (uint32_t)bit;
-tmp <<= pLSB;
+tmp = (int32_t)((uint32_t)tmp << pLSB);
sp[0] &= tmp;
sp[0] |= 1 << (pLSB - 1); // Add 0.5 (reconstruction
parameter = 1/2)
}
@@ -1176,7 +1176,7 @@ jpeg2000_decode_magref_segment( uint16_t width, uint16_t
block_height, const int
jpeg2000_modify_state(i, j, stride, 1 << HT_SHIFT_REF_IND,
block_states);
bit = jpeg2000_import_magref_bit(&mag_ref, magref_segment,
magref_length);
tmp = 0xFFFE | (uint32_t)bit;
-tmp <<= pLSB;
+tmp = (int32_t)((uint32_t)tmp << pLSB);
sp[0] &= tmp;
sp[0] |= 1 << (pLSB - 1); // Add 0.5 (reconstruction parameter
= 1/2)
}
--
2.43.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 v5 10/12] tests/swscale: rewrite on top of new API
From: Niklas Haas
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against the old one, to serve as an unchanging reference. This
does not accomplish much yet, but serves as a framework for future work.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/tests/swscale.c | 665 -
1 file changed, 284 insertions(+), 381 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index af8069f728..c11a46024e 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (C) 2024 Nikles Haas
* Copyright (C) 2003-2011 Michael Niedermayer
*
* This file is part of FFmpeg.
@@ -26,424 +27,307 @@
#undef HAVE_AV_CONFIG_H
#include "libavutil/cpu.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/mem.h"
-#include "libavutil/avutil.h"
-#include "libavutil/crc.h"
-#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/lfg.h"
#include "libavutil/sfc64.h"
+#include "libavutil/frame.h"
+#include "libavutil/pixfmt.h"
+#include "libavutil/avassert.h"
+#include "libavutil/macros.h"
#include "libswscale/swscale.h"
-/* HACK Duplicated from swscale_internal.h.
- * Should be removed when a cleaner pixel format system exists. */
-#define isGray(x) \
-((x) == AV_PIX_FMT_GRAY8 || \
- (x) == AV_PIX_FMT_YA8 || \
- (x) == AV_PIX_FMT_GRAY16BE|| \
- (x) == AV_PIX_FMT_GRAY16LE|| \
- (x) == AV_PIX_FMT_YA16BE || \
- (x) == AV_PIX_FMT_YA16LE)
-#define hasChroma(x) \
-(!(isGray(x)|| \
- (x) == AV_PIX_FMT_MONOBLACK || \
- (x) == AV_PIX_FMT_MONOWHITE))
-
-static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
-{
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-return desc->flags & AV_PIX_FMT_FLAG_ALPHA;
-}
+enum {
+WIDTH = 96,
+HEIGHT = 96,
+};
-static double prob = 1;
-FFSFC64 prng_state;
+struct options {
+enum AVPixelFormat src_fmt;
+enum AVPixelFormat dst_fmt;
+double prob;
+};
-static uint64_t getSSD(const uint8_t *src1, const uint8_t *src2,
- int stride1, int stride2, int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+struct mode {
+SwsFlags flags;
+SwsDither dither;
+};
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - src2[x + y * stride2];
-ssd += d * d;
-}
-}
-return ssd;
-}
+const int dst_w[] = { WIDTH, WIDTH - WIDTH / 3, WIDTH + WIDTH / 3 };
+const int dst_h[] = { HEIGHT, HEIGHT - HEIGHT / 3, HEIGHT + HEIGHT / 3 };
+
+const struct mode modes[] = {
+{ SWS_FAST_BILINEAR },
+{ SWS_BILINEAR },
+{ SWS_BICUBIC },
+{ SWS_X | SWS_BITEXACT },
+{ SWS_POINT },
+{ SWS_AREA | SWS_ACCURATE_RND },
+{ SWS_BICUBIC | SWS_FULL_CHR_H_INT | SWS_FULL_CHR_H_INP },
+{0}, // test defaults
+};
-static uint64_t getSSD0(int ref, const uint8_t *src1, int stride1,
-int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+static FFSFC64 prng_state;
+static SwsContext *sws[3]; /* reused between tests for efficiency */
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - ref;
-ssd += d * d;
-}
-}
-return ssd;
+static int fmt_comps(enum AVPixelFormat fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+int comps = desc->nb_components >= 3 ? 0b111 : 0b1;
+if (desc->flags & AV_PIX_FMT_FLAG_ALPHA)
+comps |= 0b1000;
+return comps;
}
-struct Results {
-uint64_t ssdY;
-uint64_t ssdU;
-uint64_t ssdV;
-uint64_t ssdA;
-uint32_t crc;
-};
-
-// test by ref -> src -> dst -> out & compare out against ref
-// ref & out are YV12
-static int doTest(const uint8_t * const ref[4], int refStride[4], int w, int h,
- enum AVPixelFormat srcFormat, enum AVPixelFormat dstFormat,
- int srcW, int srcH, int dstW, int dstH, int flags,
- struct Results *r)
+static void get_mse(int mse[4], const AVFrame *a, const AVFrame *b, int comps)
{
-const AVPixFmtDescriptor *desc_yuva420p =
av_pix_fmt_desc_get(AV_PIX_FMT_YUVA420P);
-const AVPixFmtDescriptor *desc_src = av_pix_fmt_desc_get(srcFormat);
-const AVPixFmtDescriptor *desc_dst = av_pix_fmt_desc_get(dstFormat);
-static enum AVPixelFormat cur_srcFormat;
-static int cur_srcW, cur_srcH;
-static const uint8_t *src[4];
-static int srcStride[4];
-uint8_t *dst[4] = { 0 };
-uint8_t *out[4] = { 0 };
-int dstStride[4] = {0};
[FFmpeg-devel] [PATCH v5 09/12] swscale: introduce new, dynamic scaling API
From: Niklas Haas
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the existing one.
Most of the API work has been already accomplished in the previous commits,
this commit merely introduces the ability to use sws_scale_frame()
dynamically, without prior sws_init_context() calls. Instead, the new API
takes frame properties from the frames themselves, and the implementation is
based on the new SwsGraph API, which we simply reinitialize as needed.
This high-level wrapper also recreates the logic that used to live inside
vf_scale for scaling interlaced frames, enabling it to be reused more easily
by end users.
Finally, this function is designed to simply copy refs directly when nothing
needs to be done, substantially improving throughput of the noop fast path.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/swscale.c | 196 --
libswscale/swscale.h | 89 +++
libswscale/swscale_internal.h | 7 +-
libswscale/utils.c| 4 +
libswscale/x86/output.asm | 2 +-
5 files changed, 269 insertions(+), 29 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 45172dcea4..d3dac44d04 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1219,21 +1219,205 @@ int sws_receive_slice(SwsContext *sws, unsigned int
slice_start,
dst, c->frame_dst->linesize, slice_start,
slice_height);
}
+static void get_frame_pointers(const AVFrame *frame, uint8_t *data[4],
+ int linesize[4], int field)
+{
+for (int i = 0; i < 4; i++) {
+data[i] = frame->data[i];
+linesize[i] = frame->linesize[i];
+}
+
+if (!(frame->flags & AV_FRAME_FLAG_INTERLACED)) {
+av_assert1(!field);
+return;
+}
+
+if (field == FIELD_BOTTOM) {
+/* Odd rows, offset by one line */
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+for (int i = 0; i < 4; i++) {
+data[i] += linesize[i];
+if (desc->flags & AV_PIX_FMT_FLAG_PAL)
+break;
+}
+}
+
+/* Take only every second line */
+for (int i = 0; i < 4; i++)
+linesize[i] <<= 1;
+}
+
+/* Subset of av_frame_ref() that only references (video) data buffers */
+static int frame_ref(AVFrame *dst, const AVFrame *src)
+{
+/* ref the buffers */
+for (int i = 0; i < FF_ARRAY_ELEMS(src->buf); i++) {
+if (!src->buf[i])
+continue;
+dst->buf[i] = av_buffer_ref(src->buf[i]);
+if (!dst->buf[i])
+return AVERROR(ENOMEM);
+}
+
+memcpy(dst->data, src->data, sizeof(src->data));
+memcpy(dst->linesize, src->linesize, sizeof(src->linesize));
+return 0;
+}
+
int sws_scale_frame(SwsContext *sws, AVFrame *dst, const AVFrame *src)
{
int ret;
+SwsInternal *c = sws_internal(sws);
+if (!src || !dst)
+return AVERROR(EINVAL);
+
+if (c->frame_src) {
+/* Context has been initialized with explicit values, fall back to
+ * legacy API */
+ret = sws_frame_start(sws, dst, src);
+if (ret < 0)
+return ret;
+
+ret = sws_send_slice(sws, 0, src->height);
+if (ret >= 0)
+ret = sws_receive_slice(sws, 0, dst->height);
-ret = sws_frame_start(sws, dst, src);
+sws_frame_end(sws);
+
+return ret;
+}
+
+ret = sws_frame_setup(sws, dst, src);
if (ret < 0)
return ret;
-ret = sws_send_slice(sws, 0, src->height);
-if (ret >= 0)
-ret = sws_receive_slice(sws, 0, dst->height);
+if (!src->data[0])
+return 0;
-sws_frame_end(sws);
+if (c->graph[FIELD_TOP]->noop &&
+(!c->graph[FIELD_BOTTOM] || c->graph[FIELD_BOTTOM]->noop) &&
+src->buf[0] && !dst->buf[0] && !dst->data[0])
+{
+/* Lightweight refcopy */
+ret = frame_ref(dst, src);
+if (ret < 0)
+return ret;
+} else {
+if (!dst->data[0]) {
+ret = av_frame_get_buffer(dst, 0);
+if (ret < 0)
+return ret;
+}
-return ret;
+for (int field = 0; field < 2; field++) {
+SwsGraph *graph = c->graph[field];
+uint8_t *dst_data[4], *src_data[4];
+int dst_linesize[4], src_linesize[4];
+get_frame_pointers(dst, dst_data, dst_linesize, field);
+get_frame_pointers(src, src_data, src_linesize, field);
+sws_graph_run(graph, dst_data, dst_linesize,
+ (const uint8_t **) src_data, src_linesize);
+if (!graph->dst.interlaced)
+break;
+}
+}
+
+return 0;
+}
+
+s
Re: [FFmpeg-devel] [RFC] What to do with 15k euro from STF?
Hi, Le 11 novembre 2024 01:44:26 GMT+02:00, Michael Niedermayer a écrit : >Hi all > >as we will likely have 15k available from STF "2024" for another task/project >what should it be used for ? > >I think the obvious options are: > >1. gitlab / forgeyo setup + hw + maintaince on our infrastructure >(this was often requested by people in the last years and vittorio > also asked about it again in the STF 2025 thread) + Importing Trac DB into the forge, probably. If Gitlab, Marvin should have then scripts he used for the VLC migration. >2. Maintainancenace of lynnes GPU based FFv1 encoder (if noone else funds it) > >3. a small amount for patchwork maintaince for Andriy Gelman That seems moot if task 1 is taken up. Also IMO, patchwork is a failure, as it is too brittle / too reliant on manual updates. ___ 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] [RFC] dormant git accounts
Hi On Mon, Nov 11, 2024 at 05:00:42PM +, Derek Buitenhuis wrote: > On 11/11/2024 4:42 PM, Michael Niedermayer wrote: > > Publically listing which developer provides which part of the DNS infra > > makes it easier to attack not harder. > > That said, i suspect who provides what was mentioned in the past already > > It is already publically available info to anyone who can look up an IP. Then what is this discussion about? (If all peoples names can be found easily) > > > If an attacker doesnt know who provides a server then the attacker can only > > attack the server directly via its name and IP. > > If an attacker knows who owns the server then he can perform a wide > > range of additional attacks. For example > > Impersonating that developer towards the server hoster, or if the attacker > > can figure out the phone number of the developer then sim swaping becomes > > possible. From that various other accounts can then be taken over and > > Once an attacker is in control of phone and email of someone further > > account compromises become increasingly easy. > > > > I do not think we would be doing FFmpeg a service or improve security > > by listing everyones names in a public file. Even if most of this > > probably was said publically already, having it in one single place > > makes it even easier for an attacker > > This only convinces me further that it this whole setup ins't for for purpose, > and is being run by people who have no concept of actual security. This is > totally insane. So "publically listing every admins and server owner (where its not the company) name" is the normal and sane thing and not listing them publically is totally insane ? Do i understand this correctly? If so, then iam sure that every security related company lists these publically? Likewise the FBI, financial institutions, and so forth. These are organisations where security is very important, but none of them lists server owners and admins publically. And iam not even sure what they would do if you called them and asked, but they probably would ask you for your name, intend and at least internally report this without awnsering your question. But lets go back the original question 1. what exact information do you ask for ? 2. why ? 3. what do you intend to do with this information ? 4. The names of the developers providing the infra have been provided before, did you look through past discussion? 5. Do you ask these questions to every project or just FFmpeg ? (i have been told these questions only happen toward FFmpeg, can you explain why ?) Last years i tried to simply awnser all the questions, but that didnt make anyone happy. I must be missing something. I mean we can go through the whole again if people want but I really think most developers would prefer to work on the code and project instead. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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 2/4] avfilter/f_loop: fix length of aloop leftover buffer
On Tue, 5 Nov 2024, Marton Balint wrote:
On Mon, 4 Nov 2024, James Almer wrote:
On 11/4/2024 5:30 PM, Marton Balint wrote:
If the audio loop stops inside an audio frame, the leftover buffer
contains the
end of the frame, which is not looped. The length supposed to be the
part
which
was not written to the loop buffer, so we need to drain exactly that
number of
bytes from the leftover buffer.
Signed-off-by: Marton Balint
---
libavfilter/f_loop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavfilter/f_loop.c b/libavfilter/f_loop.c
index 9b01a85405..3372c77fee 100644
--- a/libavfilter/f_loop.c
+++ b/libavfilter/f_loop.c
@@ -170,14 +170,13 @@ static int afilter_frame(AVFilterLink *inlink,
AVFrame *frame)
s->pts += av_rescale_q(s->start - s->ignored_samples,
(AVRational){1, outlink->sample_rate},
outlink->time_base);
}
s->nb_samples += ret - drain;
-drain = frame->nb_samples - written;
-if (s->nb_samples == s->size && drain > 0) {
+if (s->nb_samples == s->size && frame->nb_samples >
written)
{
int ret2;
ret2 = av_audio_fifo_write(s->left, (void
**)frame->extended_data, frame->nb_samples);
if (ret2 < 0)
return ret2;
-av_audio_fifo_drain(s->left, drain);
+av_audio_fifo_drain(s->left, written);
}
frame->nb_samples = ret;
s->pts += av_rescale_q(ret, (AVRational){1,
outlink->sample_rate}, outlink->time_base);
Does this fix ticket #11283?
It is not clear which problem the ticket is referring to, this one (which is
a very old issue), or the newer one, which was fixed by the next patch in the
series. To fix the ticket (by every interpretation) you need both fixes.
Will apply patches 2 and 3.
Regards,
Marton
___
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] SIMD Motion Compensation Optimizations
On Monday, November 11th, 2024 at 12:09 PM, compn wrote: > are you trying to say that ffmpeg should take down the tweet? I only provided my observations (with the caveat that I'm still potentially lacking context). What anyone might want to do about it isn't for me to say. If you'd like to check for yourself, try running meson with/without the '-Dbuildtype=debug' option. Note that you'll also need to pass meson the '-Dtrim_dsp=false' option, in order to be able to run the test. Once you've built the tree, which only takes about 30 seconds, you can run the exact commandline shown in the image and see how the relative performance ratios look on your machine. If your CPU lacks AVX-512, you can just compare the performance of C vs SSSE3 and AVX2, which should be more than convincing enough. > well you can come on #ffmpeg-devel irc too, if you dont like twitter. Thank you. I will probably do that, at some point. ___ 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] [RFC] dormant git accounts
Le 11 novembre 2024 18:42:37 GMT+02:00, Michael Niedermayer a écrit : >On Mon, Nov 11, 2024 at 10:02:27AM +, Derek Buitenhuis wrote: >> On 11/10/2024 2:59 PM, Michael Niedermayer wrote: >> > Its there since a long time: >> > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt >> >> [...] >> >> > If something is missing, its not going to improve on its own. >> > Someone will have to say _what_ is missing and work toward filling it in. >> >> Pretty hard to list infra you don't know exists. >> >> For example, I only recently noticed ffmpeg.org goes through avcodec.org DNS: >> >> ns1.avcodec.org - telepoint.bg >> ns2.avcodec.org - KIFU (Government Info Tech Development Agency) >> ns3.avcodec.org - CDLAN SpA >> >> Who owns avcodec.org? Who runs these DNS servers? Who has access? Who has >> contacts? >> >> It's a supply chain attack risk - you could hijack ffmpeg.org per IP or Geo. > >Publically listing which developer provides which part of the DNS infra >makes it easier to attack not harder. That's pretty pathetic excuse, TBH. All it does is make it harder to find whom to contact about whatever issue, and whose stale credentials to purge from what service. It also removes accountability, which is pretty much never a good thing overall. And lastly, if the security of a piece of infrastructure is contingent on not knowing who has access to it, then that's a major problem of its own anyway. ___ 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] [RFC] dormant git accounts
On 11/11/2024 4:42 PM, Michael Niedermayer wrote: > Publically listing which developer provides which part of the DNS infra > makes it easier to attack not harder. > That said, i suspect who provides what was mentioned in the past already It is already publically available info to anyone who can look up an IP. > If an attacker doesnt know who provides a server then the attacker can only > attack the server directly via its name and IP. > If an attacker knows who owns the server then he can perform a wide > range of additional attacks. For example > Impersonating that developer towards the server hoster, or if the attacker > can figure out the phone number of the developer then sim swaping becomes > possible. From that various other accounts can then be taken over and > Once an attacker is in control of phone and email of someone further > account compromises become increasingly easy. > > I do not think we would be doing FFmpeg a service or improve security > by listing everyones names in a public file. Even if most of this > probably was said publically already, having it in one single place > makes it even easier for an attacker This only convinces me further that it this whole setup ins't for for purpose, and is being run by people who have no concept of actual security. This is totally insane. - Derek ___ 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] [RFC] dormant git accounts
On Mon, 11 Nov 2024 18:17:11 + Kieran Kunhya via ffmpeg-devel wrote: > On Mon, Nov 11, 2024 at 5:31 PM compn wrote: > > > > what is your goal? > > > > thanks > > -compn > > Here are some quotes presented without comment: if your goal is to post old quotes, thats cool. one of my goals is to make sure that certain developers, who made their own project and then ran it into the ground, arent made as admins again. they had a good run but couldnt even make an announcement that their project had died. the last one out, did not turn out the lights. that to me is insane. that project was community run, with absolute voting made on every decision. what went wrong there? all i see is Keiran's last mail https://www.mail-archive.com/libav-devel@libav.org/msg85112.html and the community ran github has not been updated to say its status either https://github.com/libav/libav thats why i'm asking you and derek what your goals are. is your goal to turn ffmpeg into a community ran admin with lots of voting? well didnt that other project (that shall not be named) do exactly that? and what happened to them? its gone? gone. dead. how do you keep a community ran project going if there is no paid organization behind it? and who turns out the lights at the end? i think that would be a good goal for derek and the others here to do. figure out how to turn off the old github https://github.com/libav/libav . turn out the lights. greets -compn ___ 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] [RFC] What to do with 15k euro from STF?
On Tue, 12 Nov 2024, martin schitter wrote: The git history of Patches here on this mailinglist are usually rewritten whenever one of the reviewers requests some change, but the typical workflow in github/gitlab doesn't use or even forbids this kind of changes in uploaded code resp. forced pushes. It's enforcing a strict incremental timeline of changes. This is entirely up to the policy of each individual project; it's totally possible to use the exact same workflow with rewriting and force pushing the PR/MR branch, with both github and gitlab. Gitlab is usually a bit better at tracking review state across such events than github though. Anyway, this is how all such reviews are conducted on e.g. the videolan gitlab/projects. // 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] [RFC] What to do with 15k euro from STF?
On 11.11.24 08:11, Diederick C. Niehorster wrote:
I have no personal experience with gitlab, but it:
I'm a long term GitLab user. I use it for most of my work on self-hosted
instances but also on gitlab.com.
In the past it was a really impressive alternative to github, which
provided useful features long before similar tools became available on
github (e.g. the CI/CD capabilities), but I'm not sure, how we should
think today about GitLabs future?
I'm really surprised, that they still exist as an independent company
offering this self-hostable free open core compromise, but the whole
project became very business oriented over time. Their actual backing by
Google investments and infrastructure also doesn't build a really
convincing alternative to the github-microsoft monoculture.
Unfortunately there is simply nothing more acceptable available until now.
('forgejo' could a more lightweight and easier maintainable option for
small private projects, but I wouldn't see it as an equal competitor,
and 'radicle', which is in many ways a rather interesting innovative
decentralized project utilizing a much more sympathetic non-web-tech
base, is still far away from a more user-friendly alternative for the
masses)
1) allows creating merge requests by email:
https://docs.gitlab.com/ee/user/project/merge_requests/
creating_merge_requests.html#by-sending-an-email
That's an interesting point!
If you see this kind of services just as a solution to make Git repos
available in web-browsers and enabling the contribution of "patches" by
another transport mechanism, this could be trough, but the real workflow
significantly differs in both cases.
The git history of Patches here on this mailinglist are usually
rewritten whenever one of the reviewers requests some change, but the
typical workflow in github/gitlab doesn't use or even forbids this kind
of changes in uploaded code resp. forced pushes. It's enforcing a strict
incremental timeline of changes.
That's why contributions and the related communication process looks
very different in both environments in practice.
There are pros and cons for both kinds of workflow and don't want to
advocate one or the other, it's just important to point out this much
more complex side effects and foreseeable consequences of such a
workflow change.
See there are also tools for managing discussion by email.
2) has a CLI tool that can manage merge requests, but cannot be used
for attaching comments to specific code lines:
https://gitlab.com/gitlab-org/cli/-/issues/1311
Yes -- there very efficient cli-tools and plugins for nearly all common
development tools available to support a wide range of habits and user
preferences. But often you'll still have to use the webinterface and
feel the horrible pain of all this typical slow and bloated
web-tech-crap again...
Nevertheless, IMHO it would still be a better solution in comparison to
the status quo!
But this estimation isn't so much caused just by the already mentioned
elementary Git access features, but to other aspects provided by GitLab:
* much better integration of a more useful issue tracker (automatic
cross-links to code and MRs) and therefore much better searchable
growing implicit development documentation (which is IMHO one of the
really unsatisfying aspects of ffmpeg -- because searching old debates
in mailing list archives or in the IRC logs is just unacceptable
frustrating!)
* and CI capabilities -- automatic testing of all incoming merge
requests, which could eliminate lots of noise here on the list by much
more useful machine generated responses resp. quick error reports. This
provides much faster improvement circles and helps to focus the human
communication on more relevant non-trivial topics.
But I also see the danger, that current participation on this list and
the actual review of contributions by many watching eyes will very
likely decrease. That's IMHO a very important problematic aspect,
because I'm really impressed by the review quality here on this list,
although I'm not always sharing the opinions of some maintainers and
their attitude to communicate directives.
I don't know, how I should think about this question of self-hosting vs.
shared usage of an already existing GitLab instance?
Self-hosting GitLab is definitive no rocket science, but it's
nevertheless a responsible challenge, because it's not done with one
installation session, but leading to a rather time-consuming continuous
update and maintenance obligation.
Using an instance of one of the well established free software players
(freedesktop.org, debian, etc.) on their infrastructure, could therefore
also make sense for ffmpeg. This could help focus the available man
power on more useful development tasks.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To uns
Re: [FFmpeg-devel] Patch for libx265 memory leak
Hi Chen,
> On Nov 12, 2024, at 01:09, chen wrote:
>
> From 4067c58be8e719a55d89e68aaa9d3db19b88b32f Mon Sep 17 00:00:00 2001
>
> From: Chen
>
> Date: Fri, 8 Nov 2024 22:21:19 -0800
>
> Subject: [PATCH] Fix memory leak in the libx265
>
>
>
>
> ---
>
> libavcodec/libx265.c | 4 +++-
>
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
>
>
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
>
> index 63cc497..60e84d1 100644
>
> --- a/libavcodec/libx265.c
>
> +++ b/libavcodec/libx265.c
>
> @@ -143,8 +143,10 @@ static av_cold int libx265_encode_close(AVCodecContext
> *avctx)
>
> rd_release(ctx, i);
>
> av_freep(&ctx->rd);
>
>
>
> -if (ctx->encoder)
>
> +if (ctx->encoder) {
>
> +ctx->api->cleanup();
>
> ctx->api->encoder_close(ctx->encoder);
>
> +}
cleanup() release library static allocations, and I don’t see lock or reference
count
within x265_cleanup(). So call cleanup() will break other x265 encoder instance,
right?
>
>
>
> ff_dovi_ctx_unref(&ctx->dovi);
>
>
>
> --
>
> 2.35.1.windows.2
>
>
> <0001-Fix-memory-leak-in-the-libx265.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "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] Patch for libx265 memory leak
On Tue, Nov 12, 2024 at 3:38 AM Zhao Zhili wrote: > > cleanup() release library static allocations, and I don’t see lock or > reference count > within x265_cleanup(). So call cleanup() will break other x265 encoder > instance, > right? x265 already crashes when trying to run two encodes with different settings in the same process, because it's storing some instance specific data in global variables that are overwritten when starting a new encode. So at least with this patch it won't leaks the global data, but the root issue needs to be fixed in x265. ___ 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] remove arpi from MAINTAINERS
haven't seen arpi in a while so remove his root authorized key + remove him from maintainers. maybe he'll come back? anyone know how to contact tim nicholson? his mails are bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963 -compn diff --git a/MAINTAINERS b/MAINTAINERS index 7ac5614c18..8a1883c48c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -50,8 +50,8 @@ Miscellaneous Areas === documentation Stefano Sabatini, Mike Melanson, Timothy Gu, Gyan Doshi -project server day to day operations(L: r...@ffmpeg.org) Ãrpád Gereöffy, Michael Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler -project server emergencies (L: r...@ffmpeg.org) Ãrpád Gereöffy, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler +project server day to day operations(L: r...@ffmpeg.org) Michael Niedermayer, Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler +project server emergencies (L: r...@ffmpeg.org) Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov, Timo Rothenpieler presets [0] metadata subsystem Aurelien Jacobs release management Michael Niedermayer ___ 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".
