Re: [FFmpeg-devel] [RFC] STF 2025
On Fri, May 17, 2024 at 9:50 AM Michael Niedermayer wrote: > Hi all > > Before this is forgotten again, better start some dicsussion too early > than too late > > I propose that if we have the oppertunity again next year to receive a > grant > from STF. That we use it to fund: > > * Paul to work on FFmpeg full time. My idea here is that he can work on > whatever > he likes in FFmpeg (so its not full time employment for specific work but > simply full time employment for him to work on whatever he likes in > FFmpeg any > way he likes) Paul is the 2nd largest contributor to FFmpeg (git > shortlog -s -n) > why? nothing against Paul, but this seems pretty arbitrary, and many people would like to be paid to do whatever they want if we start sponsoring people there should be clear statements of work, goals, and everything in between * Fund administrative / maintainance work (one example is the mailman > upgrade that is needed > with the next OS upgrade on one of our servers (this is not as trivial > as one might > expect). Another example here may be some git related tools if we find > something that > theres a broad consensus about. > > * Fund maintaince on the bug tracker, try to reproduce bugs, ask users to > provide > reproduceable cases, close bugs still unreproduceable, ... > ATM we have over 2000 "new" bugs that are not even marked as open > I see no mention of github/gitlab work, despite being highly requested on the list. Is it because we assume it'll be done already by next year? :) > something like a video chat. Also we need more cute girls on these > events, everything i hear > its 100% male geeks/hackers. Also a "24/7" realtime stream from any > booth would be nice > I understand the idea comes from a good place, but the way it is phrased is very sketchy. -- 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] 5 year plan & Inovation
On Sat, May 4, 2024 at 4:35 PM Michael Niedermayer wrote: > > - secure funding for larger projects > > what project you want to get funding for ? > A wide range of things are funded, and last i asked when STF money was > available > i couldnt even find enough people willing to submit a project to reach > 150k € > > hint hint: there is 2025 and we need maintaince projects to submit to STF > in 2025 > move the infrastructure and review process to github/gitlab/gitea/forgeio -- 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] 5 year plan & Inovation
On Sat, May 4, 2024 at 3:09 PM Michael Niedermayer wrote: > On Sat, May 04, 2024 at 02:04:16PM -0400, Vittorio Giovara wrote: > > On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala wrote: > > > > > On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote: > > > > I have tried git-send-email, but it failed. You can say that I am > stupid, > > > > but I would say that this is because of various reasons such as my > area > > > and > > > > the network. It is really not what I can solve. > > > > Maybe I will spend a lot of energy trying it in the future, but this > is > > > > because I have submitted thousands of lines of code. I don't want to > give > > > > up. If it is from the beginning, it will cause abandonment. > > > > > > > > Maybe I am younger here in FFMPEG. I have a lot of good young people > > > around > > > > me. They all use github/lab by default, and there will be the same > > > problem > > > > as me, resulting in abandonment. > > > I feel it's worth pointing out that SourceHut and mailing list-based > > > workflows > > > are becoming popular in some young-dev circles. I am in my twenties for > > > reference. > > > > > > With that said, I did not realize how problematic setting up git > send-email > > > can be with some providers when I wrote what you're replying to. The > > > replies > > > quite surprised me honestly because when I first set up git > send-email, I > > > was using completely average providers and it was all pretty > effortless, > > > I just adjusted git's config and it worked perfectly. > > > > > > > I don't really care about the quality between these tools. I think > people > > > > are important. I only want to use it, and I can facilitate the real > > > > reviewer of Review. > > > > > > > > I don't know if I can say my personal feelings here, but I will say: > > > > > > > > I feel despised by this passage, which makes me uncomfortable. If you > > > are a > > > > reviewer, maybe I have no chance to contribute, but anyway, I have > made > > > > some contributions. > > > > > > > > > How can anyone use git, but not git send-email? Any decent email > > > provider > > > > > has support for external clients over SMTP. And I believe you *can* > > > > > > > > actually dictate that people don't attach patches -- if you have > > > control > > > > > over the mailing list software, you can set up a filter that > rejects > > > such > > > > > emails and auto-replies with instructions on how to send them > properly. > > > > I think I should have the right to contribute > > > Likewise. > > > > > > Regarding the part about rejecting patches as attachments, I was > > > specifically > > > reacting to Rémi claiming that he can't dictate that people don't use > them, > > > which technically he can. I never said it's a good idea, though it > might > > > have > > > sounded that way. Sorry about that. > > > > > > As I said multiple times, I feel like contributing over email is a lot > > > about > > > having good tooling. For example, the email client I use treats all > parts > > > of > > > a multipart message the same, so it has no issues replying to text > > > attachments > > > instead of the message body. As such, there is no difference between > > > attached > > > patches and patches in the message body with such a client. > > > > > > > Is it me or has this thread and topic run its course? > > We understand your preference is email and it is duly noted, the > > overwhelming majority of the community still seem to prefer > github/gitlab. > > Any further discussion at this point looks off topic, there are better > > venues for discussing the technical merits of email vs github/gitlab. > > Is it me or are the top 3 people who objected to gitlab on vaccation, > banned > and busy ? > Maybe we should wait for them to have an oppertunity to comment. One of > them > happens to be an experienced gitlab admin > If one is banned, then they lose the chance to express their opinion in the community, it's the whole point of being in a community! You act civil and your opinions are heard, you troll and you get banned, pretty simple to me. If we ban people and then wait for them to be unbanned before we take decisions defeats the
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala wrote: > On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote: > > I have tried git-send-email, but it failed. You can say that I am stupid, > > but I would say that this is because of various reasons such as my area > and > > the network. It is really not what I can solve. > > Maybe I will spend a lot of energy trying it in the future, but this is > > because I have submitted thousands of lines of code. I don't want to give > > up. If it is from the beginning, it will cause abandonment. > > > > Maybe I am younger here in FFMPEG. I have a lot of good young people > around > > me. They all use github/lab by default, and there will be the same > problem > > as me, resulting in abandonment. > I feel it's worth pointing out that SourceHut and mailing list-based > workflows > are becoming popular in some young-dev circles. I am in my twenties for > reference. > > With that said, I did not realize how problematic setting up git send-email > can be with some providers when I wrote what you're replying to. The > replies > quite surprised me honestly because when I first set up git send-email, I > was using completely average providers and it was all pretty effortless, > I just adjusted git's config and it worked perfectly. > > > I don't really care about the quality between these tools. I think people > > are important. I only want to use it, and I can facilitate the real > > reviewer of Review. > > > > I don't know if I can say my personal feelings here, but I will say: > > > > I feel despised by this passage, which makes me uncomfortable. If you > are a > > reviewer, maybe I have no chance to contribute, but anyway, I have made > > some contributions. > > > > > How can anyone use git, but not git send-email? Any decent email > provider > > > has support for external clients over SMTP. And I believe you *can* > > > > actually dictate that people don't attach patches -- if you have > control > > > over the mailing list software, you can set up a filter that rejects > such > > > emails and auto-replies with instructions on how to send them properly. > > I think I should have the right to contribute > Likewise. > > Regarding the part about rejecting patches as attachments, I was > specifically > reacting to Rémi claiming that he can't dictate that people don't use them, > which technically he can. I never said it's a good idea, though it might > have > sounded that way. Sorry about that. > > As I said multiple times, I feel like contributing over email is a lot > about > having good tooling. For example, the email client I use treats all parts > of > a multipart message the same, so it has no issues replying to text > attachments > instead of the message body. As such, there is no difference between > attached > patches and patches in the message body with such a client. > Is it me or has this thread and topic run its course? We understand your preference is email and it is duly noted, the overwhelming majority of the community still seem to prefer github/gitlab. Any further discussion at this point looks off topic, there are better venues for discussing the technical merits of email vs github/gitlab. -- 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] 5 year plan & Inovation
On Thu, May 2, 2024 at 10:35 AM Ondřej Fiala wrote:
> On Thu May 2, 2024 at 4:20 PM CEST, Kieran Kunhya wrote:
> > > [...]
> > I feel it's a huge selection bias to have arguments about Gitlab vs
> Mailing
> > list handled on a mailing list.
> >
> > [...]
> You will get similar selection bias anywhere else. Even if you handled
> such a conversation on a discussion site, the technology powering such
> site will influence what kind of people use it. While discussing this
> here likely excludes people who don't know how to use a mailing list,
> having such a debate on Reddit, for example, would exclude people who
> don't use social media (anyone valuing their privacy and mental health),
> etc. IMHO there is no way to avoid that.
>
I think the point is not where the bias is, but how to facilitate new blood
in ffmpeg. While mailing list reviews may work well for you, there are
hundreds of developers that won't even get close to FFmpeg because they
cannot use git{lab,hub}, regardless of the pros or cons of email.
I believe the path forward would be designing a system that can accommodate
both workflows, a main git{hub,lab} interface which can send and mirror the
discussion happening on the mailing list for those who prefer emails. Such
a project would be another good use of SPI funds.
--
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] 5 year plan & Inovation
On Sat, Apr 27, 2024 at 6:24 AM Michael Niedermayer wrote: > On Thu, Apr 25, 2024 at 08:15:27AM -0700, Vittorio Giovara wrote: > > On Wed, Apr 24, 2024 at 3:00 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > > Microsoft expanded into new fields with Xbox and Azure, yes. But > Windows > > > is still an OS, and Office is still a (un)productivity suite. > > > > > > > > Accordingly, maybe you can innovate with a new project within the > same > > > legal entity as FFmpeg (be it SPI, FFlabs or whatever). > > > > > > > > But FFmpeg as a software project is not a suitable venue for radical > new > > > innovation. > > > > > > Microsofts OS does not limit what can be installed to whats in MS main > > > repository, FFmpeg does > > > > > > Microsoft windows from a user POV includes internet explorer IIRC. Its > not > > > a seperate > > > product from just the legal entity. It was not in the first OS from > > > microsoft > > > > > > microsofts first OS MS-DOS 1.0 ? looks slightly different than the > current > > > latest OS. > > > There was radical innovation, if one likes MS or hate them. > > > > > > > > > > > > > > >You can do the same with apple, google, or others. > > > > > > > > Sure but you can't do the same with iPhone or Google Search. > > > > > > of course you can, googles search inovated. Theres a image search a > audio > > > search > > > news, travel, shoping. > > > These did not exist in the initial google search. And while i dont > know, i > > > suspect > > > google search is very good at finding google products. > > > Google didnt became that big by simply "not being evil" > > > > > > But lets not assume, lets try, if i search for maps i get > > > Google Maps as first entry. > > > > > > or finance, 2nd entry is https://www.google.com/finance/ > > > > > > > > > And the iphone uses apples operating system and their app store, with > > > many apple apps. Check the first iphone and compare it to the latest > > > there is huge inovation with what you can do with all the software > > > that comes preinstalled and also what you can install later. > > > Thats in stark contrast to > > > "FFmpeg as a software project is not a suitable venue for radical new > > > innovation" > > > when did you last use siri with your iphone ? siri was added in > > > iphone 4s IIUC. Thats a big change. > > > > > > I can ultimately only repeat my oppinion. FFmpeg will innovate or > FFmpeg > > > will stagnate and eventually be replaced by some other project that > doesnt > > > have an opposition to innovation. > > > > > > IMHO we need to find out what direction (of innovation or lack thereof) > > > people want. This RFC thread is kind of the first step. > > > 2nd step would be a vote. > > > > > > You are kinda comparing apples and oranges, a platform like an OS or a > > The examples i showed cover a wide range of software (An OS, A office > suite, > A web browser, an AI assitent, a search engine, web apps, and more) > and hardware like a phone, services like cloud > > For all of them its true that radical innovation was essential for success. > > our multimedia framework is not a special case relative to above > > > > network or a crypto exchange or a browser based on ffmpeg.exe, and not > > because it's impossible but > > These sound like really bad ideas unrealated to innovation. > > > > because it's the wrong tool for the job - > > IMHO, this is missing the point a bit > > A phone originally was a tool to call and talk to someone, to be reachable > by > voice communication. > Its not a tool to write letters, until it was > Its not a tool to browse the internet until it was > Its not an assitent you could ask something until it was > ... > > A internet browser originally was a tool to display static text and images > maybe some ftp and gopher sprinkled into it. > its not a tool to do video chat with , until it was > its not a tool to write mails in, until it was > its not a tool to submit your patches to git, until it was, ohh wait, i > have a deja vue feeling here > > (and you can continue this list with software, hardware and services from > other > successfull companies, there is radical innovation everywhere) > > our repository is also
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Wed, Apr 24, 2024 at 3:00 PM Michael Niedermayer wrote: > > Microsoft expanded into new fields with Xbox and Azure, yes. But Windows > is still an OS, and Office is still a (un)productivity suite. > > > > Accordingly, maybe you can innovate with a new project within the same > legal entity as FFmpeg (be it SPI, FFlabs or whatever). > > > > But FFmpeg as a software project is not a suitable venue for radical new > innovation. > > Microsofts OS does not limit what can be installed to whats in MS main > repository, FFmpeg does > > Microsoft windows from a user POV includes internet explorer IIRC. Its not > a seperate > product from just the legal entity. It was not in the first OS from > microsoft > > microsofts first OS MS-DOS 1.0 ? looks slightly different than the current > latest OS. > There was radical innovation, if one likes MS or hate them. > > > > > > >You can do the same with apple, google, or others. > > > > Sure but you can't do the same with iPhone or Google Search. > > of course you can, googles search inovated. Theres a image search a audio > search > news, travel, shoping. > These did not exist in the initial google search. And while i dont know, i > suspect > google search is very good at finding google products. > Google didnt became that big by simply "not being evil" > > But lets not assume, lets try, if i search for maps i get > Google Maps as first entry. > > or finance, 2nd entry is https://www.google.com/finance/ > > > And the iphone uses apples operating system and their app store, with > many apple apps. Check the first iphone and compare it to the latest > there is huge inovation with what you can do with all the software > that comes preinstalled and also what you can install later. > Thats in stark contrast to > "FFmpeg as a software project is not a suitable venue for radical new > innovation" > when did you last use siri with your iphone ? siri was added in > iphone 4s IIUC. Thats a big change. > > I can ultimately only repeat my oppinion. FFmpeg will innovate or FFmpeg > will stagnate and eventually be replaced by some other project that doesnt > have an opposition to innovation. > > IMHO we need to find out what direction (of innovation or lack thereof) > people want. This RFC thread is kind of the first step. > 2nd step would be a vote. You are kinda comparing apples and oranges, a platform like an OS or a service like google Maps are different products than the software that runs them like FFmpeg. While for sure there can be innovation and radical new design ideas in our project, the space for innovation is limited by the intrinsic nature of the software, which is basically "multimedia in/multimedia out". In other words you cannot make something like a social network or a crypto exchange or a browser based on ffmpeg.exe, and not because it's impossible but because it's the wrong tool for the job - likewise you can't make internet explorer a good multimedia low level framework - there are other places to innovate with more freedom and fewer requirements. Most of the innovations I see the community ask for our project are mostly non-technical, aka switching to a more user friendly patch system, have stronger meaningful actions from the CC, and secure funding for larger projects. These are all hard to do, even more so when the leadership stalls any action out of fear of losing contributors. I hope we can find a good compromise in the upcoming months. -- 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] lavu/opt: Clarify that AVOptions is not indended for general use
On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers wrote: > The hypothetical me wants not to throw away a week's work > because he did everything through AVOptions then came across some edge case > that doesn't fit into the AVOptions model. Out of curiosity, what are those edge cases? -- 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] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > wrote: > > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > > dcni...@gmail.com> > > 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. > > > > The CC does not have authority to permanently ban people. See ( > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > remove privileges of offending members, including [..] temporary ban from > the community. [..] Indefinite bans from the community must be confirmed by > the General Assembly, in a majority vote." > > Enough of us have access to the ML admin interface to assume this will not > be an issue. > Thanks for the clarification, it's good to know. So correct me if I'm wrong, the theoretical banning process is that a repeated offender is reported enough times, the CC notices that the temporary bans have had no effects and decides to invoke the GA to confirm a ban? -- 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] 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".
