Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Sat, Sep 09, 2023 at 09:23:35PM +0200, Tomas Härdin wrote: > lör 2023-09-09 klockan 15:53 +0200 skrev Michael Niedermayer: > > On Sat, Sep 09, 2023 at 09:04:25AM +0200, Tomas Härdin wrote: > > > fre 2023-09-08 klockan 15:09 +0200 skrev Michael Niedermayer: > > [...] > > > > > > AI based filters are neglegted at a time everything is shifting > > > > to neural networks and AI. > > > > > > Good. AI is a meme. Polynomial regression is just as good. > > > > Theres a lot i could reply but lets pick 2 choices > > 1. FFmpeg is about data compression so lets look at compression > > ill make it easy, just a "toy" project from fabrice, beat this with > > Polynomial regression > > https://bellard.org/ts_server/ts_zip.html > > I have actually had something like this in mind. Also better predictors > for intra compression. > > > 2. lets just ask AI, and while we can argue about this, i REALLY like > > to see > > your Polynomial regression producing anything that resembles english > > text > > heres chat gpts reply, first attempt: > > I'm not sure what that wall of text is supposed to accomplish, a Markov > chain can produce similar output. It's just mystified statistics, or > machine laundered labour. Or AI voodoo as I've heard it referred to. > See the paper "Polynomial Regression as an Alternative to Neural Nets" > by Cheng et al Well, 20 years ago i had a similar oppinion, NN are just a inefficient way to approximate statistics. But i changed my mind when artificial neural networks started to outperform classical statistics. I see no voodoo and no mystified statistics. What i do see is that the structures and algorithms have advanced quite a bit while for some reason its still called a "neural network". But the name used is meaningless, isnt it? The paper you quote talks about neural networks as they where 25 years ago. The field has advanced rapidly in recent years. I dont know where it will go from here. maybe we move to algorithms that can no longer be called neural networks even with one trying hard. Or maybe it will continue with things resembling neural networks. To me this makes no difference. I just find the technology cool If you dont see the difference between modern networks and this paper, i suggest you look at teh paper "Attention Is All You Need" this is the foundation to systems like GPT. And while one surely can cast anything into a frame work of additions and multiplcations or NAND gates. That doesnt capture the structure in a usefull way. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
lör 2023-09-09 klockan 15:53 +0200 skrev Michael Niedermayer: > On Sat, Sep 09, 2023 at 09:04:25AM +0200, Tomas Härdin wrote: > > fre 2023-09-08 klockan 15:09 +0200 skrev Michael Niedermayer: > [...] > > > > AI based filters are neglegted at a time everything is shifting > > > to neural networks and AI. > > > > Good. AI is a meme. Polynomial regression is just as good. > > Theres a lot i could reply but lets pick 2 choices > 1. FFmpeg is about data compression so lets look at compression > ill make it easy, just a "toy" project from fabrice, beat this with > Polynomial regression > https://bellard.org/ts_server/ts_zip.html I have actually had something like this in mind. Also better predictors for intra compression. > 2. lets just ask AI, and while we can argue about this, i REALLY like > to see > your Polynomial regression producing anything that resembles english > text > heres chat gpts reply, first attempt: I'm not sure what that wall of text is supposed to accomplish, a Markov chain can produce similar output. It's just mystified statistics, or machine laundered labour. Or AI voodoo as I've heard it referred to. See the paper "Polynomial Regression as an Alternative to Neural Nets" by Cheng et al The main thing is that "AI" gets grant money whereas "polynomial regression" does not. The former is deliberately mystified, the latter is perfectly understood. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 8, 2023 at 11:22 AM Ronald S. Bultje wrote: > Hi, > > On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer > > wrote: > > > On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: > > [...] > > > Propose a talk, from 5min to 30min. > > > > As i will not be at the conference, here are some quick words > > > > I really think you should reconsider this position. It would be extremely > valuable if you could attend, even just for one day or part of a day. > > We are not scary or creepy and will not do bad things to you (or anyone). > Please join us. You can skip dinner/drinks if that's not your thing. But > please attend the technical discussion. > +1 you should come Micheal, your feedback would be very much appreciated -- 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] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 08, 2023 at 03:09:49PM +0200, Michael Niedermayer wrote: > On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: > [...] > > Propose a talk, from 5min to 30min. [...] > Clientside / "in browser" also has become very important but > is absent from our documentation, our fate tests, and so on Slight elaboration on what i had in mind here as one (of several) things that should become possible if we look at something like pyodide, which allows us to simply run python code client side from a html file The example on pyodide.org is 21 lines for a complete html file and works as it is with just a default apache no changes on the server, no building, no installing of anything just one script link to pyodide.js is added The same should be possible with FFmpeg. We could be hosting a FFmpeg wasm js thingy (build from latest FFmpeg and specific FFmpeg versions) and anyone could just link to that and then run ffmpeg commands and call public libav* functions from within any clientside/ in browser scripts wasm and js is not my area of experties currently so its unlikely i will work on this, i just think its something we should do. Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 08, 2023 at 06:42:49PM +0300, Rémi Denis-Courmont wrote: > Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit : [...] > > Should decissions in FFmpeg be made to maximize benefit / be optimal for > > FFmpeg ? > > How do you define benefit for FFmpeg? This is real life, not an RPG. We can't > simply do linear optimisation to find out what the right choices are. With > that > said, everybody will agree with that vague phrasing to maximise benefit to > FFmpeg, and yet nobody will agree what that means and this won't change > anything. I think i really only meant the part "everybody will agree with", i dont think the exact definition is that important. Because i think something "good" will be good under most definitions that optimize something tangible But for sake of academic argument, we could consider more specific definitions like: "maximise the time and money people safe" so if you fork planet earth and one has one kind of FFmpeg and the other has another which side on average safes people more money and time from this, optimization follows, bit also bug freeness and also being maintainable and clean and well structured because otherwise code just becomes shitty and so does user experience ... > > You really need to make more concrete suggestions on this particular point > (and the rest of the email touches different issues, IMO). > > > There has been a marked shift of project goals over the years. While long > > ago FFmpeg was "all of multimedia". With time the scope of the project has > > shrunk. > > AFAICT it is rather that FFmpeg failed to capture the bits of multimedia that > its reverse dependencies had already implemented decently well first - audio > and video outputs, and user interfaces, being the obvious elephants in the > room. I don't think FFmpeg should waste time trying to reinvent SDL and > Placebo at this point, even less a web browser. i do think libplacebo functionality belongs in and is needed inside FFmpeg. > > Also FFmpeg *did* expand into filtering with some success. > > And now would probably be a good time to expand into WASM platform support > (especially SIMD). yes > > > FFserver was removed not improved, not replaced. > > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, > > rv* and others and at the time was the best encoder available (not anymore > > now, no) but after mpeg4-asp, modern video encoders where no longer added > > to ffmpeg. In one case a advanced encoder for a fringe format was rejected. > > AI based filters are neglegted at a time everything is shifting to neural > > networks and AI. Clientside / "in browser" also has become very important > > but is absent from our documentation, our fate tests, and so on > > This is more of a question of whether FFmpeg should have subpar > implementations vs no implementations. I think theres not one awnser that fits all cases here. Having a simple and clean implementation thats good enough can be usefull especially for areas where the "goodness" doesnt matter much and things require no real maintaince OTOH an implementation thats not "good enough" is bad I mean if for a fringe game format we had an encoder thats 5 pages of C code and achives 95% of the compression of the best. And the 100% one would be 1000 pages of code in an external lib. Id say the 5 page encoder is good enough to include and support. OTOH 95% compression of the best for a major format like h264 i think is not good enough and we should not do that. All this of course is subjective thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 08, 2023 at 03:53:59PM +0100, Derek Buitenhuis wrote: > On 9/8/2023 2:09 PM, Michael Niedermayer wrote: > > Whats the scope of FFmpeg ? > > And is this direction that is taken optimal for FFmpeg, and what people > > want ? > > Not that I don't think this is an issue worth discussing (it is), but I > thought it > was important to note that most/many of the people who hold strong opinions > on this > are also people who will not meet IRL, or on calls, or even IRC for some. > > So, any in person discussion will be biased in on direction. > > I do not have an easy solution, but I thought it was important to note. i 100% agree -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Sat, Sep 09, 2023 at 09:04:25AM +0200, Tomas Härdin wrote: > fre 2023-09-08 klockan 15:09 +0200 skrev Michael Niedermayer: [...] > > AI based filters are neglegted at a time everything is shifting > > to neural networks and AI. > > Good. AI is a meme. Polynomial regression is just as good. Theres a lot i could reply but lets pick 2 choices 1. FFmpeg is about data compression so lets look at compression ill make it easy, just a "toy" project from fabrice, beat this with Polynomial regression https://bellard.org/ts_server/ts_zip.html 2. lets just ask AI, and while we can argue about this, i REALLY like to see your Polynomial regression producing anything that resembles english text heres chat gpts reply, first attempt: If someone were to say, "Good. AI is a meme. Polynomial regression is just as good," I would respond with the following points: AI is not a meme: Artificial Intelligence (AI) is a field of computer science that focuses on creating systems and machines capable of performing tasks that typically require human intelligence, such as problem-solving, learning, and decision-making. AI has made significant advancements in various domains, including machine learning, natural language processing, computer vision, and robotics. It is a legitimate and impactful field of research and application. Polynomial regression vs. AI: Polynomial regression is a specific machine learning technique used for modeling relationships between variables. While polynomial regression can be effective in certain situations, it has limitations compared to AI and other machine learning approaches. AI encompasses a wide range of techniques and algorithms, including deep learning, reinforcement learning, and neural networks, which can handle complex and high-dimensional data and perform tasks that go beyond what polynomial regression can achieve. Applicability: The choice between AI and polynomial regression depends on the problem at hand. Polynomial regression is suitable for problems where a simple polynomial equation can accurately represent the data's underlying patterns. However, AI is more versatile and can tackle tasks like image recognition, language translation, autonomous driving, and more, where the relationships are highly non-linear and complex. Evolution of AI: AI has evolved significantly over the years, leading to breakthroughs in various domains, including healthcare, finance, entertainment, and scientific research. It has the potential to bring about transformative changes in society, whereas polynomial regression is just one tool within the broader AI toolkit. In summary, while polynomial regression can be a useful tool in certain contexts, it is not a replacement for AI. AI is a diverse and rapidly advancing field with a wide range of applications and techniques that go far beyond simple regression models. Both AI and polynomial regression have their places in data analysis, but they serve different purposes and should not be considered interchangeable. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
fre 2023-09-08 klockan 15:09 +0200 skrev Michael Niedermayer: > the video encoder core we had, which encoded from mpeg1 to mpeg4, > msmpeg*, rv* and others > and at the time was the best encoder available (not anymore now, no) > but after mpeg4-asp, > modern video encoders where no longer added to ffmpeg. We can't really control if people prefer to develop encoders outside of FFmpeg as James says, and such projects would be free to pick their own development process. There's also no need to fetishistically implement subpar encoders either, since that splits encoder developer resources. Just let packagers enable the glue for these external encoders and our job is done. > AI based filters are neglegted at a time everything is shifting > to neural networks and AI. Good. AI is a meme. Polynomial regression is just as good. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 08, 2023 at 12:19:45PM -0300, James Almer wrote: > On 9/8/2023 10:09 AM, Michael Niedermayer wrote: > > There has been a marked shift of project goals over the years. While long > > ago FFmpeg > > was "all of multimedia". With time the scope of the project has shrunk. > > FFserver was removed not improved, not replaced. > > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, > > rv* and others > > and at the time was the best encoder available (not anymore now, no) but > > after mpeg4-asp, > > modern video encoders where no longer added to ffmpeg. In one case a > > advanced encoder for a fringe > > format was rejected > > Which encoder was this? I would have said it, if i remembered it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, 8 Sept 2023 at 18:39, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Sep 8, 2023, at 6:09 AM, Michael Niedermayer > wrote: > > > > modern video encoders where no longer added to ffmpeg > > Writing a good modern video encoder is a massive undertaking, and i think > it's likely that encoders are going to be mostly integrated via libraries. > I agree the speed of iteration needed in developing a modern video encoder does not lend itself to 1) the FFmpeg development process on a mailing list and 2) rapid iteration whilst fitting into FFmpeg libs (e.g threading) I will deliberately avoid commenting on the other points. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
> On Sep 8, 2023, at 6:09 AM, Michael Niedermayer > wrote: > > modern video encoders where no longer added to ffmpeg Writing a good modern video encoder is a massive undertaking, and i think it's likely that encoders are going to be mostly integrated via libraries. Along those lines though, one pattern that's becoming more popular particularly recently integrated encoder libraries is to move options into an opaque key-value string that's passed to the encoder library. For example svtav1-params. This makes sense because the parameters are frequently changing with new versions and it's hard to keep that in sync. However it gives up the self-documentation when running ffmpeg -h encoder=libsvtav1 for example. It would be nice if there were some facilities for encoders to expose their parameters to ffmpeg including min/max or value list, the default value and a description such that running -h can show a useful help message. This would also allow ffmpeg to validate the parameters and possibly expose the options as proper -flags rather than requiring jamming them through a string blob. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit : > In the past, most developers in FFmpeg where primarly FFmpeg developers. But > as FFmpeg is used by almost everyone now, that has changed and many > developers in FFmpeg today are primarly developer of 3rd party projects > using FFmpeg. What does that even mean, really? FFmpeg is and has practically always been first and foremost a library. It is only natural that people involved will also be involved with one or several reverse dependencies. Already twenty years ago, the FFmpeg developer body was supposedly heavily overlapping with MPlayer's... I would understand that sort of argument for projects that are mostly ad-hoc programs, and also happen to provide libraries, such as LLVM (incl. Clang) or VLC but FFmpeg, not so much. Also FWIW, while I have probably contributed to FFmpeg more in the past 12 months than in the 19 years prior, my first patch merged in FFmpeg goes way back over 10 years ago. And conversely, while I am often associated with VLC, the reality is that I have barely written any merged code in VLC in the past couple years. > Should decissions in FFmpeg be made to maximize benefit / be optimal for > FFmpeg ? How do you define benefit for FFmpeg? This is real life, not an RPG. We can't simply do linear optimisation to find out what the right choices are. With that said, everybody will agree with that vague phrasing to maximise benefit to FFmpeg, and yet nobody will agree what that means and this won't change anything. You really need to make more concrete suggestions on this particular point (and the rest of the email touches different issues, IMO). > There has been a marked shift of project goals over the years. While long > ago FFmpeg was "all of multimedia". With time the scope of the project has > shrunk. AFAICT it is rather that FFmpeg failed to capture the bits of multimedia that its reverse dependencies had already implemented decently well first - audio and video outputs, and user interfaces, being the obvious elephants in the room. I don't think FFmpeg should waste time trying to reinvent SDL and Placebo at this point, even less a web browser. Also FFmpeg *did* expand into filtering with some success. And now would probably be a good time to expand into WASM platform support (especially SIMD). > FFserver was removed not improved, not replaced. > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, > rv* and others and at the time was the best encoder available (not anymore > now, no) but after mpeg4-asp, modern video encoders where no longer added > to ffmpeg. In one case a advanced encoder for a fringe format was rejected. > AI based filters are neglegted at a time everything is shifting to neural > networks and AI. Clientside / "in browser" also has become very important > but is absent from our documentation, our fate tests, and so on This is more of a question of whether FFmpeg should have subpar implementations vs no implementations. But as much as many (including myself) will agree that it is better to implement stuff in FFmpeg than add new dependencies to it. Yet it's all cheap talk unless somebody actually does the work. As a counter example, I certainly won't be implementing EVC or VVC in FFmpeg myself, and even the HEVC implementation leaves to be desired according to many. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
Hi, On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer wrote: > On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: > [...] > > Propose a talk, from 5min to 30min. > > As i will not be at the conference, here are some quick words > I really think you should reconsider this position. It would be extremely valuable if you could attend, even just for one day or part of a day. We are not scary or creepy and will not do bad things to you (or anyone). Please join us. You can skip dinner/drinks if that's not your thing. But please attend the technical discussion. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On 9/8/2023 10:09 AM, Michael Niedermayer wrote: There has been a marked shift of project goals over the years. While long ago FFmpeg was "all of multimedia". With time the scope of the project has shrunk. FFserver was removed not improved, not replaced. the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, rv* and others and at the time was the best encoder available (not anymore now, no) but after mpeg4-asp, modern video encoders where no longer added to ffmpeg. In one case a advanced encoder for a fringe format was rejected Which encoder was this? Also, people not submitting encoders is beyond our power and has been the case for more than a decade. All important video codecs past mpeg2 (H.264/5, VP8/9, AV1, etc) have never gotten an encoder in lavc. What i would worry the most about is decoders being written in external libs and glued into lavc. Fortunately VVC is not going that way, but others have and still are. AI based filters are neglegted at a time everything is shifting to neural networks and AI. Clientside / "in browser" also has become very important but is absent from our documentation, our fate tests, and so on If there's something that's 100% corporate interest and not a project from multimedia hobbyists, it's AI. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On 9/8/2023 2:09 PM, Michael Niedermayer wrote: > Whats the scope of FFmpeg ? > And is this direction that is taken optimal for FFmpeg, and what people want ? Not that I don't think this is an issue worth discussing (it is), but I thought it was important to note that most/many of the people who hold strong opinions on this are also people who will not meet IRL, or on calls, or even IRC for some. So, any in person discussion will be biased in on direction. I do not have an easy solution, but I thought it was important to note. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: [...] > Propose a talk, from 5min to 30min. As i will not be at the conference, here are some quick words In the past, most developers in FFmpeg where primarly FFmpeg developers. But as FFmpeg is used by almost everyone now, that has changed and many developers in FFmpeg today are primarly developer of 3rd party projects using FFmpeg. Should decissions in FFmpeg be made to maximize benefit / be optimal for FFmpeg ? There has been a marked shift of project goals over the years. While long ago FFmpeg was "all of multimedia". With time the scope of the project has shrunk. FFserver was removed not improved, not replaced. the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, rv* and others and at the time was the best encoder available (not anymore now, no) but after mpeg4-asp, modern video encoders where no longer added to ffmpeg. In one case a advanced encoder for a fringe format was rejected. AI based filters are neglegted at a time everything is shifting to neural networks and AI. Clientside / "in browser" also has become very important but is absent from our documentation, our fate tests, and so on Whats the scope of FFmpeg ? And is this direction that is taken optimal for FFmpeg, and what people want ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Sun, 20 Aug 2023, at 15:01, Tomas Härdin wrote: > Will it be possible to attend via Jitsi Meet or similar? For the FFmpeg meeting, of course. For the rest, I dunno yet. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
Will it be possible to attend via Jitsi Meet or similar? /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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] VDD conference invitation - Dublin 22-24 Sept 2023
Hello FFfolks, I'm glad to invite you to VDD 2023 in Dublin, at the end of next month. I wish I could have invited you to Iceland, but it proved too difficult to organize over there. I'll do better next year, I promise :) What is it? --- The format of the conference is going to be similar to the previous years: - Friday 22nd, community day in Dublin, where we'll do some activities (will be communicated later) and then drinks on the evening - Saturday 23rd, start of the actual conferences, with talks by members from our communities on very technical subjects, in the morning, until lunch. - Saturday afternoon, technical sessions (VLC and FFmpeg in // probably) in an unconference manner. - Saturday night, a dinner in Dublin. - Sunday morning, lightning talks, for the early people - Sunday morning and afternoon, workshops and technical sessions (x264, dav1d, VLC mobile, placebo...) We will be at Trinity College, in Dublin. Who is welcome to join? --- Everyone that cares about any open source multimedia project, VLC, FFmpeg, x264, dav1d, placebo, mpv, kodi, phonon, x265... is welcome. If you are a GSoC student, you should also come. If you are just a fan and a user, you shall probably come. How do I register? -- You can register here: https://framaforms.org/vdd-2023-1691924544 Registration will close at the end of this month. How do I get reimbursed? -- If you are an active member of one of our open source communities, VideoLAN will cover your costs, meaning Hotels + Flight/Train/Boat to Dublin. If you are part of the VideoLAN non-profit, if you are part of the FFmpeg GA, you are invited. If you have commits on git.ffmpeg.org or code.videolan.org, you are invited. If you are a GSoC student, your costs will be covered too. If you are unsure about if you are eligible, you should mail me... What should I do now? - 1. Register 2. Book your flights. 3. Help us. For your flights, please try and find flights that are not too expensive, if VideoLAN cover your costs. We have no sponsors this year, so be mindful about our costs. (Today flights from Berlin can be found easily at 100-150e, and 200e from Paris. Coming from SF can be found at 800e) How can I help? --- Propose a talk, from 5min to 30min. Help the organisation. Bring smile and join to VDD. Questions? For any question, please mail me :) Thanks and see you soon. jbk Remarks: - this is a technical conference. If you are not a technical person, this will probably bore you. - VideoLAN CoC applies to VDD. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
