[FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Jean-Baptiste Kempf]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Tomas Härdin]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Jean-Baptiste Kempf]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1560 bytes --]

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.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Derek Buitenhuis]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 960 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[James Almer]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 916 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Ronald S. Bultje]

Hi,

On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer <michael@niedermayer.cc>
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Vittorio Giovara]

On Fri, Sep 8, 2023 at 11:22 AM Ronald S. Bultje <rsbultje@gmail.com> wrote:

> Hi,
>
> On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer <michael@niedermayer.cc
> >
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Rémi Denis-Courmont]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3970 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 8, 2023, at 6:09 AM, Michael Niedermayer <michael@niedermayer.cc> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Kieran Kunhya]

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 <michael@niedermayer.cc>
> 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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Tomas Härdin]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3279 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Tomas Härdin]

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2827 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1429 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".