Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster wrote: > If i recall correctly, there was a conversation not too long ago about what > to do with all the SPI money. This seems to be a perfect use for it. > 1. Set up and manage a gitlab instance > 2. Move tickets from trac to there (possibly) > 3. Move fate running to there > +1 Another good idea would be to show negative influences the door, and not being afraid to ban them when needed. Currently the CC is supposed to decide that but idk how many and which people have access to the mailing list control panel. -- 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] avcodec/libx264: bump minimum required version to 160
On Thu, Apr 11, 2024 at 6:02 AM Nicolas George wrote: > Michael Niedermayer (12024-04-11): > > Maybe its just me but i find it desireable to be able to just > > pull ffmpeg master head, build it and have it work on as many systems > > as possible. > > While the last time FFmpeg added features… is not that recent since > features are more being removed these days, but still recent enough. > This statement is false. Please stop spreading misinformation. -- 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] Query from Reuters on XZ, open source, and Microsoft
On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer wrote: > Hi > > On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote: > > [Apologies for continuing the conversation, Rémi] > > > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin a écrit : > > > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: > [...] > > > > > Also as someone who had to maintain a Gitlab instance at uni for a > > > couple of years, I agree with Rémi's points > > > > > > > My initial contribution was motivated by the argument presented in the > > original talk that bringing new blood is critical to the survival of the > > project. > > > > If so, then I do believe that there must be a compromise to be made > between > > being easier to join for new developers and changing the existing > workflow. > > I'm also aware that changing the existing workflow has been discussed > > before. > > > > I don't think that media is not cool anymore, as argued in the talk. I > see > > a _lot_ of interested developers in my other projects and all over the > open > > source landscape. That's why I believe that it's also important to > consider > > other reasons than the talk's argument. > > To bring some of the new blood into the project the project needs to > first understand why they dont. And asking thouse who manage with > difficulty > to join could be a biased oppinion. > In my experience this boils down to three points 1. there is a legit barrier of entry in a large codebase such as ffmpeg, but over time newcomers can learn about it 2. the review process can be though and it's easy to miss a ping and patches get lost, very defeating for a new developer 3. there is net negative help from trolls who spread toxic poison, which is confusing and uninteresting for the new blood 2 out of 3 can be solved technically, while the last one needs a cultural shift - overall I think we're doing a good job at slowly changing pace and having a bit of a better structure to solve situations when they arise, but there is still a lot of work to do -- 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] Query from Reuters on XZ, open source, and Microsoft
On Mon, Apr 8, 2024 at 2:14 PM Romain Beauxis wrote: > I would like to offer a constructive feedback really not intended as > trolling. I believe that supporting a more modern development workflow such > as the GitHub PR or gitlab MR would go very long way in helping onboarding > new developers. > Plus one(thousdand). While I don't think using MR or mailing list for patches will immediately convince big tech corps to sponsor ffmpeg, it would definitely help the developer community and make sure we don't lose patchsets. The other open source community that I am involved with, the OCaml > compiler, moved to GitHub maybe 5/6 years ago and this has really done > wonders bringing in new contributors. And, you know, this is a niche > compiler that is also not getting much attention from AI/Machine Learning > people. > Other open source projects are probably less plagued by patents. -- 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] Update the Changelog for 7.0
On Thu, Apr 4, 2024 at 1:28 AM Jean-Baptiste Kempf wrote: > On Wed, 3 Apr 2024, at 23:18, Jean-Baptiste Kempf wrote: > > As attached. > > Updated version attached (v2). > lgtm with AV1 capitalized -- 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] 7.0 Name
Dijkstra time! On Tue, Apr 2, 2024 at 11:22 AM wrote: > My choice would be Dijkstra as well. > > On 2 Apr 2024, at 7:45, AV Preservation by reto.ch (lists) wrote: > > > Sean McGovern wrote: > > > >> Not sure if I am allowed to pick, my choice is Dijkstra. > > > > When I started programming in 1975, Edsger W. Dijkstra was one of my > heroes, which is why I support your proposal, even though I am not an > FFmpeg developer. > > > > Best regards, Reto > > ___ > > 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". > -- 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 14/14] avutil/avstring: Avoid av_strdup(NULL)
On Mon, Mar 25, 2024 at 12:55 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Vittorio Giovara:
> > On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavutil/avstring.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> >> index 2071dd36a5..8702fe0455 100644
> >> --- a/libavutil/avstring.c
> >> +++ b/libavutil/avstring.c
> >> @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path,
> const
> >> char *component)
> >> char *fullpath;
> >>
> >> if (!path)
> >> -return av_strdup(component);
> >> +return component ? av_strdup(component) : NULL;
> >> if (!component)
> >> return av_strdup(path);
> >>
> >
> > isn't this what av_strdup already does?
>
> It's not documented to do so. It could also decide to treat
> av_strdup(NULL) as av_strdup("").
>
Ah fair point, but should we not update its documentation instead?
--
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 14/14] avutil/avstring: Avoid av_strdup(NULL)
On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavutil/avstring.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/avstring.c b/libavutil/avstring.c > index 2071dd36a5..8702fe0455 100644 > --- a/libavutil/avstring.c > +++ b/libavutil/avstring.c > @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path, const > char *component) > char *fullpath; > > if (!path) > -return av_strdup(component); > +return component ? av_strdup(component) : NULL; > if (!component) > return av_strdup(path); > isn't this what av_strdup already does? -- 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 4/4] avcodec/libx265: encode dovi RPUs
On Tue, Mar 19, 2024 at 7:04 PM Niklas Haas wrote: > On Tue, 19 Mar 2024 21:59:53 + Cosmin Stejerean via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > > > > > > > On Mar 19, 2024, at 2:39 PM, Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > > > > > > The reason I never implemented this back when I adde RPU side data is > that > > > there is a strong chance of generating broken files. > > > > > > That's because if we do anything to the video with swscale, etc., we're > > > now encoding RPUs that aren't meant to be applied to that converted > video. > > > > > > For example, this could end up propagating RPUs when the user is > tonemapping. > > > > Would it be possible to only propagate RPUs if the color params are not > changing? If there's any change from say PQ to HLG or HLG to PQ or > tonemapping then we wouldn't want to propagate RPUs. If the color params > are not changing then propagating RPUs by default seems sensible, and > perhaps a filter can be added to explicitly clear RPUs if they should not > be propagated. > > One way to accomplish this would be to simply strip the metadata in all > filters > that can change the colorspace. Maybe we should do the same for HDR+ etc. > metadata. > > Probably it would make sense to add a common helper function for this. > I'll see > what I can do. > In the meantime maybe just adding an encoder option to preserve existing metadata would help? -- 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Tue, Mar 12, 2024 at 5:20 PM Marth64 wrote: > I have not interacted with this user and I am just a mediocre contributor. > But from my experience running forums and IRC networks in the past, > this always ends in one process... > >1. toxic user comes along >2. upsets people repeatedly, which also wastes time >3. admins ponder ban, which wastes time >4. they get banned anyway >5. repeat for the next toxic user that comes along > > imo you have the right to /mode +b toxic_user!*@* > looking at the silver lining, at least people get banned on irc -- 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 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 6:01 PM Kieran Kunhya wrote: > On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote: > > > Kieran Kunhya (12024-03-08): > > > New contributors are not interested in your biased history lessons. > They > > > want to write code and have a modern, well run project, not a > > dysfunctional > > > mess. > > > > And we go back to the core question: does the strength of this project > > come from paid-for contributors maintaining each small parts of the > > project, or does it come from hackers who play with many parts of the > > code and have original ideas to try? > > > > I think the answer is obvious. > > > > Unfortunately, the first category is the majority in number. Which is > > why we should go back on democracy, it was a trap, and re-instate a > > project leader from the second category. Or just consider that the > > ousting of the leader was unlawful. > > > > The world moved on. Open Source projects which are anarchy are few and far > between (basically us). New contributors prefer stability over chaos. > What's worrisome is that old contributors who don't agree with the status quo are free to fork the project and create their own utopia, I don't understand how being in an abusive relationship with this project is any beneficial to OP or the project itself. -- 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 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote: > On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote: > > > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern > wrote: > > > > > > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > > > > > > > Andreas Rheinhardt (12024-03-08): > > > > > > What maintenance cost and complexity are you referring to? I > > checked > > > > and > > > > > > could not find a single commit where one had to fix an > > > ff_get_buffer() > > > > > > to ff_thread_get_buffer() because it has been forgotten when the > > > > decoder > > > > > > has been declared to support frame threading. > > > > > > > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. > catering > > > for > > > > > hypothetical mediocre contributors, is more important than easy > > > > > optimizations and new approaches. > > > > > > > > > > And if you do not like it, “shut up, I'm on the TC and I won't > > recuse”. > > > > > > > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > > > > > > > Regards, > > > > > > > > > > -- > > > > > 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". > > > > > > > > > > > > > Everybody can we *please* keep the responses civil/professional on > the > > > ML. > > > > > > > > > > I'd just be happy with "on-topic" but it seems like people with agendas > > > like to project on unrelated threads. > > > > > > > LibAV actions speak more than words once again. > > > > > > > -- > > > 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". > > > > > ___ > > 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". > > > > It is really mean-spirited to make such comments about a project that is no > longer in operation. Can't we look forward instead of behind us? > Could you guys look forward in a separate thread? -- 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 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote: > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote: > > > Andreas Rheinhardt (12024-03-08): > > > What maintenance cost and complexity are you referring to? I checked > and > > > could not find a single commit where one had to fix an ff_get_buffer() > > > to ff_thread_get_buffer() because it has been forgotten when the > decoder > > > has been declared to support frame threading. > > > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering for > > hypothetical mediocre contributors, is more important than easy > > optimizations and new approaches. > > > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”. > > > > And if you do not like that, “shut up, I'm on the CC too”. > > > > Regards, > > > > -- > > 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". > > > > Everybody can we *please* keep the responses civil/professional on the ML. > I'd just be happy with "on-topic" but it seems like people with agendas like to project on unrelated threads. -- 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 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
On Fri, Mar 8, 2024 at 12:18 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > >> > >> -1: This adds avoidable runtime checks. > > > > What checks and why is that a problem? > > > It adds a runtime check to every call to ff_get_buffer() by every > decoder not supporting frame-threading (by checking whether > frame-threading is currently in use). > >>> > >>> I cannot imagine any situation where it could have a measurable impact. > >>> > >> > >> And? It is avoidable, therefore it should be avoided. > > > > Why should it be avoided when it can never have any measurable impact? > > > > The maintenance cost of a more complex API is higher than the > > infinitesimal cost of this check. > > > > What maintenance cost and complexity are you referring to? I checked and > could not find a single commit where one had to fix an ff_get_buffer() > to ff_thread_get_buffer() because it has been forgotten when the decoder > has been declared to support frame threading. > I'd wager documentation and developer complexity costs, usually a simpler API is a nice thing to have. Especially in this case, if the runtime check is minimal it doesn't make sense to keep two different APIs that do the same thing. -- 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] [RFC] clarifying the TC conflict of interest rule
On Thu, Mar 7, 2024 at 12:25 AM Michael Niedermayer via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > instead of backroom deals, for a > > change. > > iam sorry, but these accusations are not acceptable > The application was and is on a public wiki > the SoWs where collected by pierre and it was publically announced before. > I tried to contact all people before the deadline who had incomplete > submissions. > I think the backroom deals is referring to the months of silence between *some people* knowing and the community being informed, plus the rushed 2 weeks voting time > I think for a change you should say thanks to tara, pierre, SPI, STF and > others > doing all the work. Instead of accusations. > I don't see anybody thanking Anton for the work trying to solve the contentious point on the rules If anything he keeps being disparaged by conspiracy theorists, and getting the discussion derailed > And you should submit a proposal with SoW and all needed information > next time. Similarly others should too. The idea of this was never to have > just 2 people submit SoWs > > > > > > The application has apparently been submitted, with no public > > announcement that it even happened, much less what was in it. > > whats in it, should simlpy be what was on the wiki application > plus the fixes and cleanups mentioned above > Can you guys open a separate thread for these points? They have nothing to do with the case at hand. -- 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] [RFC] clarifying the TC conflict of interest rule
On Tue, Mar 5, 2024 at 3:50 AM Michael Niedermayer wrote: > On Mon, Mar 04, 2024 at 10:45:02AM +0100, Vittorio Giovara wrote: > > On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote: > > > [...] > > > > > > > +If a TC member is aware of a conflict of interest with regards to > the > > > case, they must announce it > > > > +and recuse themselves from the TC discussion and vote. > > > > > > please replace this in my proposal by this (as it clearer states what > the > > > intend is) > > > > > > > * If a TC member is aware of being in a conflict of interest with > > > regards to the case, they must announce it > > > > and recuse themselves from the TC discussion and vote. > > > > > > (also as you can see we have active discussions here, the vote is IMHO > > > premature) > > > > > > > we literally had premature voting for STF, despite multiple discussions > > taking place during the time > > The STF opertunity had a deadline. > a deadline that you were aware of for months, and dumped on the community saying "we only have 2 weeks to decide" and *while we were discussing the options* you single handedly started a vote > Also we can already start discussing what shall be done when the next grant > opertunity comes. I dont know if we will be accepted, so its possible > 1. that if we are rejected that we will hear of that narrowly before the > next deadline. > 2. there is always the chance for more opertunities, we should be ready > to know what we want next time > We are NOT discussing this topic in this thread, please stop trying to derail the conversation > > I don't see how a parallel thread here should stop the proposed vote now > > please let's stop filibustering and just move on to voting > > voting on what ? > On the list of options that Anton is preparing > Iam not blocking the vote btw, i suggested several options for it. > What i think is that a real discussion would make sense before the vote > if no such discussion happens and the vote moves forward with all options > then that will work out too i guess. > Including expanding the GA, sending separate patches, and now mentioning funding in this very response I love the chaos as much as anybody but we need to be practical at a certain point. Either add an option to the proposed list of options or let's move to voting. -- 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] [RFC] clarifying the TC conflict of interest rule
On Mon, Mar 4, 2024 at 1:57 AM Michael Niedermayer wrote: > On Sun, Mar 03, 2024 at 03:49:33AM +0100, Michael Niedermayer wrote: > [...] > > > +If a TC member is aware of a conflict of interest with regards to the > case, they must announce it > > +and recuse themselves from the TC discussion and vote. > > please replace this in my proposal by this (as it clearer states what the > intend is) > > > * If a TC member is aware of being in a conflict of interest with > regards to the case, they must announce it > > and recuse themselves from the TC discussion and vote. > > (also as you can see we have active discussions here, the vote is IMHO > premature) > we literally had premature voting for STF, despite multiple discussions taking place during the time I don't see how a parallel thread here should stop the proposed vote now please let's stop filibustering and just move on to voting -- 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 2/3] doc/community: Conflict of interest recusal requirement (Similar to mid part of Antons proposal)
On Mon, Mar 4, 2024 at 1:46 AM Michael Niedermayer wrote: > > Again, the effective way to work-around this problem is to keep a large > and > > diverse enough TC membership to offset the one or few hypothetical > dishonest > > votes. > > This doesnt work. The set of people is very specific, and they will always > be > representatives of the community so when 60% of the community works for > companies which would benefit by FFmpeg not competing. There > would be no realistic way to have a committee that wasnt also 60% affected > by this. And for this we need a clear rule. > This scenario is, also, not realistic. -- 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 2/2] avcodec: remove sonic lossy/lossless audio
On Fri, Mar 1, 2024 at 10:34 PM Lynne wrote: > >> If it's the last case, or simply being a one-off, I can agree with > deprecating > >> and remove it next bump. But if the developer thinks they will have > time and > >> have motivation to work on it in the future, I think we should leave it > at just > >> deprecation plus disabling building the encoder by default, until the > issue is > >> brought up again at say, after the next version bump. > >> After all, CELT started out more than 10 years before Opus was > standardized, > >> and its EC code has made it all the way to AV2 despite its core > remaining > >> visibly similar over the years. And FFv1 was used as an inspiration for > FLIC, > >> which went on to become JPEG-XL. > >> > > > > Sure, but there was active interest in all of these. I see no active > > interest in Sonic. > > > > No one had any interest in CELT for years until it was used in Mumble, > or Speex initially, or FLIC, as it they were not competitive enough on its > own, > and Vorbis, or Opus for the first few years. > There is nothing stopping developers to work on their own fork and release the codec when ready, or at least there is moderate interest The developer has said there's interest in continuing to work on it > in the future. > The developer expressed interest in literally everything in ffmpeg, there needs to be a threshold in what is reasonably expected to be worked on in a lifetime. I don't see why we shouldn't give him a chance to work on it for > a bit longer before we bring it up again for removal. > Because people had 10 years to work on it a bit longer and they didn't. Claiming interest only because there is an active removal process is not very healthy for the codebase (or the community). -- 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 2/2] avcodec: remove sonic lossy/lossless audio
On Thu, Feb 29, 2024 at 2:31 PM Lynne wrote: > Feb 29, 2024, 02:50 by vittorio.giov...@gmail.com: > > > On Wed, Feb 28, 2024 at 11:13 PM Lynne wrote: > > > >> Feb 28, 2024, 14:29 by mich...@niedermayer.cc: > >> > >> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >> > > >> >> This was an experimental/research codec of which ffmpeg is the only > >> >> encoder and decoder, > >> >> > >> > > >> > > >> >> development has stalled > >> >> > >> > > >> > Thats not true, there was private dicussion making sonic the most > >> > advanced audio codec in FFmpeg a few months ago. > >> > Iam not saying that will happen, i am just saying there was a > >> > discussion about it. And that iam in principle interrested in > >> > working on this. Its possible i will not have enough time ... > >> > > >> > >> I would strongly prefer for it to be kept around as well. > >> > >> Otherwise it creates precedence to throw out codecs if they're > >> not popular enough, and we're known for being able to play > >> most formats ever created. > >> > > > > IMO there is a big difference between a game codec and an experimental > > codec that hasn't come out of ffmpeg > > > > We offer support for it. Someone must have used it. > I'm sure there are less used game codecs we support than Sonic. > the point here is that game codecs are part of digital preservation and and effort against digital obsolescence an "experimental codec" that nobody (read: a very limited amount of users) used except ffmpeg devs as playground does not warrant it being in the codebase (but rather a branch or personal fork) IMO -- 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 2/2] avcodec: remove sonic lossy/lossless audio
On Wed, Feb 28, 2024 at 11:13 PM Lynne wrote: > Feb 28, 2024, 14:29 by mich...@niedermayer.cc: > > > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > > > >> This was an experimental/research codec of which ffmpeg is the only > >> encoder and decoder, > >> > > > > > >> development has stalled > >> > > > > Thats not true, there was private dicussion making sonic the most > > advanced audio codec in FFmpeg a few months ago. > > Iam not saying that will happen, i am just saying there was a > > discussion about it. And that iam in principle interrested in > > working on this. Its possible i will not have enough time ... > > > > I would strongly prefer for it to be kept around as well. > > Otherwise it creates precedence to throw out codecs if they're > not popular enough, and we're known for being able to play > most formats ever created. > IMO there is a big difference between a game codec and an experimental codec that hasn't come out of ffmpeg -- 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 1/2] MAINTAINERS: remove inactive developer
On Wed, Feb 28, 2024 at 1:56 PM J. Dekker wrote: > Inactive since 2007. > > Signed-off-by: J. Dekker > --- > MAINTAINERS | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > lgtm -- 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 2/2] avcodec: remove sonic lossy/lossless audio
On Wed, Feb 28, 2024 at 2:38 PM J. Dekker wrote: > > Michael Niedermayer writes: > > > [[PGP Signed Part:Undecided]] > > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >> This was an experimental/research codec of which ffmpeg is the only > >> encoder and decoder, > > > > > >> development has stalled > > > > Thats not true, there was private dicussion making sonic the most > > advanced audio codec in FFmpeg a few months ago. > > Iam not saying that will happen, i am just saying there was a > > discussion about it. And that iam in principle interrested in > > working on this. Its possible i will not have enough time ... > > > > The last commit which actually changed the codec was > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > years ago. For an experimental codec I think it's pretty safe to say > that development has stalled. > > Keeping the codec around based on 'what if?'s doesn't seem > reasonable. Besides, if you do make sonic the most advanced audio codec > in FFmpeg there's nothing which says you couldn't re-add it at a later > date when it's being actively developed again. > +1 but please do the deprecation dance as suggested -- 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] [RFC] fate rsync switch to git
On Wed, Feb 21, 2024 at 3:50 PM wrote:
>
>
> On 21 Feb 2024, at 15:38, Niklas Haas wrote:
>
> > On Tue, 20 Feb 2024 20:43:30 +0200 Jan Ekström wrote:
> >> Do note that the idea was that this would only be for management of
> >> the main archive, so it would not affect clients/runners rsync'ing
> >> from the main archive.
> >>
> >> Of course clients which want to sync directly from git could do that,
> >> but the idea would be to keep the sync requirements same for FATE
> >> clients/runners: if you are only running tests, rsync is enough.
> >>
> >> As after all, the primary reasons for having the samples in git would
> >> be versioning, more concrete known states in a public archive (I would
> >> probably not call this a "backup", but it would mean we would have the
> >> history in multiple places at least), as well as - if we utilize
> >> something like git{lab,hub} - easier workflow to adding new samples by
> >> means of f.ex. merge/pull requests.
> >>
> >> This idea originated from looking at how the dav1d project handled
> >> their reference sample suite, which seems to have served them well
> >> enough: https://code.videolan.org/videolan/dav1d-test-data
> >>
> >> Regards,
> >> Jan
> >
> > Is there any reason (besides efficiency hit) not to make the FATE repo
> > a `git submodule` of the FFmpeg git repo? That way, commits which depend
> > on certain additions to fate-samples can explicitly depend on the
> > commits adding those files, developers can more easily see (e.g. via
> > `git status`) if the fate samples are out-of-date (or use `git pull
> > --recurse-submodules` to automate the process).
>
> I am all for having it in git but do not like the idea of a git submodule
> at all as they are a nightmare to work with, sometimes create absolutely
> unworkable conflicts when rebasing and other oddities…
>
> (We use submodules for the Icecast project, it was my idea back then and
> I regret it…)
>
> >
> > It will also make the samples repo historically consistent, e.g. if
> > somebody changes a detail about a file in a later commit, older commits
> > referencing the unmodified version will continue passing FATE tests. I'm
> > not sure if this has ever been a concern in the past, but it may well
> > be one in the future.
> >
> > Worrying about the performance impact of rsync vs git-lfs (or equivalent
> > solutions) seems like premature optimization to me; and the ease of
> > maintenance, historical consistency, transparency in process, and
> > end-user convenience of a git repository seems to far outweigh the
> > drawbacks.
I don't mind submodules but I understand the complications. Maybe we could
design a system in which samples have attached a hash/branch/ref so that
when checking out older/outdated samples the correct sample itself can
still be used.
But overall I agree it would be much preferable to have the management
system in git over rsync.
--
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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 4:40 PM Gyan Doshi wrote: > > > On 2024-02-19 08:00 pm, Vittorio Giovara wrote: > > On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote: > > > >> The TC is invoked when there's an intractable dispute. So the dispute > >> precedes the TC activity hence the parties to the dispute are the main > >> opposing participants at the venue of the dispute wherever that is, and > >> the rules applies to all main parties. Imagine there's a new feature to > >> be added which doesn't exist in the codebase in any form so there's no > >> status quo. Member A submits a patch using design pattern X. Member B > >> objects and wants design pattern Y. Now let's say if only A was on the > >> TC, then as per the arguments of some here, A should recuse themselves > >> but if only B was on the TC, B gets to vote. That asymmetry is not > >> supported in the wording nor would it be fair. > >> > > The asymmetry is that the TC should be protecting the good of the project > > and the community interests, while the member of the community proposing > > the patch is protecting their own interest. > > Both the proposer and disputer of a patch may have a vested interest in > steering decisions one way or the > other, or both may believe they're furthering the good of the project. > There is no asymmetry inherent in the > roles of the participants. There shouldn't be in the rules either. > As a matter of fact there is no asymmetry rule: if the author of the patch is a member of TC and there is a disagreement, then they shall not vote. Applies equally, to all members of the TC, of course it does not apply if a TC member is involved in a technical discussion outside of the TC discussion itself. It wouldn't make sense otherwise! > > The rule you keep bringing forth is stated to avoid a conflict of > > interest where the member of the TC is also the author of the patch, but > > was never meant to exclude one party from voting in the TC. > We've already had the proposer of the rule participate in this thread > and I cited discussion from the time of drafting of the rule that it is > meant to apply to both sides. Treating the rule as applying to only the > author is the aberrant interpretation. Regards, Gyan > While you may find my interpretation of the rule "aberrant" for the local case, I find yours abhorrent for the health of the project itself. I understand your frustration about this situation (and I am sure some people are enjoying the show) but I am starting to suspect bad faith here, and I invite you to reconsider your views on the matter. -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 3:28 PM Nicolas George wrote: > Vittorio Giovara (12024-02-19): > > By that reasoning, someone could argue that you forced the inclusion of > > this rule being discussed only to set up a backdoor in the process and > > thwart any chance of a functioning process for the community > > Can you explain the part of your reasoning where you establish that I > “forced” anything? > > Otherwise, you are just being libelous. > Not my intention, allow me to rephrase: > By that reasoning, it could be argued that someone proposed the inclusion of > this rule being discussed only to set up a backdoor in the process and > thwart any chance of a functioning process for the community As mentioned, it's just a hyperbole, extending the deviance of this thought logic. -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 3:30 PM Nicolas George wrote: > Vittorio Giovara (12024-02-19): > > I understand your concerns regarding the potential consequences of > changing > > this rule, and I acknowledge the importance of upholding the principles > > that underpin our project's governance. However, I must express my > > disappointment in the insinuation that I am acting in bad faith. > > There is no insinuation in the mail you are answering to. > There are many in the section snipped below the original email. -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi wrote: > > > On 2024-02-19 03:16 am, Vittorio Giovara wrote: > > On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote: > > > >> > >> On 2024-02-18 11:33 pm, Anton Khirnov wrote: > >>> Quoting Gyan Doshi (2024-02-18 05:06:30) > >>>> b) what "maximalist" interpretation? > >>> A non-maximalist interpretation would be that a TC member is only > >>> excluded from voting when they authored the patch that is being > >>> disputed. > >> If the promulgators meant to only prevent proposers of the disputed > >> change to not take part, then > >> the verbiage would be different. > >> > >> In looking up how this clause came to be present, I came across the > >> following messages: > >> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273443.html > >> (Nicolas George originally proposes this clause - wording is more > >> restrictive) > >> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274822.html > >> (this one is interesting, you objected to the clause but on the grounds > >> that it was all-encompassing i.e. anyone commenting on the dispute was > >> potentially subjected to recusal and referred to some 'model' > >> discussion, so your describing my reading as maximalist is weird since > >> that is how you read it - you just happen to object to this rule) > >> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274826.html > >> (Ronald clarifies that "involved" should be constrained to just be one > >> of the two parties -- of which you happen to be one) > >> > >> There's the matter of what the rule currently is, distinct from what it > >> should be. What it ideally should be is that the decision should be > >> taken by a fresh set of eyes consisting of those who haven't become or > >> are seen to be publicly invested in the outcome. So the TC should have a > >> set of alternates - those who can make up the quorum and constitute an > >> odd number of voters when some from the first 5 are recused. > >> > > I'd like to offer a lighter interpretation of the rule, the mailing list > is > > the common playing ground, where discussions and disagreements can be > had. > > In case of a technical "maximalist" disagreement, then either party can > > invoke the TC to judge on the matter. If anyone in the TC is involved in > > the patch, as if it's an author or significantly contributed to it, then > > they should step away from voting. In other words the "level of > > involvement" rule takes place at the TC level, not at the ffmpeg-devel > > discussion. > > The TC is invoked when there's an intractable dispute. So the dispute > precedes the TC activity hence the parties to the dispute are the main > opposing participants at the venue of the dispute wherever that is, and > the rules applies to all main parties. Imagine there's a new feature to > be added which doesn't exist in the codebase in any form so there's no > status quo. Member A submits a patch using design pattern X. Member B > objects and wants design pattern Y. Now let's say if only A was on the > TC, then as per the arguments of some here, A should recuse themselves > but if only B was on the TC, B gets to vote. That asymmetry is not > supported in the wording nor would it be fair. > The asymmetry is that the TC should be protecting the good of the project and the community interests, while the member of the community proposing the patch is protecting their own interest. For the better or the worse of course. The rule you keep bringing forth is stated to avoid a conflict of interest where the member of the TC is also the author of the patch, but was never meant to exclude one party from voting in the TC. > Also consider that even in a vote recusal, the member's > > arguments will still be read and by all likelihood taken into > consideration > > by the TC, so yours seems to be a literal interpretation of the rule, > > instead of the spirit of the rule, which in my opinion matters more. > > Of course. There's no mind-reading or mind-control machine here. Humans > aren't automatons either. The judges on any Supreme Court are older > human beings with all the deep convictions that one acquires during a > long lifetime but that's the best we can do. The rules are meant to be > the most that is practically feasible within mutually observable > reality, not ideally efficient within an omniscient universe. > If you believe the interpretation of the rule is dubious or incorrect, you should propose a formal vote to change or clarify its wording. -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 9:54 AM Nicolas George wrote: > Vittorio Giovara (12024-02-18): > > While I understand that you're referencing the existing rules that we've > > collectively agreed upon, I believe it's crucial for us to periodically > > review and refine these rules to ensure they remain aligned with our > > evolving community values and goals. > > > > This is true, but you neglect two very important facts: > > First, the rule we are discussing is a direct consequence of the more > general rule that nobody is above anybody in the project. A change to > this rule is a very deep change and must be discussed knowing the > consequences. > > Second, the current committee has been elected based on the current > rules. If the rule get changed, then the election must be redone. And > you can count on me for emphasizing that somebody who did not want to > adhere to the current rules is unfit to be elected even under the new > ones. > I understand your concerns regarding the potential consequences of changing this rule, and I acknowledge the importance of upholding the principles that underpin our project's governance. However, I must express my disappointment in the insinuation that I am acting in bad faith. It is essential to approach discussions with mutual respect and trust, assuming positive intent from all parties involved. Implying bad faith undermines the spirit of constructive dialogue and collaboration that is crucial for the progress of our community. I must address the concerning implication of bad faith in your response. Accusations of acting in bad faith are detrimental to our collaborative efforts and undermine the mutual respect necessary for productive discourse within our community. It is imperative that we engage in discussions with goodwill and a presumption of positive intent from all parties involved. Such insinuations hinder our ability to work together effectively and erode the trust essential for maintaining a healthy community environment. While I value your dedication to upholding the integrity of our project's rules, I urge us to refrain from casting doubt on each other's motivations. Let us refocus our efforts on constructive dialogue aimed at finding solutions that serve the best interests of the FFmpeg project. Thank you for your understanding, and I remain committed to fostering a culture of respect and collaboration within our community. -- Vittorai ___ 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 9:45 AM Nicolas George wrote: > Vittorio Giovara (12024-02-18): > > If it helps, I'll block the patch so that Anton can vote in the TC. > > Do you see how slippery (and insane) this interpretation of the rule > > becomes? > > The rules are written assuming people in the project are working in good > faith for the benefit of the project. > > Proposing that kind of cheat to work-around the rules is the opposite of > acting in good faith, it is acting like a corrupt politician. And that > should disqualify anybody of participating in the governance of the > project. > By that reasoning, someone could argue that you forced the inclusion of this rule being discussed only to set up a backdoor in the process and thwart any chance of a functioning process for the community Of course we're talking by hypotheticals, right? -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Mon, Feb 19, 2024 at 2:17 AM Michael Niedermayer wrote: > On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote: > > On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer > > wrote: > > > > > > * A disagreement implies that there are 2 parties > > > * And we assume here that what one party wants is better for FFmpeg > than what the other wants. > > > * The TC needs to find out which partys choice is better or suggest a > 3rd choice. > > > * If one but not the other party is a member of the TC then this > decission becomes biased if that member votes > > > > > > Your interpretation suggests that the TC members are "above" everyone > and should > > > prevail in arguments they have with others. > > > > > > > Noone is above the rules, but just because someone has an opinion and > > shared it shouldn't disqualify them, because they were specifically > > voted into the TC for their opinions on technical matters. > > Would their opinion, and therefore their vote, change if someone else > > was seen as the person "blocking"? > > I think you are mixing the concept of an oppinion and blocking a patch. > following is how i see the concept > > If you state that you prefer a linked list but dont mind the patch as it is > thats an oppinion > > If you state that you prefer a linked list and i tell you that i would > prefer to keep an array and you say you are ok, again thats an oppinion > the patch is not blocked > > If you state that you prefer a linked list and i tell you that i would > prefer to keep an array and you now tell me that if i want an array i have > to go to the TC then you are blocking the patch. You and me in this case > are the cause of the TC being involved. > Only at this point we would be parties to the disagreement IMHO > and we cannot be the judge here > > > > > > What if multiple people had expressed disagreement with a patch, and > > most of the TC was involved in the public discussion already? Do the > > The question would be who is actually blocking it and not just stating > their oppinion. > > > > remaining "uninvolved" people on the TC get all the decision power? Or > > do we consider most of the TC already opposing it publicly as perhaps > > an indicator that the patch might not be the way to go? > > Thats what the TC was voted in for, to give their opinion on technical > > matters and decide if needed, so why deprive them of their opinion, > > just because they already stated it publicly? That makes no sense to > > me. > > You certainly have a point but, again I think there are big differences > between a TC oppinion and someone blocking a patch > > If a TC member states an oppinion and clearly explains the reasoning > behind it > that should have no impact on the TC members ability to vote. In fact it > should > lead to all parties discussing and resolving the conflict probably without > the > need to formally involve the TC > > IMHO, invoking the TC is already an exceptional situation and failure. > and it shouldnt give the parties of that failure more influence in the > decission. > (which is another orthogonal reason why the parties of a conflict should > not > be judges of the conflict) > > Its really strange. > > You know, if a judge files a lawsuit, that judge cannot be the judge in > that lawsuit. > This is a very simple concept. > It seems some people here see "their friend" not being allowed to vote > but thats not what this is about. > If a TC member blocks a patch, that TC member cannot vote on how to resolve > that blockage. > > If a TC member chooses not to block a patch so he retains the power in a > potential future vote. Thats a game theoretic decission he makes to > maximize > his blocking power. But really if he doesnt block it it could be applied > so this is not a logic decission. The logic decission is to block the patch > if thats what he wants and if noone else is blocking it. > game theoretically the example you provide above would never happen > as there would never be more than 1 TC member blocking a patch. > > So IMO arguing that a person should be party to a disagreement and judge of > it. But making this dependant on an argument where people have to act in an > illogic way is really odd > i long for the day in which ffmpeg might actually seem like a functioning community, where we would not constantly and needlessly bikeshed rules and other politics,but that day is clearly not today -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer wrote: > Hi > > On Sun, Feb 18, 2024 at 07:20:43PM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-02-18 01:43:14) > > > "If the disagreement involves a member of the TC" > > > does IMHO not preclude commenting on a patch. > > > > > > For a disagreement we need 2 parties. For example one party who > > > wants a patch in and one who blocks the patch. or 2 parties where both > > > block the other. > > > > > > Being a party of a disagreement would not make anyones opinon invalid. > > > > Anything that goes to TC is a disagreement. > > probably, thats true, yes > > > > Anyone who expressed an > > opinion on the patch then is 'a party to the disagreement'. > > no, i dont see it that way > A developer blocking a patch is a party to the disagreement > So is the developer who calls the TC because of that. > Disagree. If that basically means that no patches will be ever blocked by the members of the TC! They should express the best technical excellence of the whole community, not be stifled from participating in the discussion If it helps, I'll block the patch so that Anton can vote in the TC. Do you see how slippery (and insane) this interpretation of the rule becomes? > Similarly if you look at real world court cases > parties to the lawsuit are the one who is filling the lawsuit and > the defendant. > The thousand people expressing an oppinion in some random place are > not parties to the disagreement > This is a false dichotomy, we're not a court case where we're interpreting the law, we're trying to solve a technical disagreement. > More formally, you could define a "party to a disagreement" as > all minimal sets of people whos non existence would resolve the > disagreement > By that reasoning you shouldn't vote either since you touched basically all of ffmpeg codebase! > * A disagreement implies that there are 2 parties > * And we assume here that what one party wants is better for FFmpeg than > what the other wants. > * The TC needs to find out which partys choice is better or suggest a 3rd > choice. > * If one but not the other party is a member of the TC then this decission > becomes biased if that member votes > > Your interpretation suggests that the TC members are "above" everyone and > should > prevail in arguments they have with others. > Nobody is saying that!!! > I dont think the GA has given that power to the TC. > Are you suggesting to have a vote to rewrite/reinterpret the rule? -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 10:25 PM Nicolas George wrote: > Vittorio Giovara (12024-02-18): > > While I value your insights, I'd like to offer a different > > viewpoint regarding the practice of recusing oneself from discussions. > > > > That might be your viewpoint, but that is not what the rules we all > agreed upon say. > Thank you for your prompt response, Nicolas. I appreciate the opportunity to delve deeper into our governance rules and their interpretation within the FFmpeg community. While I understand that you're referencing the existing rules that we've collectively agreed upon, I believe it's crucial for us to periodically review and refine these rules to ensure they remain aligned with our evolving community values and goals. The rules we've agreed upon serve as a foundation for our governance structure, providing guidelines for decision-making and ensuring fairness and transparency in our processes. However, as our community grows and evolves, it's natural for interpretations and perspectives to shift, necessitating occasional reassessment of these rules. Your reminder about the importance of adhering to the established rules is valid, and I share your commitment to upholding them. However, I also believe that our rules should be flexible enough to accommodate diverse viewpoints and adapt to changing circumstances. Therefore, I propose that we engage in a collaborative effort to revisit and clarify our existing rules. By fostering open dialogue and soliciting input from all members of the community, we can ensure that our governance framework reflects the collective wisdom and values of our community. Furthermore, this process of review and refinement will help address any ambiguities or discrepancies in our rules, promoting greater clarity and understanding among all stakeholders. It will also provide an opportunity to incorporate new insights and best practices that may have emerged since the rules were initially established. In conclusion, I appreciate your reminder about the importance of adhering to our agreed-upon rules. However, I believe that revisiting and clarifying these rules is a proactive step toward strengthening our governance processes and ensuring the continued success and sustainability of the FFmpeg project. Thank you for your dedication to the community, and I look forward to engaging in productive discussions to enhance our governance framework. -- Vittorai ___ 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 1/2] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi wrote: > > > On 2024-02-18 11:33 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2024-02-18 05:06:30) > >> b) what "maximalist" interpretation? > > A non-maximalist interpretation would be that a TC member is only > > excluded from voting when they authored the patch that is being > > disputed. > > If the promulgators meant to only prevent proposers of the disputed > change to not take part, then > the verbiage would be different. > > In looking up how this clause came to be present, I came across the > following messages: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273443.html > (Nicolas George originally proposes this clause - wording is more > restrictive) > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274822.html > (this one is interesting, you objected to the clause but on the grounds > that it was all-encompassing i.e. anyone commenting on the dispute was > potentially subjected to recusal and referred to some 'model' > discussion, so your describing my reading as maximalist is weird since > that is how you read it - you just happen to object to this rule) > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274826.html > (Ronald clarifies that "involved" should be constrained to just be one > of the two parties -- of which you happen to be one) > > There's the matter of what the rule currently is, distinct from what it > should be. What it ideally should be is that the decision should be > taken by a fresh set of eyes consisting of those who haven't become or > are seen to be publicly invested in the outcome. So the TC should have a > set of alternates - those who can make up the quorum and constitute an > odd number of voters when some from the first 5 are recused. > I'd like to offer a lighter interpretation of the rule, the mailing list is the common playing ground, where discussions and disagreements can be had. In case of a technical "maximalist" disagreement, then either party can invoke the TC to judge on the matter. If anyone in the TC is involved in the patch, as if it's an author or significantly contributed to it, then they should step away from voting. In other words the "level of involvement" rule takes place at the TC level, not at the ffmpeg-devel discussion. Also consider that even in a vote recusal, the member's arguments will still be read and by all likelihood taken into consideration by the TC, so yours seems to be a literal interpretation of the rule, instead of the spirit of the rule, which in my opinion matters more. -- 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 1/2] avcodec/s302m: enable non-PCM decoding
On Sun, Feb 18, 2024 at 7:40 PM Nicolas George wrote: > Anton Khirnov (12024-02-18): > > That is absurd and makes no sense. > > That makes absolute sense, unless you consider your opinion is worth > more than the opinion of the other people in the project. > > A spot on the TC is not a license to consider one's opinion above the > other's, and therefore comes with a trade-off, and it is exactly that. > > There are other members of the TC who did not take part in the > discussion: recusing yourself is not an issue. > > Sitting on the TC is a duty, a responsibility to examine in details > changes one do not care about to make an informed decision. Somebody who > sees it as a means to power rather than a responsibility should be > evicted as soon as possible. > Thank you for your perspective on TC responsibilities within the FFmpeg project. While I value your insights, I'd like to offer a different viewpoint regarding the practice of recusing oneself from discussions. It's essential to recognize that each TC member holds a duty to actively participate in discussions and decision-making processes. Recusing oneself from discussions should be a rare occurrence reserved for situations where a clear conflict of interest exists, rather than a default response to certain topics. Serving on the TC requires a commitment to thoroughly examine proposed changes and contribute to informed decision-making. It's through active engagement and thoughtful consideration of all viewpoints that we can ensure the best outcomes for the project. While I understand the importance of avoiding conflicts of interest, it's equally vital for TC members to fulfill their responsibility to the project by actively engaging in discussions and providing valuable insights. In conclusion, let's uphold the principle of active participation and responsibility in TC discussions to maintain the integrity and effectiveness of our governance processes within the FFmpeg project. -- Vittorai ___ 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/jpeg2000dec: support of 2 fields in 1 AVPacket
On Thu, Feb 15, 2024 at 4:02 PM Jerome Martinez wrote: > In other words, I would like to know if AVFrame is intended at long term > to handle also fields in addition to frames, and if so is there a way to > signal that the AVFrame structure actually contains a field > I may be missing something from the previous discussion, but the AV_FRAME_FLAG_INTERLACED should indicate when that is the case. I am not familiar enough with j2k code to know if that flag is correctly set or not. -- 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 0/2] Remove SDL2 output devices
On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote: > Anton Khirnov (12024-02-07): > > ...so they are precisely broken by design. > > Words words words. > > Words to try and hide that something used to work for people and now you > are done with it it no longer works. > > Exactly the kind of attitude that killed libav, killing FFmpeg now. > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- 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] [RFC] Vote STF/SPI 2024-02
On Thu, Feb 1, 2024 at 9:11 PM Rémi Denis-Courmont wrote: > Le torstaina 1. helmikuuta 2024, 19.45.52 EET Vittorio Giovara a écrit : > > The same of course should apply to any other future funding, it must be > > either the community (via GA) or a third party setting up the > sponsorship. > > Neither the community or the GA can forbid people from seeking funding for > themselves. I suppose that, in theory, developers could be required to > sign an > agreement to that effect before they are allowed to submit code for > inclusion, > but that seems neither practical, nor desirable to me. > > That is probably not what you meant, but that is what this reads like. > Yeah that's not what I meant, sorry for the confusion: what I meant was whoever secures the funding, then cannot be directly funded for any of the projects attributed in the current funding. This might be counterintuitive and possibly controversial, but the goal here is to distinguish benefiting the community and benefiting oneself as well as avoid losing a possible funding: I would really like to avoid that we miss out on funding out of fear that whoever found the funding will strongarm the community into accepting something that the community may reject. In other words, this is both protection for the community and for whoever finds the funding. I don't know how enforce-able it is, or if it is something that can actually facilitate accepting future funding for the community, but since we're in a time crunch and we're voting with unanswered open questions, it is something we should at least consider. -- 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] STF SoWs
On Tue, Feb 6, 2024 at 3:18 PM Ronald S. Bultje wrote: > Hi, > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer > > wrote: > > > 2. Deliverables > > Patches submitted for review to the FFMPEG dev mailing list. > > > > I think the goal is to get patches merged, not submitted. > ┓┏┓┏┓┃ ┛┗┛┗┛┃＼○／ ┓┏┓┏┓┃ / NOBODY ┛┗┛┗┛┃ノ) ┓┏┓┏┓┃ KNOWS ┛┗┛┗┛┃ ┓┏┓┏┓┃ ┛┗┛┗┛┃ ┓┏┓┏┓┃ ┃┃ ┻┻ -- 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 0/2] Remove SDL2 output devices
On Tue, Feb 6, 2024 at 9:08 AM Michael Koch wrote: > Removing SDL2 sounds like a very bad idea. There are many examples which > are using these output devices, and all these examples would be broken. > A quick search in my book > http://www.astro-electronic.de/FFmpeg_Book.pdf > finds about 40 occurences for "-f sdl" or "-f sdl2". > would it be easier/possible to fix SDL to work on any thread, instead of keeping this odd architecture in the codebase? -- 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] STF SoWs
On Tue, Feb 6, 2024 at 3:06 AM Michael Niedermayer wrote: > Hi all > > As Jonatan reminded the ML we need to provide SoWs if we want to > participate in STF-SPI > > We need one for each project (they do not need to list a person ATM) > but obviously we do need someone who will do the work > > I do belive they do need to list the money amount. > Thanks go to Pierre for helping me write template/example. > (converted from google docs and with some last minute edits) > > @Jonatan, is this below what SPI needs for each project ? > Correct me if I'm wrong but we still need the answer on "merge forks". Which ones, where, and why -- ie what if the community doesn't want or need any particular one? -- 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] [RFC] Vote STF/SPI 2024-02
On Thu, Feb 1, 2024 at 5:29 AM Michael Niedermayer wrote: > Hi all > > To do the STF/SPI thing properly, and make sure we do what the Community > wants. > We should do this vote: (unless lots of people reply and say we should > skip the vote) > (i am also CCing jonatan to make sure the option in the vote actually ask > the GA the > right question) > > The vote description will be as follows: > The STF/SPI has suggested us to submit an Application / Scope of work > before their february meeting. > There are about 2 weeks left. > The minimum grant is 150 000 € > The next STF meeting is expected to be in may. If we submit in february > and are not selected > we can probably try again in may. Which would increase our chances > If we do not submit in february we can probably submit in may. > There is no guarantee that money will be available in may, for example > between october 2023 > and february 2024 no funds where available AFAIK. > Wiki page is here: > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 > > > Option A. The Application and Scope of Work from the WIKI shall be > submitted to STF/SPI before the february 2024 meeting, disagreements in it > shall be decided by the TC. To achieve continuity, submission shall be done > by the same person as previous if possible. > > Option B. No Application and Scope of Work shall be submitted in february > 2024 > Since all objections and requests for more time have been ignored, and this is happening anyway, can we add a small amendment for the sake of transparency and for avoiding any conflict of interest? Whoever was involved with the STF/SPI talks cannot be the recipient of the sponsorship. The same of course should apply to any other future funding, it must be either the community (via GA) or a third party setting up the sponsorship. I'm aware that would exclude Micheal, Thilo, and technically Jonatas, but at this point it's the only way I can see this move forward in any direction. Jonatas any feedback on this possibility? Thank you -- 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] Meeting at FOSDEM
On Sun, Jan 28, 2024 at 11:32 PM Jean-Baptiste Kempf wrote: > Hello Folks, > > FOSDEM is upon us, in a few days. > > It would be a great idea to meet for a FFmpeg discussion, since quite a > few of us will be there. > So please bring your technical topics with you :) > Maybe it's more infra than technical, but how to add samples to FATE and how to add people to that server? -- 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 1/2] avcodec: add ambient viewing environment packet side data.
On Tue, Jan 30, 2024 at 1:16 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Wednesday, 06 September 2023 at 18:27, Cosmin Stejerean via
> ffmpeg-devel wrote:
> >
> >
> > > On Aug 17, 2023, at 11:36 PM, Damiano Galassi
> wrote:
> > >
> > > Ping
> > >
> >
> > I believe this is still waiting for a FATE test to be added.
>
> Could this be added without a FATE test?
>
Ideally no, is there any concern with sharing such a sample?
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index f28e7e7011..199baad763 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -299,6 +299,13 @@ enum AVPacketSideDataType {
*/
AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
+/**
+ * Ambient viewing environment metadata, as defined by H.274.. This
metadata
Nit: double ".."
--
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] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 11:15 AM Nicolas George wrote: > Vittorio Giovara (12024-01-30): > > Sorry, but this feels a lot like “I have nothing to add to the > > conversation, but I feel like I need to speak up anyway”. > > Well... > > > It's not a veto when multiple eminent contributors outlined the problems > > with the current proposals, and I don't think ignoring them is beneficial > > to the community. I'm surprised I have to explain this *once again*. > > When several people say no and several people say yes, at the end, > whatever the chosen answer, some will feel they have been ignored. But > it is just a feeling. > > I am surprised to have to explain this at all. > Thanks for derailing the conversation and proving my point while at it. -- 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] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 11:07 AM Nicolas George wrote: > Vittorio Giovara (12024-01-30): > > Sorry but this feels a lot like "thanks for your feedback, I'm going to > do > > this anyway". > > Sorry, but this feels a lot like “I gave an objection, you have to treat > it like a veto”. > Sorry, but this feels a lot like “I have nothing to add to the conversation, but I feel like I need to speak up anyway”. It's not a veto when multiple eminent contributors outlined the problems with the current proposals, and I don't think ignoring them is beneficial to the community. I'm surprised I have to explain this *once again*. -- 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] Sovereign Tech Fund
On Tue, Jan 30, 2024 at 2:48 AM Michael Niedermayer wrote: > Hi all > > after people said they would help and start a wiki page (no not thilo dont > blame him) > I again wrote one myself. This is really early WIP > it contains the application we would send to STF, this is NOT written by me > and a few random projects > > the structure of the application at the end is i think fixed > so that can be edited but the general structure is specified by STF i think > > the stuff above the application is ours and can be changed without > limitation > > I mainly created this page so people can start collaborating on turning > this into > what they want it to look like. My version is trash as is, iam aware of > that > thats also why i was waiting and hoping someone who is actually good at > this > would start it > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 Sorry but this feels a lot like "thanks for your feedback, I'm going to do this anyway". -- 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] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 9:19 PM Anton Khirnov wrote: > Quoting Vittorio Giovara (2024-01-29 21:09:42) > > This is not something that should be discussed on a public ML > > Where do you think it should be discussed then? > IMO anywhere with a more limited set of constituents, such as the GA or the technical committee. I, for one, see a much bigger problem in the fact that it only starts > being discussed on the ML this late, after so much underground dealings > that bypassed the community entirely. > Of course, I cannot disagree there. -- 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] Sovereign Tech Fund
On Mon, Jan 29, 2024 at 8:22 PM Michael Niedermayer wrote: > > I have yet to see an actual project of "this magnitude" materialize as a > proposal. > > you can suggest one ? > libavscale! or there is nothing you want improved in FFmpeg ? > Or only if SPI isnt involved or iam not sure what exactly you want > different ? > I, for one, would love to stop seeing flame threads about funding FFmpeg that lead to nowhere. This is not something that should be discussed on a public ML and the lack of visibility and clarity on how SPI/STM got involved this time around is at least disingenuous IMO. -- 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] [RFC/PATCH] doc/developer: clarify the criterion for removing deprecated APIs
On Sun, Jan 28, 2024 at 11:47 PM Michael Niedermayer wrote: > On Sun, Jan 28, 2024 at 01:28:36PM +0100, Anton Khirnov wrote: > > Previously, the implicit standard was to wait 2 years before deprecation > > and removal, but it has been widely agreed at developer meetings that > > time-based measures do not make sense and we should switch to a > > release-based one instead. > > --- > > Feel welcome to argue for other numbers than 2, or suggest alternative > > criteria, but please try to limit bikeshedding. > > --- > > doc/developer.texi | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index dd96e3b36a..3f3218f66a 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -552,7 +552,8 @@ the negative effects on our callers, who are > required to adapt their code, > > backward-incompatible changes during a major bump should be limited to: > > @itemize @bullet > > @item > > -Removing previously deprecated APIs. > > +Removing APIs that were marked as deprecated in at least two previous > > +major releases. > > Removing APIs that were marked as deprecated in at least two previous > major releases for at least 1 year. > > (goal of this proposed difference is to ensure that if for whatever reason > we make several major releases in quick succession it doesnt deprecate > things faster) > IMO that's a bit verbose and given language is not precise it could lead to confusion (at least 1 year from deprecation? from a release with a deprecation warning? a mix of the two?) I find extremely unlikely that there will be two major releases, and these are supposed to be guidelines so I'm sure that even in that event we could reasonably delay things if 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 2/2] fate/video: add DXV3 HQ tests
On Sun, Jan 28, 2024 at 10:32 PM Connor Worley wrote: > I'd like to get this series merged before doing any further DXV work. Is > anyone able to help with uploading the linked samples? > I unfortunately don't have access to the FATE samples server, can you mail samples-requ...@ffmpeg.org? -- 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 1/2] Revert "avcodec: Rename ff_kbd_window_init() as it will be needed from outside libavcodec"
On Mon, Jan 29, 2024 at 8:58 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Michael Niedermayer:
> > On Sun, Jan 28, 2024 at 08:52:20PM -0300, James Almer wrote:
> >> On 1/28/2024 7:41 PM, Michael Niedermayer wrote:
> >>> On Sun, Jan 28, 2024 at 02:49:26PM +0100, Andreas Rheinhardt wrote:
> This reverts commits fd5aa93a37b3fa21195c6d7b22ef655124020e09
> and cf00f60bab1f79213c274a6cd4357b32bd5c0101
> ("avcodec/kbdwin: Support arbitrary sized windows").
>
> The change in question has only been made for libavradio.
> in anticipation of merging it into the main tree. This has
> not happened, so this commit reverts the changes to kbdwin
> that are not used for anything else. In particular, these
> functions are no longer exported (as avpriv functions);
> notice that the fixed-point function has been exported
> despite having never been used outside of lavc.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/aacdec_template.c | 8
> libavcodec/aactab.c | 4 ++--
> libavcodec/ac3dec.c | 2 +-
> libavcodec/ac3enc_fixed.c| 2 +-
> libavcodec/ac3enc_float.c| 2 +-
> libavcodec/dolby_e.c | 4 ++--
> libavcodec/kbdwin.c | 23 ---
> libavcodec/kbdwin.h | 10 --
> 8 files changed, 23 insertions(+), 32 deletions(-)
> >>>
> >>> I still intend to work on SDR either within what people agreed to
> >>> (that is a separate library) or in form of a fork.
> >>>
> >>> For both it is easier if the functions it needs are accessible
> >>>
> >>> thx
> >>
> >> Renaming an ff_ symbol into avpriv_ can happen at any time. Renaming an
> >> avpriv_ symbol to ff_ can only happen during a bump. So this patch is
> IMO
> >> ok.
> >> There's no warranty that whatever happens with SDR will happen before
> the
> >> next bump, so better remove as many exposed symbols as possible.
> >
> > You are missing something here.
> >
> > With the symbols, i can fork libavdevice and add SDR support.
> > Without the symbols, i cannot just do that. At least not cleanly
> > Because i need to replace libavcodec too and i need to extend its ABI
> > then.
> > This makes this more messy.
> >
>
> I would rather have you just copy the needed code into your fork of
> libavradio/libavdevice than add avpriv symbols (one of which was always
> unnecessary) for this.
>
Agreed, Michael is there any blocker for this to be done in your fork?
--
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 24/24] libs: bump major version for all libraries
On Thu, Jan 25, 2024 at 2:48 PM James Almer wrote: > Signed-off-by: James Almer > --- > doc/APIchanges| 2 +- > libavcodec/version.h | 2 +- > libavcodec/version_major.h| 2 +- > libavdevice/version.h | 2 +- > libavdevice/version_major.h | 2 +- > libavfilter/version.h | 2 +- > libavfilter/version_major.h | 2 +- > libavformat/version.h | 2 +- > libavformat/version_major.h | 2 +- > libavutil/version.h | 6 +++--- > libpostproc/version.h | 2 +- > libpostproc/version_major.h | 2 +- > libswresample/version.h | 2 +- > libswresample/version_major.h | 2 +- > libswscale/version.h | 2 +- > libswscale/version_major.h| 2 +- > 16 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index e477ed78e0..60711379a1 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -1,4 +1,4 @@ > -The last version increases of all libraries were on 2023-02-09 > +The last version increases of all libraries were on 2024-01-xx > > API changes, most recent first: > > diff --git a/libavcodec/version.h b/libavcodec/version.h > index 0fae3d06d3..8c3d476003 100644 > --- a/libavcodec/version.h > +++ b/libavcodec/version.h > @@ -29,7 +29,7 @@ > > #include "version_major.h" > > -#define LIBAVCODEC_VERSION_MINOR 38 > +#define LIBAVCODEC_VERSION_MINOR 0 > #define LIBAVCODEC_VERSION_MICRO 100 should we use this bump opportunity to reset MICRO to 0 too? -- 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 6/7] avcodec/hap: Avoid unnecessary opt.h inclusion
On Wed, Jan 24, 2024 at 9:06 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> It presumably exists because HapContext contains an AVClass*.
> Yet AVClass is actually defined in log.h and even this inclusion
> can be avoided by struct AVClass*. This avoids opt.h inclusions
> in hap.c and hapdec.c.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hap.h | 5 ++---
> libavcodec/hapqa_extract_bsf.c | 2 ++
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hap.h b/libavcodec/hap.h
> index a888b58fd7..1de6d45428 100644
> --- a/libavcodec/hap.h
> +++ b/libavcodec/hap.h
> @@ -23,10 +23,9 @@
> #ifndef AVCODEC_HAP_H
> #define AVCODEC_HAP_H
>
> +#include
> #include
>
> -#include "libavutil/opt.h"
> -
> #include "bytestream.h"
> #include "texturedsp.h"
>
> @@ -59,7 +58,7 @@ typedef struct HapChunk {
> } HapChunk;
>
> typedef struct HapContext {
> -AVClass *class;
> +const struct AVClass *class;
>
> GetByteContext gbc;
>
> diff --git a/libavcodec/hapqa_extract_bsf.c
> b/libavcodec/hapqa_extract_bsf.c
> index 0d9b40aaa6..eac9eafe42 100644
> --- a/libavcodec/hapqa_extract_bsf.c
> +++ b/libavcodec/hapqa_extract_bsf.c
> @@ -30,6 +30,8 @@
> #include "bytestream.h"
> #include "hap.h"
>
> +#include "libavutil/opt.h"
>
Is this include only for AVClass? Should it be log.h then?
--
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] lavc/dxvenc: add DXV encoder with support for DXT1 texture format
On Fri, Jan 19, 2024 at 8:17 PM Connor Worley wrote: > I've tested the latest patch with both the lavc decoder and Resolume's > proprietary software, and the encoded outputs are working for me. > Pushed, thank you -- 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] Add DXV encoder with support for DXT1 texture format
On Fri, Jan 19, 2024 at 5:56 PM Connor Worley
wrote:
> Thanks for the feedback! For the next revision, is it preferred to reply
> to this thread or create a new one?
>
here is fine
> On 1/19/24 08:23, Vittorio Giovara wrote:
> >> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> >> index 93ce8e3224..ef8c3a6d7d 100644
> >> --- a/libavcodec/allcodecs.c
> >> +++ b/libavcodec/allcodecs.c
> >> @@ -106,6 +106,7 @@ extern const FFCodec ff_dvvideo_encoder;
> >> extern const FFCodec ff_dvvideo_decoder;
> >> extern const FFCodec ff_dxa_decoder;
> >> extern const FFCodec ff_dxtory_decoder;
> >> +extern const FFCodec ff_dxv_encoder;
> >> extern const FFCodec ff_dxv_decoder;
> >>
> > nit: keep list in order
>
>
> Not sure what you mean, the present order seems to be encoder followed by
> decoder for codecs that have both.
>
disregard, I assumed it was in alphabetical order
> > What does the HT stand for?
>
>
> Hash table -- this change implements a simple linear probing approach.
>
got it, would be nice to have a small comment on why it's needed, as
documentation
> >> +#define LOOKBACK_WORDS0x20202
> >> +
> >> +enum DXVTextureFormat {
> >> +DXV_FMT_DXT1 = MKBETAG('D', 'X', 'T', '1'),
> >> +};
> >>
> > Why would you go for an enum here? Just for future expansion and the
> switch
> > case below?
>
>
> Exactly, that's the plan.
>
very cool
--
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] Add DXV encoder with support for DXT1 texture format
Hi,
thanks for the patch, below a few minor nits
On Wed, Jan 17, 2024 at 9:57 PM Connor Worley
wrote:
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 93ce8e3224..ef8c3a6d7d 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -106,6 +106,7 @@ extern const FFCodec ff_dvvideo_encoder;
> extern const FFCodec ff_dvvideo_decoder;
> extern const FFCodec ff_dxa_decoder;
> extern const FFCodec ff_dxtory_decoder;
> +extern const FFCodec ff_dxv_encoder;
> extern const FFCodec ff_dxv_decoder;
>
nit: keep list in order
> extern const FFCodec ff_eacmv_decoder;
> extern const FFCodec ff_eamad_decoder;
> diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
> new file mode 100644
> index 00..33080fa1c9
> --- /dev/null
> +++ b/libavcodec/dxvenc.c
> @@ -0,0 +1,358 @@
> +/*
> + * Resolume DXV encoder
> + * Copyright (C) 2015 Vittorio Giovara
> + * Copyright (C) 2015 Tom Butterworth
> + * Copyright (C) 2018 Paul B Mahol
> + * Copyright (C) 2024 Connor Worley
>
Idk about tom or paul, but I haven't done anything for this encoder :)
I think you can prune the list of copyright quite a bit here
> +#define LOOKBACK_HT_ELEMS 0x4
>
What does the HT stand for?
> +#define LOOKBACK_WORDS0x20202
> +
> +enum DXVTextureFormat {
> +DXV_FMT_DXT1 = MKBETAG('D', 'X', 'T', '1'),
> +};
>
Why would you go for an enum here? Just for future expansion and the switch
case below?
lgtm overall
--
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 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED
On Tue, Jan 2, 2024 at 4:06 PM Kieran Kunhya wrote: > > > > > and not the CLI (something this project is unable to understand). > > > > What is exposed by the API is exercised by the CLI (which is a good > > thing for scripting and for testing). > > > > The CLI can't just write random binary data to the terminal. What next, raw > frames available via JSON? I'm sure there are users who want that too. > Again, this is something that should either be parsed by FFmpeg or done via > the API. > +1 -- 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] lavc: remove the QOA decoder
On Thu, Dec 21, 2023 at 6:14 PM Nicolas George wrote: > Vittorio Giovara (12023-12-21): > > I agree, I hope you can work on your lack of self-awareness. > > Oh, the “Ah ?… Et moi, Cyrano-Savinien-Hercule De Bergerac.” comeback. > You're really scrapping the bottom of the barrel, aren't your. > No, I'm just pointing out the obvious, but there is none so deaf as those who will not hear. Anyway the offtopic has been gone long enough, no point in continuing this dead branch of a resurrected thread. For real, no harm feelings, thanks for this pleasant and fruitful exchange. -- 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] lavc: remove the QOA decoder
On Thu, Dec 21, 2023 at 5:41 PM Nicolas George wrote: > Vittorio Giovara (12023-12-21): > > Not sure what gave you the idea > > Mails like this one for example. The lack of self-awareness is > hilarious. > I agree, I hope you can work on your lack of self-awareness. -- 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] lavc: remove the QOA decoder
On Thu, Dec 21, 2023 at 5:22 PM Nicolas George wrote: > Vittorio Giovara (12023-12-21): > > Oh so you know how it feels! > > I am not surprised to see your animosity against me is stronger than > your care about the project. > Not sure what gave you the idea, but I have no animosity towards you and I appreciate your technical feedback when you share it. What surprises me is that you feel discouraged by the same treatment you have towards others in other discussions: it's been an actual concern of mine that your long paragraphs of empty text and sometimes toxic messages may have discouraged many people and companies to work on the project. All I hope is that we can all communicate better in 2024 and be able to work together. Fwiw I'm glad you and Paul agree on something at least, though, let's remember, the topic is a simple "new decoders should come with tests" and its objections seem an odd hill to die on. Cheers -- 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] Add new vf_tiltandshift filter
On Wed, Dec 20, 2023 at 2:56 PM Vittorio Giovara wrote: > > > On Wed, Dec 20, 2023 at 2:50 PM Nicolas George wrote: > >> Vittorio Giovara (12023-12-20): >> > If there are no more comments, I'll push this today or tomorrow. >> >> I think the change you made after the last request might go too far, but >> I have not had time to look at the code carefully enough to be sure. >> >> If a filter can produce several output frames from one input, then it >> must send at lease one of the NEW frames. >> >> An illustration to make it clear: if I1 allows to compute O1a, O1b, O1c, >> I2 allows to compute O2a, O2b, O2c, etc. >> >> Then when I1 arrives, the filter must output at least O1a, it can output >> O1b and O1c or not. >> >> But when I2 arrives, it must output at lease O2a, which means it must >> output O1b and O1c if that was not done at the time of I1. >> >> Your filter only outputs one frame per input, but it seems to me it can >> create several frames. >> > > the filter needs at least $width input frames to generate an output frame, > so it queues them > when the buffer is full, it will pop the head and generate the output > frame when the next input frame arrives, but the amount of input frames in > the queue needed to generate new frames is constant so it cannot output any > additional frames > at the end it will flush the buffer and generate the remaining output > frames > -- > pushed thanks -- 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] lavc: remove the QOA decoder
On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol wrote: > On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin wrote: > > > ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer: > > > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote: > > > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George: > > > [...] > > > > [...] , but every line of code > > > > carries with it a non-zero maintenance burden > > > > > > Assuming you mean with "non-zero" a "larger than zero" maintenance > > > burden > > > > > > then we can proof this to be false > > > > Doubt > > > > > What iam trying to say is, the maintaince burden resulting from a > > > change > > > is complex > > > > Indeed > > > > > In this specific case here we have a patch proposing the removial of > > > a decoder > > > missing a test. > > > Its easy to say the burden is less when the decoder is removed > > > But its author recently left the project too > > > > This is one problem. But the careless attitude to shoving more features > > into the codebase is far more serious. Every line of code is a CVE > > waiting to happen. Apparently this is a difficult thing to grasp for > > some contributors. It's an attitude I expect only from junior > > developers. > > > > Ensuring C code is correct and safe is *hard*. I have spent time > > formally verifying embedded C code for spaceflight. The lessons learned > > from this has made me supremely suspicious of cowboy coding. > > > > I have raised this issue multiple times in this project to no avail. I > > do not expect things to change. > > > > Say what serious feature you contributed ? - Nothing. > Contributions to the process that makes us code better and keep higher quality code are welcome. Let's not fall into the trap of "no commits therefore your opinion is invalid" way of thinking which only a fool would follow. -- 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] lavc: remove the QOA decoder
On Thu, Dec 21, 2023 at 3:31 PM Nicolas George wrote: > Paul B Mahol (12023-12-21): > > Say what serious feature you contributed ? - Nothing. > > I did not want to say it, but since it is now in the open: Not nothing: > negative. His naysaying discouraged me from working further on the > built-in documentation system. > Oh so you know how it feels! -- 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] Add new vf_tiltandshift filter
On Wed, Dec 20, 2023 at 2:50 PM Nicolas George wrote: > Vittorio Giovara (12023-12-20): > > If there are no more comments, I'll push this today or tomorrow. > > I think the change you made after the last request might go too far, but > I have not had time to look at the code carefully enough to be sure. > > If a filter can produce several output frames from one input, then it > must send at lease one of the NEW frames. > > An illustration to make it clear: if I1 allows to compute O1a, O1b, O1c, > I2 allows to compute O2a, O2b, O2c, etc. > > Then when I1 arrives, the filter must output at least O1a, it can output > O1b and O1c or not. > > But when I2 arrives, it must output at lease O2a, which means it must > output O1b and O1c if that was not done at the time of I1. > > Your filter only outputs one frame per input, but it seems to me it can > create several frames. > the filter needs at least $width input frames to generate an output frame, so it queues them when the buffer is full, it will pop the head and generate the output frame when the next input frame arrives, but the amount of input frames in the queue needed to generate new frames is constant so it cannot output any additional frames at the end it will flush the buffer and generate the remaining output frames -- 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] Add new vf_tiltandshift filter
On Fri, Dec 15, 2023 at 3:12 PM Vittorio Giovara
wrote:
>
>
> On Fri, Dec 15, 2023 at 12:34 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> > +static int list_add_frame(FrameList **list, size_t *size, AVFrame
>> > *frame)
>> > +{
>> > +FrameList *element = av_mallocz(sizeof(FrameList));
>>
>> The overhead of this FrameList is unnecessary: You can simply use
>> AVFrame.opaque as your next pointer.
>>
>
> Good tip! Attached an edited version, with all the other suggestions too.
> --
> Vittorio
>
If there are no more comments, I'll push this today or tomorrow.
Thanks
--
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] MAINTAINERS: remove myself from FFmpeg
On Tue, Dec 19, 2023 at 8:12 AM Nicolas George wrote: > Rémi Denis-Courmont (12023-12-07): > > You have had heated arguments against Paul in recent times too. You have > also > > argued a lot of exercising your review privileges, which sounds like a > very > > libavish notion to me > > Only because you were not there at the time to get a first-hand > impression. That patches should be reviewed if possible was the policy > way before libav. That came with a set of implicit rules: waiting a few > days, then pinging, then waiting a few days and only then pushing > without review. The role of maintainer would affect the reasonable value > for “a few” days. > > Paul insistence on pushing after barely 24 hours on code with a > maintainer that is not him always contradicting the way of doing things. > > Furthermore, his refusal to give more time to the maintainer when asked > to is not just that: it is a level of rudeness and incivility > incompatible with working together with other people. > > But Paul's attitude was annoying but never a real problem: resist his > eagerness a little and soon he finds something else to do and forgets > about pushing immediately for weeks or months. > > For reference, libav turned the practice that patches should be reviewed > into a hard rule that patches must be reviewed. At the same time, since > they had kicked out or disgusted a significant part of the projects' > maintainers, they had nobody capable of actually reviewing the code. As > a result, when a patch was proposed by a major libav contributor, after > the ping somebody else who did not know the code would post a clueless > “LGTM”. > > (The online archives of libav-devel seem to have disappeared, so I > cannot link to the example I bookmarked.) > I am not too sure that bringing up a topic from 12 days ago with arguments from 12 years ago is bringing any value to the conversation. Just as a note, remember that a clueless LGTM is a better review than NO review, and in fact it's the system that it's employed in any modern software house: the master branch is usually protected and any PR/MR needs both CI pass and at least a read from a developer. Oh and for the sake of your (and our readers') time, don't bother replying, I'm not interested in discussing 12 years ago affairs or modern development practices here. I do invite you to evaluate whether your vision of ffmpeg is still the one shared by the community as a whole though. Regards -- 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] Add new vf_tiltandshift filter
On Fri, Dec 15, 2023 at 12:34 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> > +static int list_add_frame(FrameList **list, size_t *size, AVFrame
> > *frame)
> > +{
> > +FrameList *element = av_mallocz(sizeof(FrameList));
>
> The overhead of this FrameList is unnecessary: You can simply use
> AVFrame.opaque as your next pointer.
>
Good tip! Attached an edited version, with all the other suggestions too.
--
Vittorio
0001-Add-new-vf_tiltandshift-filter.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] [PATCH] Add new vf_tiltandshift filter
On Tue, Dec 12, 2023 at 3:00 AM Nicolas George wrote: > Vittorio Giovara (12023-12-11): > > This is an older filter I wrote and never got around publishing. > > It can be used to generate a distortion effect like > > https://vimeo.com/104938599?share=copy > > Please see attached. > > Your code is doing in request_frame() what should be done in > filter_frame(). That will work in simple linear graphs but not in > graphs with branches and/or time shifts. See doc/filter_design.txt for > details. > Thanks for the review, attached the proposed changes. -- Vittorio 0001-Add-new-vf_tiltandshift-filter.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".
[FFmpeg-devel] [PATCH] Add new vf_tiltandshift filter
This is an older filter I wrote and never got around publishing. It can be used to generate a distortion effect like https://vimeo.com/104938599?share=copy Please see attached. -- Vittorio 0001-Add-new-vf_tiltandshift-filter.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] [PATCH] lavd/avfoundation: Use correct preprocessing directive
On Mon, Dec 11, 2023 at 12:37 PM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Am 11.12.23 um 18:29 schrieb Vittorio Giovara: > > Fixes compilation, introduced in e37b15e. > > > > src/libavdevice/avfoundation.m:799:10: error: invalid preprocessing > > directive > > Which compiler did complain about that? > Apple clang version 15.0.0 (clang-1500.0.40.1) Target: arm64-apple-darwin23.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin -- 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".
[FFmpeg-devel] [PATCH] lavd/avfoundation: Use correct preprocessing directive
Fixes compilation, introduced in e37b15e. src/libavdevice/avfoundation.m:799:10: error: invalid preprocessing directive #elseif (TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED < 14) -- Vittorio 0001-lavd-avfoundation-Use-correct-preprocessing-directiv.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".
[FFmpeg-devel] MAINTAINERS: Remove older s3tc entry
Missed from a5b2b22d9a45c9634e6947d43945ebafe121abec. 0001-MAINTAINERS-Remove-older-s3tc-entry.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] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote:
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 2cfb3fcf97..f9b18a2c35 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> validate_avframe_allocation(avctx, frame);
>
> +if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> +uint32_t color[4] = {0};
> +ptrdiff_t linesize[4] = {frame->linesize[0], frame->linesize[1],
> frame->linesize[2], frame->linesize[3]};
> +av_image_fill_color(frame->data, linesize, frame->format, color,
> frame->width, frame->height);
>
I think it's be safer to add a return check here
--
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] lavc: remove the QOA decoder
I ain't reading all of that Happy for you Or sorry that happened On Wed, Dec 6, 2023 at 3:47 PM Nicolas George wrote: > Vittorio Giovara (12023-12-05): > > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of > > literature about feature creep and how important it is to remove dead > code. > > You should read said literature before quoting it, you would learn the > difference between more features and feature creep: creeping features > make it harder to maintain core features. > > So, can you prove that this QOA decoder makes it harder to maintain the > framework of FFmpeg? No, you cannot. > > > Uhhh, but maybe I'm just misinterpreting your message, but that looks > like > > a very ignorant comparison. > > It is not ignorant at all, you show exactly the same argument structure. > > Homophobes cannot prove homosexuality causes objective and immediate > harm to anybody. > > You cannot prove that Paul's code causes objective and immediate harm to > the project. > > So homophobes resort to invoking a vague harm to society / youth / > whatever. > > So you resort to invoking a vague harm to a generation. > > You do it because you have a strong intuition that it is true. > > Homophobes have a strong intuition that it is true too. > > But intuition without arguments has no place in a debate, it cannot > convince anybody. > > And your intuition is just as wrong as the homophobes'. > > In this instance, your intuition is wrong because it applies to FFmpeg > what it knows about professional projects — open or closed source — > whereas FFmpeg is not a professional project but a Libre Software > projects whose most talented contributors work for fun. > > In a professional project, the time and effort of developers is limited > and must be focused on useful things. In a project like FFmpeg, the time > and effort that talented developers invest in the project grows as they > can work on fun tasks, even when said tasks are of limited usefulness. > > A sure way of killing a project like FFmpeg is to prevent people from > working on the things they find fun and try to force them to do useful > things instead, either by outright rejecting if you have the authority > or by drowning them with bickering and demands, like you did with > Michael and like you just ran Paul out. > > Good job. > > -- > 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". > -- 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 v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote: > Lie. > A summary of your proposal or a link to your suggestion would be appreciated. Without reference we're all shouting in the void. > I guess now that your side holds most of the power the mask is off. > > This mail you just sent should be enough to get you kicked out three > times over. > I actually chuckled at this line :-D But that will not happen, will it? > > Congratulations, you are on track to become FFmpeg's de-facto dictator, > just like you were libav's de-facto dictator and ran it to the ground > with your blatant disregard for users and disrespect for fellow > developers. > I don't think improving the ffmpeg CLI tools shows any "disregard for users" and having code in parallel shows a lot of respect to fellow developers since it makes our life easier. You seem fixed on a crusade of keeping the status quo, but the consensus you speak of is instead to move forward. Yes some very minor use cases might break or see degraded performance, but that's the point of a development branch - so that we can all improve the code before the next stable release > I hope Fabrice keeps control of the domain, so that we can revive FFmpeg > in a few years. > See? this is what i mean, you're still in 2011. It's time to move on Nicolas, for your own sake, and for respect to your fellow developers and the users you hold so dear -- 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 v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. > LGTM -- 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] lavc: remove the QOA decoder
On Tue, Dec 5, 2023 at 9:59 AM Nicolas George wrote: > Vittorio Giovara (12023-12-05): > > I'm not bickering, > > That is exactly what you do. > And you are not? The view must be great from that glass house > actively include testing as part of the bare minimum process to accept the > > patch/review is harming the whole generation of developers. > > I agree that Paul's attitude is utterly toxic to the project, but > Anton's attitude of removing features is way worse. At least Paul almost > only pollutes his own code. > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of literature about feature creep and how important it is to remove dead code. > As for harming a whole generation, it is the same vague argument used by > everybody to condemn anything they do not like, like homosexuality for > example, and that argument is always the same level of bullshit. > Uhhh, but maybe I'm just misinterpreting your message, but that looks like a very ignorant comparison. -- 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] lavc: remove the QOA decoder
On Tue, Dec 5, 2023 at 2:45 AM Nicolas George wrote: > Vittorio Giovara (12023-12-04): > > It's almost 2024, when will you be able to drop it? > > Never. When will YOU be able to drop bickering about parts of the code > that do no harm and do not bother you? > I'm not bickering, we're having a discussion on a mailing list (aka the point of having a list in the first place) -- also, having someone in one of the largest mailing lists promoting a development model that does not actively include testing as part of the bare minimum process to accept the patch/review is harming the whole generation of developers. Please stop saying nonsense, or do it with a bit more kindness without bringing up dead projects, and I'll stop answering you. Believe me I want this more than you do. Cheers -- 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] lavc: remove the QOA decoder
On Mon, Dec 4, 2023 at 1:53 PM Nicolas George wrote: > Anton Khirnov (12023-12-02): > > Its author not only failed to add any tests, as is required by the > > development rules, but continues to actively refuse to do so. > > > > Untested decoders are worse than useless, so remove it. > > Only tested manually ≠ untested. > > A code that works is better than no code at all. > > We are not libav, we do not remove code just because the Great Dictator > says so. If you really really want this decoder to have a test, you can > write add it yourself. > It's almost 2024, when will you be able to drop it? -- 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 4/6] avcodec/h264: keep track of which frames used gray references
On Sun, Nov 19, 2023 at 7:11 PM Michael Niedermayer
wrote:
> On Tue, Nov 14, 2023 at 07:46:16PM +0100, Michael Niedermayer wrote:
> > On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> > > On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/h264_picture.c | 1 +
> > > > libavcodec/h264_slice.c | 19 ++-
> > > > libavcodec/h264dec.c | 1 +
> > > > libavcodec/h264dec.h | 4
> > > > 4 files changed, 24 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > > > index 691c61eea23..3234141dbd6 100644
> > > > --- a/libavcodec/h264_picture.c
> > > > +++ b/libavcodec/h264_picture.c
> > > > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture
> *dst, const H264Picture *src)
> > > > dst->field_picture = src->field_picture;
> > > > dst->reference = src->reference;
> > > > dst->recovered = src->recovered;
> > > > +dst->gray = src->gray;
> > > > dst->invalid_gap = src->invalid_gap;
> > > > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > > > dst->mb_width = src->mb_width;
> > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > index 4861a2cabba..2c4ab89dae1 100644
> > > > --- a/libavcodec/h264_slice.c
> > > > +++ b/libavcodec/h264_slice.c
> > > > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext
> *dst,
> > > > h->poc.prev_frame_num= h->poc.frame_num;
> > > >
> > > > h->recovery_frame= h1->recovery_frame;
> > > > +h->non_gray = h1->non_gray;
> > > >
> > > > return err;
> > > > }
> > > > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h,
> const H264SliceContext *sl,
> > > > if (ret < 0)
> > > > return ret;
> > > > h->short_ref[0]->poc = prev->poc + 2U;
> > > > +h->short_ref[0]->gray = prev->gray;
> > > > ff_thread_report_progress(>short_ref[0]->tf,
> INT_MAX, 0);
> > > > if (h->short_ref[0]->field_picture)
> > > > ff_thread_report_progress(>short_ref[0]->tf,
> INT_MAX, 1);
> > > > -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> > > > +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > > > color_frame(h->short_ref[0]->f, c);
> > > > +h->short_ref[0]->gray = 1;
> > > > +}
> > >
> > > While we can't color invalid frames for hwaccels easily, the flag
> > > should perhaps still be applied, as they are equally invalid.
> >
> > ok
>
> will apply with this changed
>
> >
> >
> > > Thinking about this, maybe the name should be less the color we
> > > happened to use for it, and more like "placeholder" or "invalid" or
> > > anything like that?
> >
> > "invalid" is a quite generic term that covers more than this case.
> > and iam not sure if "placeholder" is really good description of them.
> > I picked "gray" because i had no better idea and they are gray
>
> if someone comes up with a better name, we can rename it
> but gray is kind of fitting
>
Sorry, what exactly are h264 gray frames?
Could you add some documentation to the new field in H264Picture too?
--
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 Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > I hope you can grasp the difference between CAN and WOULD. That would be > better than calling somebody's logical arguments “FUD”. > You're right, we should call things by their name, these arguments are illogical. -- 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 Tue, Nov 14, 2023 at 10:56 AM Tomas Härdin wrote: > Ballot secrecy cannot actually be guaranteed. While I'm not versed in > the specifics of CIVS, I doubt it has solved problems like evil > sysadmin. Ballots should be public IMO, secret voting is cowardice. > That way duplicate ballots are easily filtered out ex-post and > scrutable to all. > Absolutely not, you're mixing cowardice for safety and privacy, especially in a community that is prone to toxic language and harassment. Further reading https://www.rochester.edu/newscenter/should-secret-voting-be-mandatory-yes-say-political-scientists-459082/ https://www.quora.com/Should-voting-be-public-so-that-everyone-one-knows-what-everyone-else-voted-for-instead-of-secret https://daily.jstor.org/why-do-we-vote-by-secret-ballot/ https://campaignlegal.org/update/voters-have-right-secret-ballot https://www.quora.com/Why-is-it-important-for-votes-to-be-secret What really matters is records for every vote, and automatic random audits, so that results can be reproduced. -- 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".
[FFmpeg-devel] Fwd: Poll: Repeat vote: GA voters list updates
This is ridiculous, and everybody involved in this second vote should be ashamed of themselves. -- Forwarded message - From: Thilo Borgmann (CIVS poll supervisor) If you would like to vote, please visit the following URL: https://vote.ffmpeg.org/cgi-bin/civs/vote.pl?id=E_07e9c717f7820201=7324c23f1e12682a This is your private URL. Do not give it to anyone else, because they could use it to vote for you. -- 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 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] [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] 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
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] upcoming vote: extra members for GA
On Fri, Nov 10, 2023 at 2:31 PM Michael Niedermayer wrote: > On Fri, Nov 10, 2023 at 02:24:23PM +0200, Rémi Denis-Courmont wrote: > > > [...] or at least allow people to resign from the GA discretionarily. > > I think this makes alot more sense > > Asking "I want to be in the GA" fully in public is something thats a very > high bar for some people. It certainly is a very low bar for others yes > > If we imaginge every citizen in a country would have to publically demand > in front of the whole citizenship their vote right, explain why they should > have the right and then be voted on by all before receiving the right. > Thats not something normally required to receive voting rights. > No, that is not required at all, but what is required is for people willing to vote is to register, and you cannot register someone else, unless for election fraud. Am I missing something or am I taking crazy pills? I think this bar is too high. Especially for a project that just a moment > ago complained about sustainability. > We should welcome everyone who wants to participate not setup barriers But we are welcoming everyone! And having a reliable process like it's being established *is* a way to being more sustainable. At the same time, we also need to get stuff done, so while the community noted your feedback and has taken proper action for it (delaying the vote and inviting people to candidate themselves) there is nothing else to be done about it in my opinion, so I'd suggest moving on. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 3:17 PM 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. > > I think this is asking too much and it is unfair. We are not in any other > case demanding that people announce themselfs infront of everyone for > anything. Not for joining the mailing list, Not for anything else. > Especially not for having vote rights. > This is unmanageable. As mentioned, being subscribed to the mailing list should be the very first minimum requirement, and secondly the candidates should speak up. We don't want people to put words in their mouth, or guilt trip them into performing work they don't want to do, or given the project's troubled history give them a ptsd attack bringing back bad memories. Voting is definitely a right, and in most rights there are obligations tied to it as well, one of them is the obligation of announcing publicly a candidacy to the GA. -- 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: extra members for GA
On Thu, Nov 9, 2023 at 10:40 AM Michael Niedermayer wrote: > On Thu, Nov 09, 2023 at 07:11:37AM -0500, Vittorio Giovara wrote: > > On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > Fabrice Bellard(Founder of the project over 600 commits in FFmpeg) > > > Aman Karmani (17 authored commits in 2020-2023, recently active > in > > > 2023-June and work all over the codebase) > > > Baptiste Coudurier (Pays for our fate server since forever, maintains > 15 > > > things in MAINTAINERs, is the the copyright of 56 files, over 1900 > commits > > > in FFmpeg) > > > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > > > Lauri Kasanen (Linux / PowerPC maintainer) > > > Dale Curtis(14 commits in 2020 was in the 2020-GA) > > > Alexander Strasser (Root admin, just recently reported that he could > not > > > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > > > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, > s337m) > > > Huiwen Ren (8 matches in the codebase of his name, avs2* and > > > related things maintainer) > > > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > > > hostility) > > > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in > the > > > 2020-GA but not on jbs list) > > > Matthieu Bouron(over 200 commits in FFmpeg, recently active in > 2022, 5 > > > entries in MAINTAINERs, 25 in copyrights) > > > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > > > various bits of code, last active in git in 2020) > > > John Stebbins (over 100 commits in FFmpeg, last active in git in > > > 2020, 1 copyright match) > > > Ting Fu(last active in April 2023, 24 commits in > 2021-2023, ) > > > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > > > commits in FFmpeg) > > > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his > name > > > in the source, last commit May 2023) > > > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > > > commit in Oct 2023, 49 matches for his name in the codebase) > > > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > > > MAINTAINERs, 70 copyright line matches) > > > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in > MAINTAINERs, > > > 4 copyrights, last commit in Jul 2023) > > > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > > > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > > > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in > MAINTAINERs, > > > 22 copyright matches) > > > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > > > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > > > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > > > > just noting some people in the list have cut ties with this project and > > would much rather not be involved in anything related to ffmpeg - > > People who do not want to be in the GA should be ommitted, thats obvious > i agree with that of course. > > > > as a rule > > of thumb it's probably safe to omit inactive developers and inactive > > founders from the list, in my opinion > > That i do not agree with. > For example iam inactive in SPI and i do NOT vote in SPI but i very > much want to maintain my ability to vote if a situation arises that > matters. > Why ? FFmpeg has alot of money with SPI so I want to maintain my ability to > cast a vote if a special situation arrises. > Right but you *are* maintaining an active interest in SPI because it matters to you and the project, but your situation doesn't directly translate to the people listed, who might consider being included automatically as spam in the best case and offensive in the worst case. if you flip this around. Some inactive contributors are very dependant > on FFmpeg in their jobs. I do not belive they want to have no say in > major decissions in FFmpeg. > I mean if they are "very dependent" maybe they should spend a minimum time of "volunteer service" if they want to have a stake in voting matters. Voting is a right but it has obligations too, and just diluting the GA with inactive people (who might not even vote) won't do the project any good > Why did i include people who left due to hostility? > It was a
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer wrote: > Fabrice Bellard(Founder of the project over 600 commits in FFmpeg) > Aman Karmani (17 authored commits in 2020-2023, recently active in > 2023-June and work all over the codebase) > Baptiste Coudurier (Pays for our fate server since forever, maintains 15 > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > in FFmpeg) > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > Lauri Kasanen (Linux / PowerPC maintainer) > Dale Curtis(14 commits in 2020 was in the 2020-GA) > Alexander Strasser (Root admin, just recently reported that he could not > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > Huiwen Ren (8 matches in the codebase of his name, avs2* and > related things maintainer) > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > hostility) > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > 2020-GA but not on jbs list) > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > entries in MAINTAINERs, 25 in copyrights) > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > various bits of code, last active in git in 2020) > John Stebbins (over 100 commits in FFmpeg, last active in git in > 2020, 1 copyright match) > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > commits in FFmpeg) > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > in the source, last commit May 2023) > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > commit in Oct 2023, 49 matches for his name in the codebase) > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > MAINTAINERs, 70 copyright line matches) > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > 4 copyrights, last commit in Jul 2023) > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > 22 copyright matches) > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > just noting some people in the list have cut ties with this project and would much rather not be involved in anything related to ffmpeg - as a rule of thumb it's probably safe to omit inactive developers and inactive founders from the list, in my opinion -- 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] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
On Wed, Nov 8, 2023 at 3:46 PM Alexander Strasser wrote: > On 2023-11-08 12:40 +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-10-31 09:40:44) > > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > > last bit of the last coefficient be toggled so that the sum > > > > of all coefficients is odd; both our decoder and encoder > > > > did this only if the bitexact flag has been set (although > > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > > This patch changes this by removing the spec-incompliant > > > > functions. > > > > > > This commit message should include benchamarks documenting the speed > loss > > > (of the unquantize, the IDCT and overall) > > > It is expected that the speed of some IDCTs will be impacted negativly > > > as the non zero terms will prevent the skiping of some significant code > > > > > > as well as information about how much PSNR improves (to the encoder > input) > > > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > bitexactly > > > specified in MPEG-2 so one could think of this as a > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > instead of spec non compliance > > > > > > Only after the benchmarks and PSNR is presented should we decide if > this > > > is a change we want > > > > I disagree that the burden of proof should be on Andreas here. It should > > be up to whoever wants to keep this code to show that it is useful. > > There was an argument presented. > > That argument could be challenged or otherwise explained why it more > important to have this always behave like with bitexact. > > This could lead to "OK, I think removal is better" or if not benchmarks > could lead to one or the other decision. > > Saying the burden is on whoever wants to keep the code sounds like a way > for arbitrary code removal. While I agree getting rid of code can be a good > thing, this would definitely take it too far. > To be fair, this is noncompliant spec code, it shouldn't be present at all since it produces inconsistent results (with the spec) and there is no device particularly needing this functionality.It's not arbitrary code removal, it's removing something that is not needed any more since the speed impact (pro or against) is negligible on modern computers. I'm of the opinion that presenting an argument against such a targeted and specific code removal with no supportive use case should be noted but not acted upon, until relevant proof is brought over. Yes sadly that burden should fall on whoever is presenting the argument. -- 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 Tue, Nov 7, 2023 at 2:44 AM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > Correct, it's you trying to win arguments with aggressive communication > > No. You came into an argument without knowing the first thing about it > and you decided to side with the guy who wants to violate the project's > policy about review. > Oh you like policies now? Interesting :) Your behavior in this thread was toxic from your very first post. I'm sorry but it was your behavior that has been toxic, rude, and frankly unacceptable. It seems like you pick on everybody who dares to confront you, and don't care about taking an entire discussion offtopic just for the sake of winning an argument. To better explain the case at hand, there is no developer policy that lets you request an indefinite amount of review time with a single "No, you are not" message. A good way to ask for an extension would be a message like "Please let me have a few days to review this and debug it. I know last time I used the same request only to test you and spread more toxicity around me, but this time I really mean it". ( https://ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316297.html)... Hm I wonder why your request is being ignored now. And no, I am not siding with anybody, skipping over your personal attack about my libavfilter knowledge, I literally have no stake in the matter. I do recognize toxic behavior tho, and I think it should stop at a certain point, as the list deserves better than reading this email exchange. If you would like to provide more technical feedback to the patch (or bring references to points already made), please go ahead, otherwise just drop this vendetta you seem to have against everybody in your path. Please and thank you, I believe in you. -- 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 Mon, Nov 6, 2023 at 6:05 PM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > Stop twisting people's words and implying things they never said :) > > This is not you presenting excuses. > Correct, it's you trying to win arguments with aggressive communication > And thank you for ignoring my request to stay on topic > > There is no topic to stay on: I will review this bug when time permits, > and you do not know anything about lavfi's scheduling so you cannot > help. > Projecting much? -- 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 Mon, Nov 6, 2023 at 5:49 PM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > I'm not misrepresenting anybody's words, > > Me: “I never doubted that Paul's patches do make the bug go away in your > test case.” > > You: “you insisted it wasn't there” > > This is precisely misrepresenting my words. > > So stop lying and present excuses > Stop twisting people's words and implying things they never said :) And thank you for ignoring my request to stay on topic, this really shows the shortcomings of the mailing list and how important live communication and IRC texting is. Paul, feel free to push at any time. -- 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 Mon, Nov 6, 2023 at 4:46 PM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > Nice try but pointing out your logical fallacies is not being rude, but > > rather is just showing you how easily your message can be misinterpreted, > > You have done nothing of the sort. You have just misrepresented my > words, showing that you decided to barge into a conversation without > knowing its details. > No, you barged out and started calling fair arguments "bullshit" while I'm trying to have a polite discussion. I'm not misrepresenting anybody's words, just making sure you understand how belittling and prone to misinterpretation your comments are due to harsh style of communication. I think I'm advising you to improve that through the lines in order to have better success in getting your point across. > And yes, asking for time when you yourself do not provide a > > timeline is equivalent to vetoing a patch (indefinitely too, since you > > yourself say you "will review this issue when [you] have the time", which > > could very well be never). > > And now you are accusing me of outright dishonesty. Better and better. > I'm not a lawyer, this is not a trial, nobody's accusing you of anything. I'm just pointing out the facts that lead to *a* reasonable conclusion, you could prove me wrong by providing a sound technical discussion but you insist in this syllogistic battle, hence the long off topic, and the continued bickering. > > I feel like, once again, we've exhausted this topic > > You have exhausted because you barged in without knowing the first thing > about it. > No, we've exhausted the topic because you insist on playing the "who is right" game with someone who has no stake in the matter. Right now, if I acted like you do, I'd start a long paragraph saying something like "oh this is a process of intentions" or "so you're accusing me of barging in, this rude/dishonest/$adjective", but instead I'm patiently trying to bring the discussion back to the technical points raised previously. Can we focus on them please? > > Please justify your objections to the proposed solution, > > I have already done so, but again you neglected to read it: if there is > a bug, it is in the framework code. > Paul already explained why it is not, in the email starting with "Sorry to hear your deep feelings and failed realizations for this topic and in FFmpeg in general." You seem to have neglected to read it and reply to the points made there. -- 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 Mon, Nov 6, 2023 at 3:50 PM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > world, please make a minimum of effort to keep communication polite > > Please realize that politeness resides not only in which words we use, > like “bullshit”, but also in what we say, even if it is with very mild > words. For example: > > > while you insisted it wasn't there > > Pretending I said something when I said precisely the opposite is > extremely rude from you. > > Or: > > > That is not how it works, you cannot indefinitely veto a patch > > Pretending that I try to veto a patch when I am just demanding the time > to properly review it is extremely rude from you. > Nice try but pointing out your logical fallacies is not being rude, but rather is just showing you how easily your message can be misinterpreted, due to the aggressive and non-constructive way of communication you insist on using. And yes, asking for time when you yourself do not provide a timeline is equivalent to vetoing a patch (indefinitely too, since you yourself say you "will review this issue when [you] have the time", which could very well be never). I feel like, once again, we've exhausted this topic, and before delving into what is rude and what is time, let's get back to the technical merits of the patch. Please justify your objections to the proposed solution, provide proof that this patch is invalid, or send code that improves upon this. Thank you -- 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 Mon, Nov 6, 2023 at 3:28 PM Nicolas George wrote: > Vittorio Giovara (12023-11-06): > > You gave no indication you were willing to, and I thought he gave you > time > > Bullshit. Please do not intervene in a thread when you do not know what > is going on at all. Paul has been repeatedly rude and threatened to push > before review, yet it is towards me you address your criticism. > Please as a non-native English speaker to another non-native English speaker, you may miss that this comes off extremely aggressive and offensive especially in text form. And this is a public mailing list, everybody is allowed to intervene in every thread -- if you don't like it, take your discussion offline. There is no need for some language or behavior, while I can understand being mad at Paul, the community, or the world, please make a minimum of effort to keep communication polite, and efficient, as stated multiple times. Belligerence will take you nowhere. > > on the other thread for a related bug and you used it for mind games. > > Anyway, usually code trumps words, so the course I'd suggest is agreeing > on > > a feasible time window, and if you can get a better patch out, then > submit > > it, otherwise Paul's can go in. > > No. I will review this issue when I have the time and Paul will wait. > This is how it works. Invalid patches do not go in just because the > maintainer is busy or sick. > That is not how it works, you cannot indefinitely veto a patch just because you think it is invalid. Your concerns in the first email were addressed in Paul's reply. In the other thread, 3 people verified the presence of the bug while you insisted it wasn't there, while also confirming the patch is valid. If you can provide further counterpoints to Paul's explanation, please share them instead of silence, if you have anything substantial (code wise) to add please do so, otherwise let the patch in. This bickering on the list cannot continue. -- 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".
