Re: [FFmpeg-devel] Project orientation

[赵娟]

On Sun, Jul 5, 2020 at 5:26 AM Jean-Baptiste Kempf  wrote:

> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
> > Another area as we are already on the subject is stuff falling a little
> > outside what FFmpeg covers.
> > Not every filter that anyone wants to write should have to be in FFmpeg
>
> Thank $deity that you are saying this!
>
> FFmpeg is used more and more and numerous people want to put everything in
> it.
>
> The project needs to learn to say no to features and define the scope of
> each library.
>
> For libavcodec, the scope is quite clear, even if there are some debates
> about experimental codecs.
>
> But for the other libraries, including avformat and avfilter, there are
> dubious things in.
>
> For example and in my opinion, I don't see why there is support in
> avformat for things that are not standards, like AMQP/ZMQ, who are neither
> a multimedia format nor a multimedia protocol.
> In the same way, if you start to need tensorflow or openvinno for a
> filter, the code has no place in FFmpeg: you can use the api and use that
> externally. Importing tensorflow is probably more lines of code, than
> FFMpeg.
> Or speech-recognition (sphinx) or OCR (tesseract)...
> And now comes the debate with synthesizers or complex filters that are
> almost reinventing GStreamer inside libavfilter ("let's use libavcodec as a
> filter, since everything is a filter")...
>
> When you look at the FFmpeg dependency graph on distributions like Debian,
> this is getting scrary, and this increases a lot the binary size and
> resources usage.
>
> At some point, the project needs to decide what is in and what is out, and
> since FFmpeg has numerous APIs, people can plug them externally. It's not a
> problem to say "No" to a feature, especially when, the number of people
> using that feature is under 0,01% of FFmpeg users, and when people can
> build that externally anyway.
>

It's a good point, looking forward to the "plugin" mechanism.
Frankly speaking, some of the filters don't have to be upstreamed to
FFmpeg, but cloud service providers are using FFmpeg to build the media
pipeline. So the filters may receive some requirements to provide the
functionality through FFmpeg.
If developers can provide a standalone plugin to FFmpeg, and host them by
their own, that's something good, and reduce the complexity of FFmpeg.
But for now, developers can only maintain a patchset which may not be able
to upstream for many reasons.

Thanks,
Juan


>
>
> --
> 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Kieran O Leary (12020-07-10):
> Same here, been using email to reply to github issues and pull requests
> over the years. The only things i have to watch out for are:
> * People can edit their post in a github issue, so the email version you
> receive may be outdated as it could be updated on github itself. Perhaps
> there's a setting for getting email notifications about updates.

Updates seems like a terrible idea in the first place for this kind of
thing. They are a recipe for misunderstandings: somebody will have read
the original version and not noticed the update, somebody else will have
read the updated version and not be aware of the original.

The correct way to mark an update in a discussion is to say "I changed
my mind".

Can updates be disabled?

> * I usually need to delete the full email quote before replying, as it just
> looks ugly and weird on the web client.

It is a good thing to do for normal mail too. I hope people have noticed
how much more pleasant to read are the mails from those of us who do
always trim our mails than the mails that are not trimmed.

Regards,

-- 
  Nicolas George


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] Project orientation

[Kieran O Leary]

Hi,

On Thu, Jul 9, 2020 at 1:56 AM Manolis Stamatogiannakis 
wrote:

> On Tue, 7 Jul 2020 at 16:27, Nicolas George  wrote:
>
> > Manolis Stamatogiannakis (12020-07-07):
> > > If I reply to the email, my response will appear online in the issue/PR
> > > page.
> >
> > That is good to know. I have never noticed it documented. Does it work
> > reliably?
> >
> >
> Haven't noticed any glitches so far.
>

Same here, been using email to reply to github issues and pull requests
over the years. The only things i have to watch out for are:
* People can edit their post in a github issue, so the email version you
receive may be outdated as it could be updated on github itself. Perhaps
there's a setting for getting email notifications about updates.
* I usually need to delete the full email quote before replying, as it just
looks ugly and weird on the web client.

-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] Project orientation

[Manolis Stamatogiannakis]

Thanks Gerion.

This sounds more or less like what I had in mind (but I was trying to keep
it short).

– The present thread is a non-technical discussion, and branching indeed
helps. The mailing list is perfect for this kind of discussions.
– Patches with narrow scope are focused, technical discussion, which is
unlikely to branch. They can be dispatched and discussed directly as a PR,
either via the web interface or email. This should keep this list more
focused.
– Patches that involve deeper changes can be discussed before materializing
in a PR, in whatever way core developers prefer.

To be clear, by no means I am in favour of deprecating the mailing list.
PRs and Issues are not a panacea. E.g. asking questions by opening issues
on GH/GL is something I would frown upon (and I have seen
happening elsewhere).

Best regards,
Manolis

On Thu, 9 Jul 2020 at 12:27, Gerion Entrup 
wrote:

> Hi,
>
> Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis
> Stamatogiannakis:
> > On Tue, 7 Jul 2020 at 16:27, Nicolas George  wrote:
> > > > Is tree threading that important? A PR is essentially a single
> thread of
> > > > discussion.
> > >
> > > It is a single thread of discussion until the discussion becomes
> complex
> > > and has branches.
> > >
> >
> > This doesn't sound like the common case.
> > But it should be straightforward to get some statistics on that from the
> > list archives when a transition is officially discussed.
>
> This whole current discussion here would be a lot more confusing without
> branches.
>
> Maybe you like the Gentoo approach: Do the majority of changes in pull
> requests, in Gentoo this are changes of packages, here it would be
> changes on codecs/demuxers/filters/etc. And then do all changes of the
> framework itself and discussions via mailinglist. In Gentoo this are
> changes of eclasses (i.e. code libraries for packages). For FFmpeg it
> would be the introduction of new API, API changes, decoupling or merging
> of libraries etc.
>
> The first is likely to produce no to little (conflicting) discussion,
> has a huge benefit from CI, is the part where most of the newcomers begin
> development and includes a lot of easy tasks. Here by far the most
> developments happens.
>
> The latter is likely to produce huge discussions, needs deep knowledge
> of the libraries, so it is not likely done by newcomers and has little
> gain from CI since it adds e.g. something completely new. Here happens
> not so much development in terms of frequency or code lines but the
> impact is much higher.
>
> Just a suggestion, since I follow both projects...
>
> Regards,
> Gerion
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Project orientation

[Gerion Entrup]

Hi,

Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis Stamatogiannakis:
> On Tue, 7 Jul 2020 at 16:27, Nicolas George  wrote:
> > > Is tree threading that important? A PR is essentially a single thread of
> > > discussion.
> >
> > It is a single thread of discussion until the discussion becomes complex
> > and has branches.
> >
> 
> This doesn't sound like the common case.
> But it should be straightforward to get some statistics on that from the
> list archives when a transition is officially discussed.

This whole current discussion here would be a lot more confusing without
branches.

Maybe you like the Gentoo approach: Do the majority of changes in pull
requests, in Gentoo this are changes of packages, here it would be
changes on codecs/demuxers/filters/etc. And then do all changes of the
framework itself and discussions via mailinglist. In Gentoo this are
changes of eclasses (i.e. code libraries for packages). For FFmpeg it
would be the introduction of new API, API changes, decoupling or merging
of libraries etc.

The first is likely to produce no to little (conflicting) discussion,
has a huge benefit from CI, is the part where most of the newcomers begin
development and includes a lot of easy tasks. Here by far the most
developments happens.

The latter is likely to produce huge discussions, needs deep knowledge
of the libraries, so it is not likely done by newcomers and has little
gain from CI since it adds e.g. something completely new. Here happens
not so much development in terms of frequency or code lines but the
impact is much higher.

Just a suggestion, since I follow both projects...

Regards,
Gerion



___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Manolis Stamatogiannakis]

On Tue, 7 Jul 2020 at 16:27, Nicolas George  wrote:

> Manolis Stamatogiannakis (12020-07-07):
> > If I reply to the email, my response will appear online in the issue/PR
> > page.
>
> That is good to know. I have never noticed it documented. Does it work
> reliably?
>
>
Haven't noticed any glitches so far.
I can help you test the feature if you want. Just make a dummy public
github repo and send me the details with email.



> > Now, if you also want to review the code of a PRs from mutt, that's
> another
> > discussion.
>
> Not necessarily mutt, but if it's a web browser, then find somebody else
> to review.
>

Code review on github is pretty nice, if you haven't tried it.



> > Is tree threading that important? A PR is essentially a single thread of
> > discussion.
>
> It is a single thread of discussion until the discussion becomes complex
> and has branches.
>

This doesn't sound like the common case.
But it should be straightforward to get some statistics on that from the
list archives when a transition is officially discussed.


>
> > I would first ask why keep using a mailing list to post patches and not
> use
> > PRs. For a 3 commit patch, and 3 people sending feedback a few days
> apart,
> > you have a minimum of 15 emails for everyone on the list. Is that
> efficient?
>
> Actually, since mail servers are much much less resource-consuming that
> web interfaces, it probably is.
>

Valuing hardware resources more than the time any of us volunteers is a
pretty unorthodox approach.
We are not living in the 60s. Hardware is cheap, programmers are expensive
[1].

[1]
https://blog.codinghorror.com/hardware-is-cheap-programmers-are-expensive/

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Moritz Barsnick]

On Tue, Jul 07, 2020 at 10:03:34 -0300, James Almer wrote:
> On 7/7/2020 8:33 AM, Steinar H. Gunderson wrote:
> > FWIW, the “less secure” part is about not supporting 2FA (POP/IMAP has no
> > OAuth-like authentication methods).
>
> This is not true. Thunderbird and i assume any modern IMAP/SMTP client
> supports Oauth (which triggers the 2FA Gmail offers), so it's not one of
> the "Less secure" applications Google warns you about.

I believe this is due to the fact that Thunderbird is a non-synamically
registered application:

https://hg.mozilla.org/comm-central/file/tip/mailnews/base/util/OAuth2Providers.jsm

> And for those applications, like git send-email, they introduced the
> "App passwords" that you can use to you login without Oauth and thus no
> 2FA prompt, without having to make any changes in security settings like
> it was years ago.

That's also the impression I had, that there's some shim to be used to
avoid compromising your account's security. I don't know how it plays
with git send-email though.

Instructions would be nice.

Moritz

(I see the discussions mutt is going through in trying to support XOAUTH2
with Microsoft. Not that I care. ;-))
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Jean-Baptiste Kempf]

On Tue, Jul 7, 2020, at 13:13, Anton Khirnov wrote:
> > But be very careful to not make them mandatory.
> 
> +1
> Any change that makes it necessary to use a web browser for development
> a big step back IMO.

Github has a quite nice CLI, so you don't need the web part for that.

Best,
-- 
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] Project orientation

[Jean-Baptiste Kempf]

On Tue, Jul 7, 2020, at 15:15, Nicolas George wrote:
> Jean-Baptiste Kempf (12020-07-05):
> > With tools and organization.
> 
> Sure, but you are forgetting one wing: responsibility.
> 
> The reason many patches go a long time without review is that nobody
> feels responsible for reviewing them.

I'm sorry, but I believe this is the downside of the MAINTAINERS file.
MAINTAINERS file explain to people that someone "owns" a part of the code, and 
therefore, there is no incentives for other people to understand that code.
Also, it de-responsibilizes people from reviewing the parts that are not the 
ones that they maintain.

And that happens because some people on the MAINTAINERS files are not active 
anymore.

--
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] Project orientation

[Andriy Gelman]

On Tue, 07. Jul 16:29, Oneric wrote:
> On Sun 2020 Jul 5 20:01 +0300 Kieran Kunhya  wrote:
> >
> > Going back to the original point in hand.
> > Many patches aren't getting reviewed and pushed any more.
> > 
> > In part this is because in 2020 whether we like it or not mailing
> > lists are not the way to do Git based development.
> > The kernel is the exception to the rule, as Linus says it has a whole
> > load of grey-bearded system maintainers who are paid full time to work
> > on it.
> >
> > For new contributors git send-email is annoying. For people wanting to
> > push, the .mbox format is annoying, Gmail doesn't support it any more.
> > And you can't get new contributors to start using CLI based email
> > clients or run their own mail server, that's not going to happen.
> > 
> > A solution like Gitlab is the only way forward. It has worked well for
> > dav1d, it can run regression tests on all platforms for all commits:
> > https://code.videolan.org/videolan/dav1d
> > 
> > Merges are done with one push of a button. Yes, the branch sprawl is
> > not great but it's better than now.
> > It has inline patch reviews which are nice.
> > 
> > Whether we like it or not web interfaces are the way 95% of the world
> > does Git and we have to move with the times.
> 
> As someone who recently only submitted a single, simple patch, I haven't seen 
> mail-based dev as an annoyance, rather the contrary as this avoids the burden 
> of creating yet another account on some website, that I'll have to manage.
> 
> There also already seems to be some automatic testing, as Patchwork send me 
> an 
> off-list mail about failing tests. (I did not set SAMPLES when running make 
> fate locally as it was not mentioned clearly on the main "Contribute" site on 
> the webpage. https://ffmpeg.org/developer.html .) It can probably be improved 
> though.
> 
> What was frustating however, was the lack of any form of response to the 
> patch 
> for over a month, despite ml-pings.

> On top of that the revised patch with updated FATE-samples had to change 
> files 
> with CRLF line endings that are not marked as such in .gitattributes. This 
> prompted patchwork to be unable to apply the patch. Even though this is the 
> only correct way to update these samples and left me concerned the patch 
> might 
> be being silently ignored because it fails on patchworks.

Thanks for reminding. This should now be fixed on patchwork.

-- 
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Jean-Baptiste Kempf (12020-07-05):
> Also in this example, noone is telling them to fork, just to use the
> API to register their custom protocol.

About this, I think there are two separate issues.

One is that recent effort to get rid of mutable global state.
Registering custom protocols involves modifying global state, and
therefore has been made impossible by efforts to be able to add "const"
whenever possible.

This issue is actually easy to solve. The patch about
avrefcount_template.h was actually the first step towards my solution to
it: to have potentially multiple mutable states, with protocols,
formats, codecs, filters lists. That way, we can bring back the dynamic
lists of components without the drawbacks we wanted to eliminate. And
there are a few extra benefits: no interference if different parts of a
huge application register different components; a more reliable way of
enabling only a few selected components (the systems of whitelist used
now is an afterthought, afterthoughts are terrible for security; and we
will have to rename them anyway).

It is a bit tricky, because it spans several libraries (this always
makes things harder), but I have solutions. If I can explain these
solutions to somebody in charge and have them pre-approved in general
principle, I can work on the code rather quickly. But if I code with the
risk of it getting bikeshedded to death immediately, it is debilitating.

So again: not a very hard issue, but requires something at the helm, to
decide the orientation of the project.

The other issue is much more burdensome.

If you remember, at the beginning of libavfilter, applications could
register custom filters. We ended up making it private to be able to
evolve it.

The problem is API stability. Changing an internal API is easy: just
change it, and fix all the build failure, or grep for all uses of the
function. Changing a public API is much more trouble.

Anton could probably never have achieved the change from AVBufferRef to
AVFrame in libavfilter if all the internal filtering APIs had been
public and required careful compatibility. Same for me reworking the
scheduling to make it by message instead of recursive.

There are partial solutions yet:

- The internal API have somewhat stabilized. Things that seemed a good
  idea at the time but were too complex have been eliminated. That will
  help.

- We can make the public API less powerful than the internal API. No
  direct rendering or other extra optimizations to avoid data copy. No
  fancy format negotiation. No access to ultra-optimized computation
  building blocks.

- We can make the public API less stable. I am serious, it is an
  entirely acceptable solution. These are just applications, not
  life-and-death situations, "do it at your own risk" is not worse than
  "don't do it". We can have headers that clearly indicate "if you use
  something from this header, we do not guarantee it will keep working,
  you will have to check if it still works after each update.

  And if people are not happy about lack of stability, they can come and
  help.

Regards,

-- 
  Nicolas George


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] Project orientation

[Nicolas George]

Manolis Stamatogiannakis (12020-07-07):
> And some quick grepping reveals that 45% of the emails in the list for
> 2019-2020 were from 236 unique Gmail addresses.
> That's an awful lot of people with bad habits to ignore.

Ah, but a gmail address is not the sign of bad habits. You can use a
gmail address with an IMAP and SMTP client. You can use a gmail address
without tying your entire life to it.

Who doesn't have a throw-away gmail address to order semi-legal drugs
online, anyway? ;-)

> I'm a command line veteran myself, with the same weapons of choice as you
> (vim/zsh), but I still struggle with the ffmpeg workflow. I'd surely be
> interested for any command line tools that would make it easier.
> 
> If you have the time to add a section to the documentation, I'm sure it
> would be helpful for many people. And there's also the "tools" directory
> for sharing any tools/scripts you created for ffmpeg development.

This is an interesting idea.

Yes, sharing tips and tricks to work more efficiently would be a good
idea.

Although, I must say, I do not think I have any tricks: all my uses are
pretty straightforward. The most I have is an init script that populates
my shell environment and history with useful commands.

Regards,

-- 
  Nicolas George


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] Project orientation

[Nicolas George]

Oneric (12020-07-07):
> As someone who recently only submitted a single, simple patch, I haven't seen 
> mail-based dev as an annoyance, rather the contrary as this avoids the burden 
> of creating yet another account on some website, that I'll have to manage.
> 
> There also already seems to be some automatic testing, as Patchwork send me 
> an 
> off-list mail about failing tests. (I did not set SAMPLES when running make 
> fate locally as it was not mentioned clearly on the main "Contribute" site on 
> the webpage. https://ffmpeg.org/developer.html .) It can probably be improved 
> though.

Thanks for this insight.

> What was frustating however, was the lack of any form of response to the 
> patch 
> for over a month, despite ml-pings.
> 
> In my experience the review activity of a project is independend of its 
> development workflow being mail or web based.

Would you agree with what I say there:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/265898.html
? i.e. that we would need to have rules to make sure somebody feels
responsible for reviewing patches?

> On top of that the revised patch with updated FATE-samples had to change 
> files 
> with CRLF line endings that are not marked as such in .gitattributes. This 
> prompted patchwork to be unable to apply the patch. Even though this is the 
> only correct way to update these samples and left me concerned the patch 
> might 
> be being silently ignored because it fails on patchworks.
> 

> I also feel compelled to point out, that a switch to a web-based interface 
> instead of plaintext emails can be a hurdle for devs with impaired vision, 
> who 
> might rely on customised mail interfaces, screen readers and/or braille 
> displays as a Web-page is more complicated in that regard (especially with 
> js).
> While I myself am fortunate enough to not needing to rely on such a setup, I 
> personally know devs (not working on ffmpeg afaik) that do.

And thanks for reminding us of that. It is an even stronger argument
that "I personally find web interface annoying", although they are both
caused by the same underlying reality: the need to be able to use the
tools of choice.

Regards,

-- 
  Nicolas George


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] Project orientation

[Manolis Stamatogiannakis]

On Tue, 7 Jul 2020 at 14:38, Nicolas George  wrote:

> Manolis Stamatogiannakis (12020-07-07):
> > I believe I have adequately explained that "less secure" needs to be
> > enabled, not to make your Google account more secure, but to contain
> > the damage from a potential compromise.
> >
> > Yes, "less secure" sounds a lot like marketing slang. But Gmail is not
> used
> > exclusively by CompSci majors :)
>
> I will state it another way.
>
> Anybody should be able to use the software of their choice to read their
> e-mail.
>
> If a compromise around these software have a consequence beyond mail and
> what is directly related to mail, then the fault is not the software's,
> the fault is to whoever tied mail and other things together.
>
> Google has a totalitarian policy, as in they want to totally control
> your web experience (the fact that the same word is used to qualify
> dictatorships is not a coincidence): they make every effort so that if
> you dip a toe in them, you find yourself submerged before you know it.
>
> It is Google's choice, and Google's responsibility, and your choice and
> your responsibility if you decide to use Google totally.
>
> This choice should not direct the workings of a Libre Software projects
> that is not under the control of Google. The choice should even less
> direct the choices of other people working on the project.
>
> As was pointed out earlier, there are solutions. Even if Google hides
> it, there are ways of accessing their walled gardens with other
> applications. Even if there are not, you can decide to isolate your
> accounts. (If would probably be a good idea irregardless of FFmpeg,
> anyway.)
>
> So learn to use them, and do not demand other people to change their
> (good) habits so that you can keep your (bad) habits.
>


I understand your concerns, but Google has been pretty open with all its
productivity SaaS offerings.
So, while I would be against mandating the use of any Google products, I
can't see catering for Gmail users as a valid existential threat to any
open/libre project.

And some quick grepping reveals that 45% of the emails in the list for
2019-2020 were from 236 unique Gmail addresses.
That's an awful lot of people with bad habits to ignore.



> I would offer my help in doing so, but as I explained, I do not use
> Google, and therefore have no help to offer to better use it. But if you
> want my help in learning powerful command-line tools, you can have it.
> (And it would probably be a good investment of your time.)
>
>
I'm a command line veteran myself, with the same weapons of choice as you
(vim/zsh), but I still struggle with the ffmpeg workflow. I'd surely be
interested for any command line tools that would make it easier.

If you have the time to add a section to the documentation, I'm sure it
would be helpful for many people. And there's also the "tools" directory
for sharing any tools/scripts you created for ffmpeg development.

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Oneric]

On Sun 2020 Jul 5 20:01 +0300 Kieran Kunhya  wrote:
>
> Going back to the original point in hand.
> Many patches aren't getting reviewed and pushed any more.
> 
> In part this is because in 2020 whether we like it or not mailing
> lists are not the way to do Git based development.
> The kernel is the exception to the rule, as Linus says it has a whole
> load of grey-bearded system maintainers who are paid full time to work
> on it.
>
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.
> 
> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
> 
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
> 
> Whether we like it or not web interfaces are the way 95% of the world
> does Git and we have to move with the times.

As someone who recently only submitted a single, simple patch, I haven't seen 
mail-based dev as an annoyance, rather the contrary as this avoids the burden 
of creating yet another account on some website, that I'll have to manage.

There also already seems to be some automatic testing, as Patchwork send me an 
off-list mail about failing tests. (I did not set SAMPLES when running make 
fate locally as it was not mentioned clearly on the main "Contribute" site on 
the webpage. https://ffmpeg.org/developer.html .) It can probably be improved 
though.

What was frustating however, was the lack of any form of response to the patch 
for over a month, despite ml-pings.
On top of that the revised patch with updated FATE-samples had to change files 
with CRLF line endings that are not marked as such in .gitattributes. This 
prompted patchwork to be unable to apply the patch. Even though this is the 
only correct way to update these samples and left me concerned the patch might 
be being silently ignored because it fails on patchworks.

In my experience the review activity of a project is independend of its 
development workflow being mail or web based.


I also feel compelled to point out, that a switch to a web-based interface 
instead of plaintext emails can be a hurdle for devs with impaired vision, who 
might rely on customised mail interfaces, screen readers and/or braille 
displays as a Web-page is more complicated in that regard (especially with js).
While I myself am fortunate enough to not needing to rely on such a setup, I 
personally know devs (not working on ffmpeg afaik) that do.


Regards
Oneric
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Manolis Stamatogiannakis (12020-07-07):
> If I reply to the email, my response will appear online in the issue/PR
> page.

That is good to know. I have never noticed it documented. Does it work
reliably?

> Now, if you also want to review the code of a PRs from mutt, that's another
> discussion.

Not necessarily mutt, but if it's a web browser, then find somebody else
to review.

> Is tree threading that important? A PR is essentially a single thread of
> discussion.

It is a single thread of discussion until the discussion becomes complex
and has branches.

> I would first ask why keep using a mailing list to post patches and not use
> PRs. For a 3 commit patch, and 3 people sending feedback a few days apart,
> you have a minimum of 15 emails for everyone on the list. Is that efficient?

Actually, since mail servers are much much less resource-consuming that
web interfaces, it probably is.

Regards,

-- 
  Nicolas George


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] Project orientation

[Manolis Stamatogiannakis]

On Tue, 7 Jul 2020 at 14:59, Nicolas George  wrote:

>
> Is there a way of interacting with the discussions in GitHub issues
> outside their web interface?
>
> If there is, I never found it. If there is not, then GitHub's issue
> system is just not usable for serious work.
>

Any activity on issues/PRs I watch on GitHub is also sent to me with email.
If I reply to the email, my response will appear online in the issue/PR
page.
I've been doing that for years. When was the last time you checked?

Now, if you also want to review the code of a PRs from mutt, that's another
discussion.



> (Also, who designs discussion systems without tree threading?!?)
>

Is tree threading that important? A PR is essentially a single thread of
discussion.
If discussion on the PR carries on, you will anyway start stripping the old
context and respond to the bits of the last email. So tree threading
doesn't do much.

I would first ask why keep using a mailing list to post patches and not use
PRs. For a 3 commit patch, and 3 people sending feedback a few days apart,
you have a minimum of 15 emails for everyone on the list. Is that efficient?

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Paul B Mahol]

On 7/7/20, Nicolas George  wrote:
> Jean-Baptiste Kempf (12020-07-05):
>> With tools and organization.
>
> Sure, but you are forgetting one wing: responsibility.
>
> The reason many patches go a long time without review is that nobody
> feels responsible for reviewing them.
>
> If it is an area of the code we know well, an area for which we have
> maintainership, or if it seems to be tangent to a pet-peeve of ours, we
> will have a look at it.
>
> But otherwise, we will have a more-or-less cursory look at it, and
> assume somebody else will worry about it.
>
> It could be decided that authority in this project comes with the duty
> of doing some amount of boring review. (And doing it properly: if
> Coverity goes fireworks each time somebody approves a patch, they're not
> reviewing properly.)
>
> Probably another discussion to have once we have the structures to
> decide.
>

Yes, I still remember EOF saga in libavformat and unwillingness to fix
all regressions in timely manner, that caused similar issues also in
external projects.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Jean-Baptiste Kempf (12020-07-05):
> With tools and organization.

Sure, but you are forgetting one wing: responsibility.

The reason many patches go a long time without review is that nobody
feels responsible for reviewing them.

If it is an area of the code we know well, an area for which we have
maintainership, or if it seems to be tangent to a pet-peeve of ours, we
will have a look at it.

But otherwise, we will have a more-or-less cursory look at it, and
assume somebody else will worry about it.

It could be decided that authority in this project comes with the duty
of doing some amount of boring review. (And doing it properly: if
Coverity goes fireworks each time somebody approves a patch, they're not
reviewing properly.)

Probably another discussion to have once we have the structures to
decide.


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] Project orientation

[Nicolas George]

Soft Works (12020-07-05):
> When then reviewer would not have to look for code style and could
> assume that this is all right, he would be free to focus on the actual things.
> And when it's only about code-style, a reviewer would not need to
> review a patch two times (original + corrected) for checking whether 
> there were no other changes (imagine a multi-part patch).
> Also, the contributor would not have to wait two times for his patch 
> to get reviewed.

Honestly, this is a non-issue. When we review, we are not looking for
code style violations specifically. We are looking at the code very
carefully to try and spot real flaws. In doing so, we just see code
style violations and report them. It costs nothing.

Looking at a patch several times is a good thing: there are problems,
real problems, that we only spot on the second, third, fourth attempt.

> Continuous integration processing could also list compiler warnings
> isolated to the patch and help a reviewer spot issues that he might 
> have overlooked otherwise.

Sure, helpful tools would be nice.

Regards,

-- 
  Nicolas George


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] Project orientation

[James Almer]

On 7/7/2020 8:33 AM, Steinar H. Gunderson wrote:
> On Tue, Jul 07, 2020 at 01:30:52PM +0200, Nicolas George wrote:
>>> We don't live in a world of innocence. Enabling "less secure" applications
>>> is trouble waiting to happen.
>> Please don't believe that "less secure" applications are actually less
>> secure. The only thing they are less secure for is advertisers' business
>> model.
> 
> FWIW, the “less secure” part is about not supporting 2FA (POP/IMAP has no
> OAuth-like authentication methods).

This is not true. Thunderbird and i assume any modern IMAP/SMTP client
supports Oauth (which triggers the 2FA Gmail offers), so it's not one of
the "Less secure" applications Google warns you about.
And for those applications, like git send-email, they introduced the
"App passwords" that you can use to you login without Oauth and thus no
2FA prompt, without having to make any changes in security settings like
it was years ago.

> It is a very real concern -- for a large
> majority of users, enabling a good 2FA method would be the single most
> important thing they could do to improve their account security.
> 
> /* Steinar */
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

vectronic (12020-07-07):
> I think the key is choice. For example on GitHub people are able to
> contribute to the same project using any or all of: IDE plugins, the
> GitHub web UI or the standard git client CLI.

Is there a way of interacting with the discussions in GitHub issues
outside their web interface?

If there is, I never found it. If there is not, then GitHub's issue
system is just not usable for serious work.

(Also, who designs discussion systems without tree threading?!?)

Same question for the equivalent GitLab feature.

Regards,

-- 
  Nicolas George


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] Project orientation

[Nicolas George]

James Almer (12020-07-04):
> Just a few quick Saturday morning thoughts that don't cover your entire
> email and may be just me rambling, but some of this could be linked to
> the completely different world we're living in today than in say 2010,
> regarding what is expected of multimedia projects. Nowadays almost
> everything is streaming, and almost everything is mobile focused.
> Getting a 1% speed up in one hot loop in h264dec that could mean the
> difference between realtime or dropped frames in some ARM chip is
> immensely more important and demanded than a smoother experience running
> a filter chain, or a decoder for a 20 years old console game that would
> aid with emulation efforts. And yes, even if those chips have a hw decoder.
> 
> Similarly, the HEVC patent pool disaster completely ruined any chance
> for ffhevc to ever see any kind of real development, and the situation
> indirectly (or not) resulted in what would have been the internal AV1
> decoder becoming a standalone library: It required a extremely
> permissive license for the sake of fast and widespread adoption that
> ffmpeg could not provide with LGPL.
> It's the first time a very important codec is not present internally in
> our codebase, and that itself is proof things are definitely not the
> same as they used to. I can't imagine ffmpeg without an internal h264
> decoder ever making it anywhere a decade ago.
> Of course anyone could port it today, but does anyone capable want to?
> So far it doesn't look like.

Thanks for these explanations. There are a few facts that I was not
aware of that explain the situation better.

> Another thing worth mentioning is a lack of new blood. Despite
> participating in GSoC for a long while, i can't name a student that
> stuck around after the fact. Mind, there are new devs that started
> contributing for other reasons, but perhaps not enough?

When the something-of-code season is upon us, I have noticed we have to
rack our brains to find projects that are easy enough for students, and
it is hard.

Maybe FFmpeg has become too advanced to be able to benefit much of
contributions from the above-average students that make the bulk of the
something-of-code initiatives.

Maybe we should consider proposing projects and tasks that are much
harder, and accepting that we may get nobody for them, but if we get
somebody they could be somebody exceptional who may stay in the long
run.

Just a few thoughts about it, probably betraying shameless elitism from
my part.

Regards,

-- 
  Nicolas George


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] Project orientation

[Nicolas George]

Kieran Kunhya (12020-07-07):
> I don't disagree with the point about Gmail, however the reality of the
> situation is this is how 95% of the world now use email.

I would argue that 95% of the world has nothing of value to bring to
FFmpeg anyway.

And I would add there is probably a very strong correlation between
"having something of value to bring to FFmpeg" and "being able to learn
different ways of using software".

Therefore, this number, "95%" (which was probably invented on the spot,
like 99.1729% of statistics in similar situations) is not relevant in
this discussion.

> We are in a stagnasis as a project even *with* self-described experts
> staying.
> If they are the experts then they can deal with inconvenience to widen the
> pool of developers. A real expert sees the value in a sustainable project.

I think you are not using the word "expert" properly. Expertise means
being very good at something, not being good at everything.

Regards,

-- 
  Nicolas George


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] Project orientation

[Nicolas George]

Manolis Stamatogiannakis (12020-07-07):
> I believe I have adequately explained that "less secure" needs to be
> enabled, not to make your Google account more secure, but to contain
> the damage from a potential compromise.
> 
> Yes, "less secure" sounds a lot like marketing slang. But Gmail is not used
> exclusively by CompSci majors :)

I will state it another way.

Anybody should be able to use the software of their choice to read their
e-mail.

If a compromise around these software have a consequence beyond mail and
what is directly related to mail, then the fault is not the software's,
the fault is to whoever tied mail and other things together.

Google has a totalitarian policy, as in they want to totally control
your web experience (the fact that the same word is used to qualify
dictatorships is not a coincidence): they make every effort so that if
you dip a toe in them, you find yourself submerged before you know it.

It is Google's choice, and Google's responsibility, and your choice and
your responsibility if you decide to use Google totally.

This choice should not direct the workings of a Libre Software projects
that is not under the control of Google. The choice should even less
direct the choices of other people working on the project.

As was pointed out earlier, there are solutions. Even if Google hides
it, there are ways of accessing their walled gardens with other
applications. Even if there are not, you can decide to isolate your
accounts. (If would probably be a good idea irregardless of FFmpeg,
anyway.)

So learn to use them, and do not demand other people to change their
(good) habits so that you can keep your (bad) habits.

I would offer my help in doing so, but as I explained, I do not use
Google, and therefore have no help to offer to better use it. But if you
want my help in learning powerful command-line tools, you can have it.
(And it would probably be a good investment of your time.)

Regards,

-- 
  Nicolas George


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] Project orientation

[Anton Khirnov]

Quoting Manolis Stamatogiannakis (2020-07-07 13:28:55)
> On Tue, 7 Jul 2020 at 12:46, Nicolas George  wrote:
> 
> >
> > * GMail's warnings about "less secure" applications are scare tactics to
> >   get you to exclusively use their products, because they cannot feed
> >   you advertisement when you use a real mail client with their IMAP and
> >   SMTP servers.
> >
> >
> I *strongly* disagree with the scare tactics part. One's gmail account may
> be tied to several other online accounts.
> Having "less secure" applications enabled means that if your gmail password
> is compromised, people can easily own a few dozens of other accounts you
> own.
> And you won't even know, because gmail won't alert you about the intrusion.

Then the right solution is to support generating tokens with limited
privileges, e.g. just for SMTP access. Then again somebody in this
thread said this is already possible, so I don't know what we are even
arguing about.

Beyond that you can make a separate email account just for sending
patches, if you want to be extra doubleplus secure.


-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Jean-Baptiste Kempf (12020-07-05):
> You are missing the point here:
> Lego Racers demuxer is in the scope of "play everything under the sun"
> that the FFmpeg project is, while AMQP/ZMQ is not.
> 
> The issue is not usefulness, but correctly defining the scope of the
>  project (aka the orienttation). If you don't, you will integrate a
>  webserver, an email sender, a full webRTC stack with p2p and a coffee
>  controller.
> 
> Some codecs and formats are not useful, sure, but they are in the
> scope, and there is little debate about it.
> But custom protocols or complex filters that bring huge dependencies
> are very debatable, and I doubt they are the consensus.

I understand your point, but I see it as less a problem than another
similar but not identical issue.

Whether they are an actual multimedia protocol, format or codec, and
therefore "in the scope of the project" or something else and stranger,
and therefore not "in the scope", components are not in the way. They
are just a few extra C files to compile, possibly a few extra library
dependencies (i.e. NEEDED fields in ELF objects). They can be disabled,
and when they are they cost nothing. If they become a burden, if they
fail to build for example, they can be removed in a few seconds. In the
build tree, they are just leaves.

It can be said they cause a little namespace pollution, but that is all
there is technically. The major objection to accepting strange and
fringe components is not technical, it is us holding ourselves to a
higher standard: once something is in, it is in for good, it must be
maintained. If a patch on the framework breaks it, it must be repaired
or the patch is not accepted.

We do not have to do that. We do not have to hold ourselves to such
unattainable standards that they hamper development.

We could just say: we accept your fringe codec/format/filter/whatever,
but you have to maintain it: if it breaks we disable it, and either you
fix it or we remove it. Such components could be in sub-directories of
their respective libraries, there could be a global configure flag
--enable-fringe, etc.

The issues of components is not the hardest issue when it comes to
project orientation.


What is hardest, in my opinion, is changes that affect the way we do
things.

Let me develop one of the things I had in mind when starting this
discussion: strings.

Despite FFmpeg not being a project about handling text, it uses strings
in many places. And these strings are almost always basic NUL-terminated
C strings, either in constant-size on stack or mallocated. It is costing
us efficiency, code complexity (all the "if (!str) return
AVERROR(ENOMEM);".

I have drafted a proposal for a better API to handle strings (see
AVWriter in the archives). I think it is a good proposal: it was a long
time brewing, it includes several original ideas that should make it all
at once convenient, efficient and maintainable. See my points above
about creativity in programming.

But for people who work on parts of the code where there are not many
strings, the benefit does not exist. For them, there is only the hassle
of learning a new, non-default API. Even if this hassle is tiny, it is
still a hassle, and people do not want it, they oppose.

On the other hand, I could just push AVWriter and start using it in my
parts of the code: it is not in the scope of any maintained part, there
is nothing in the actual project rules that forbids me to do it. But it
would be extremely rude. And more than rude, it would lead to more
inconsistency (see https://xkcd.com/927/).

What we need is somebody or somebodies who listen on all sides of the
arguments, weigh the benefits and drawbacks, and decide: no, we'll
continue using basic C strings, don't waste your time working on
AVWriter; or yes, we'll use AVWriter, so all must find fifteen minutes
to learn how to use it; or even, yes we'll use smarter strings, but
rather this other proposal that looks more promising than AVWriter.

I can deal with AVWriter being discussed and rejected. What I have a
hard time dealing with is uncertainty: the code I am currently writing,
will it be wasted?

I took AVWriter as an example because it is something I worked on
recently, and something that affects a significant part of the code, but
there are many similar cases, where we need somebody to be able to
decide, for the whole project, how we will be doing things.

This could fall under the mandate of the tech committee, but I am not
sure it is the best idea: these issue border on the technical, but they
are also a matter of policy and human interaction. It would greatly
increase the power of the tech committee.

But tech committee or other, we need to be able to ask and answer these
questions.

> Also in this example, noone is telling them to fork, just to use the
> API to register their custom protocol.

I have a point for this, but this mail is already very long, I will make
it separately.

Regards,

-- 
  Nicolas George


signature.asc

Re: [FFmpeg-devel] Project orientation

[Manolis Stamatogiannakis]

On Tue, 7 Jul 2020 at 13:31, Nicolas George  wrote:

> Manolis Stamatogiannakis (12020-07-07):
> > We don't live in a world of innocence. Enabling "less secure"
> applications
> > is trouble waiting to happen.
>
> Please don't believe that "less secure" applications are actually less
> secure. The only thing they are less secure for is advertisers' business
> model.
>
>
I believe I have adequately explained that "less secure" needs to be
enabled, not to make your Google account more secure, but to contain
the damage from a potential compromise.

Yes, "less secure" sounds a lot like marketing slang. But Gmail is not used
exclusively by CompSci majors :)

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Steinar H. Gunderson]

On Tue, Jul 07, 2020 at 01:30:52PM +0200, Nicolas George wrote:
>> We don't live in a world of innocence. Enabling "less secure" applications
>> is trouble waiting to happen.
> Please don't believe that "less secure" applications are actually less
> secure. The only thing they are less secure for is advertisers' business
> model.

FWIW, the “less secure” part is about not supporting 2FA (POP/IMAP has no
OAuth-like authentication methods). It is a very real concern -- for a large
majority of users, enabling a good 2FA method would be the single most
important thing they could do to improve their account security.

/* Steinar */
-- 
Homepage: https://www.sesse.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] Project orientation

[Nicolas George]

Manolis Stamatogiannakis (12020-07-07):
> We don't live in a world of innocence. Enabling "less secure" applications
> is trouble waiting to happen.

Please don't believe that "less secure" applications are actually less
secure. The only thing they are less secure for is advertisers' business
model.

Regards,

-- 
  Nicolas George


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] Project orientation

[Manolis Stamatogiannakis]

On Tue, 7 Jul 2020 at 12:46, Nicolas George  wrote:

>
> * GMail's warnings about "less secure" applications are scare tactics to
>   get you to exclusively use their products, because they cannot feed
>   you advertisement when you use a real mail client with their IMAP and
>   SMTP servers.
>
>
I *strongly* disagree with the scare tactics part. One's gmail account may
be tied to several other online accounts.
Having "less secure" applications enabled means that if your gmail password
is compromised, people can easily own a few dozens of other accounts you
own.
And you won't even know, because gmail won't alert you about the intrusion.

We don't live in a world of innocence. Enabling "less secure" applications
is trouble waiting to happen.

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[vectronic]

> On 7 Jul 2020, at 12:13, Anton Khirnov  wrote:
> 
> Quoting Nicolas George (2020-07-07 12:46:39)
>> 
>> * GMail's warnings about "less secure" applications are scare tactics to
>>  get you to exclusively use their products, because they cannot feed
>>  you advertisement when you use a real mail client with their IMAP and
>>  SMTP servers.
> 
> VERY much agree
> We should not go along with these attempts to build a walled garden
> around email.

+1

> 
>> But be very careful to not make them mandatory.
> 
> +1
> Any change that makes it necessary to use a web browser for development
> a big step back IMO.

+1

I think the key is choice. For example on GitHub people are able to contribute 
to the same project using any or all of: IDE plugins, the GitHub web UI or the 
standard git client CLI.
I am not proposing GitHub, just saying that being able to choose the mode of 
interaction is attractive.

> There are public APIs for github and gitlab that make it possible in
> theory to develop CLI tools for them. But AFAIK the currently existing
> gitlab tools are too primitive for serious use, the github ones are more
> advanced but still limited compared to the web interface.
> 
> Also, gitlab and github are not the only options. Sourcehut[1] looks
> quite appealing to me and should be considered.
> 
> In any case, I think there should be a dedicated discussion and a vote
> about any proposed change in development process.

In terms of issue management and patch reviews etc. what is the view of people 
with respect to these two systems (which are as far as I know only web based):

https://trac.ffmpeg.org 

https://patchwork.ffmpeg.org/project/ffmpeg/list/ 


vs the usage of terminal based mail client and mailing lists?



> [1] https://sourcehut.org


___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Kieran Kunhya]

On Tue, 7 Jul 2020 at 12:13, Anton Khirnov  wrote:

> Quoting Nicolas George (2020-07-07 12:46:39)
> >
> > * GMail's warnings about "less secure" applications are scare tactics to
> >   get you to exclusively use their products, because they cannot feed
> >   you advertisement when you use a real mail client with their IMAP and
> >   SMTP servers.
>

I don't disagree with the point about Gmail, however the reality of the
situation is this is how 95% of the world now use email.
Likewise with CLI git. You cannot fight wider change, it will happen anyway.

We are in a stagnasis as a project even *with* self-described experts
staying.
If they are the experts then they can deal with inconvenience to widen the
pool of developers. A real expert sees the value in a sustainable project.

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] Project orientation

[Anton Khirnov]

Quoting Nicolas George (2020-07-07 12:46:39)
> 
> * GMail's warnings about "less secure" applications are scare tactics to
>   get you to exclusively use their products, because they cannot feed
>   you advertisement when you use a real mail client with their IMAP and
>   SMTP servers.

VERY much agree
We should not go along with these attempts to build a walled garden
around email.

> But be very careful to not make them mandatory.

+1
Any change that makes it necessary to use a web browser for development
a big step back IMO.

There are public APIs for github and gitlab that make it possible in
theory to develop CLI tools for them. But AFAIK the currently existing
gitlab tools are too primitive for serious use, the github ones are more
advanced but still limited compared to the web interface.

Also, gitlab and github are not the only options. Sourcehut[1] looks
quite appealing to me and should be considered.

In any case, I think there should be a dedicated discussion and a vote
about any proposed change in development process.

[1] https://sourcehut.org/

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Kieran Kunhya (12020-07-05):
> Going back to the original point in hand.

This was not the original point at all, but it does not matter much.

> Many patches aren't getting reviewed and pushed any more.
> 
> In part this is because in 2020 whether we like it or not mailing
> lists are not the way to do Git based development.
> The kernel is the exception to the rule, as Linus says it has a whole
> load of grey-bearded system maintainers who are paid full time to work
> on it.
> 
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.

Please, this is oversimplification and caricature. I urge you, for the
sake of sane discussion, learn a little about the arguments of the other
side.

* You don't need to set up a mail server to use git send-email, it is
  perfectly usable with any SMTP server, including GMail's.

* You can use any GUI mail client to work on FFmpeg, including with GMail.

* GMail's warnings about "less secure" applications are scare tactics to
  get you to exclusively use their products, because they cannot feed
  you advertisement when you use a real mail client with their IMAP and
  SMTP servers.

* And you can make bullet lists in plain mails, I just did. I would
  argue that if you do not know how to make a bullet list in a plain
  mail, you would not be able to make a bullet list in a C comment.

> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
> 
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
> 
> Whether we like it or not web interfaces are the way 95% of the world
> does Git and we have to move with the times.

I will speak about my case, but I am pretty sure it applies to a few of
my fellow developers, including a few of the very important and core
ones.

I know and know how to use both command-line and graphical tools to
program and develop, and I know this: I am immensely more efficient with
command-line tools.

There are many reasons for that. Command-line tools make together a
programming language, and I am good at programming; GUI tools, when they
allow programming, usually allow it in a clumsy way and only for the
things that were explicitly designed. Command-line tools tend to be much
more predictable in their fine behaviors, GUI tools have windows that
appear in unexpected places and the focus that gets lost somewhere. I am
much more agile with my fingers than with my whole arm, and hitting a
few keys in rapid succession requires less fine motor control than
hitting places on screen in rapid succession.

I do not like being inefficient, I despise it. Therefore, developing
with graphical tools is for me a pain. If I have a strong incentive to
do it, I will do it. But for fun? No, thanks.

I do not begrudge you your choices of tools to program an develop. Quite
the contrary, I want you to be able to use the tools you prefer. Git and
all the software around it are designed for that: they can be used
directly, but they can also be used within interfaces, and still work
with the raw versions.

You can use all the interfaces you need to make your work with FFmpeg as
comfortable as you want. If you find somebody to install and maintain
it, you can have all the interfaces you want available for all potential
developers.

But be very careful to not make them mandatory.

If the infrastructure of the project evolves to let us all use GUI tools
easily, then I will just not use them, or use them only in the rare
cases where they are more convenient than command-line.

But if the infrastructure of the project evolves so that only GUI tools
can be used, if I can no longer communicate with Mutt, program with Vim
and manage things with Zsh and the associated tools...

Then the project is no longer for me, and goodbye.

(And note that goodbye also means: good luck finding somebody who
understands how libavfilter works. I have tried to document as much as I
could, but the task is huge, and nobody but me seems interested anyway.
Goodbye from other core developers would similarly mean significant
parts of the code becoming orphan of know-how.)

A note about web interfaces. My point is that I want to use the software
of my choice. With web interface, the web browser is not the software of
my choice. First, the web browser is not the software, it is the runtime
environment; the software is the set of scripts running in the browser.
Unless there is also a low-level web-API interface, and an usable one,
not one that requires thousands of lines of code from undocumented
libraries just to authenticate, we cannot choose the software.

And 

Re: [FFmpeg-devel] Project orientation

[Mattias Wadman]

On Mon, Jul 6, 2020 at 5:59 PM Olly Woodman  wrote:
>
> On Mon, 6 Jul 2020 at 05:54, Jim DeLaHunt  wrote:
>
> > On 2020-07-04 07:43, Nicolas George wrote:
> > > [In the FFmpeg project,] [t]here is work in making highly-optimized
> > > decoders, this work is impressive and creative…. But as far as I can see,
> > > that is mostly all there is going on. The rest seems to be rather basic:
> > > fixing bugs…, implementing support for
> > > features that were decided and designed elsewhere.
> > >
> > > And it is not just that it is not happening: there is genuine opposition
> > > to creativity: things that are not already justified externally, things
> > > that do not look like well-known patterns, are met with scepticism and
> > > eventually rejected.
> > >
> > > At this point, we should ask ourselves:
> > >
> > > Is it what we want the project to be, or is it just what we have let it
> > > become?
> > >
> > > I do not think this evolution is the result of a deliberate choice. I
> > > think it is more the result of the stress of success and the stress of a
> > > fork. Success can stifle creativity, because creativity implies the risk
> > > of failure: the project has become advert to risk.
> > >
> > > It has evolved that way, but are we fine with it?
> > >
> > > I personally am not….
> >
> > I am really happy to see this discussion starting up. It is good timing;
> > some new governance committees are forming. They might be able to take
> > it on. From my perspective as an outside observer, I think the project
> > will benefit from you — the people who are at the heart of the project —
> > having this discussion.
> >
> > For what purpose do all of you contribute to FFmpeg? What is the good
> > you see FFmpeg doing? What is FFmpeg's purpose?  What stands in the way
> > of FFmpeg achieving its purpose, and of you achieving your own
> > individual purpose?
> >
> > For me, several comments in the thread resonated. They have a theme:
> > bringing in new participants:
> >
> > On 2020-07-04 08:37, James Almer wrote:
> > > …Another thing worth mentioning is a lack of new blood. Despite
> > > participating in GSoC for a long while, i can't name a student that
> > > stuck around after the fact. Mind, there are new devs that started
> > > contributing for other reasons, but perhaps not enough?
> >
> >
> > On 2020-07-04 11:20, Soft Works wrote:
> >
> > > …As a developer (without a well-known name) who wants to contribute a
> > patch,
> > > things can be quite frustrating here. When that patch accidentally hits
> > an
> > > area of one the very few who are caring and friendly - you're lucky.
> > > But otherwise, a patch will either be ignored or talked into infinity.
> > >
> > > I have a number of things to contribute, but after it didn’t work well
> > > with small things, I decided not to bother with the bigger ones.
> >
> > On 2020-07-05 11:42, Steinar H. Gunderson wrote:
> > > On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> > >> As a fresh contributor, setting up git send-email was a hassle, but
> > >> not an insurmountable obstacle.
> > > Speaking only for myself, having sent a single-digit number of patches
> > > to FFmpeg ever: Setting up git send-email was not a big turnoff. Having
> > your
> > > patch being not responded to (whether being forgotten, not found
> > interesting
> > > enough, or whatever other reason) was.
> >
> >
> > To the extent you decide that you want new participants to join you on
> > FFmpeg, I'm sorry to say, I think you have a problem. My own experience
> > is that this project is more hostile to newcomers than many other free
> > culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal,
> > MusicBrainz, Wikipedia). It's not just your rudeness to each other on
> > the email lists. It's not just the inattention to patches from new
> > developers. It's also a simple lack of telling newcomers: welcome, we
> > are glad you are here, we want your help, we will help you learn.
> >
>
> As someone who recently tried to send their first patch to FFmpeg,
> I'd also like to +1 this. It was completely ignored, despite sending
> three reminders (sending a reminder is suggested in the FFmpeg
> documentation for submitting patches). Perhaps it was ignored for
> a good reason, but a non-response does not tell me that, and nor
> does it encourage further involvement.
>
> I've also been quite shocked by some of the rudeness on this mailing
> list, and the level to which it appears to be tolerated (or at least, the
> extent to which there appear to be no repercussions for those who
> repeatedly behave in a way that I'd consider unacceptable in a
> professional context).

+1 on this. Personally i didn't feel ignored and got good code review
feedback. But the amount of rudeness I see on this list i think discourages
people from participating. Also think gitlab or something similar would
make things easier.

>
>
> > Even more deeply, the culture of this project is focussed on 

Re: [FFmpeg-devel] Project orientation

[Tomas Härdin]

sön 2020-07-05 klockan 18:01 +0100 skrev Kieran Kunhya:
> [...]
> 
> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
> 
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
> 
> Whether we like it or not web interfaces are the way 95% of the world
> does Git and we have to move with the times.

I'd be fine with moving to a self-hosted GitLab. Might bring in some
fresh blood. Keeps us independent of GitHub as well.

/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] Project orientation

[Olly Woodman]

On Mon, 6 Jul 2020 at 05:54, Jim DeLaHunt  wrote:

> On 2020-07-04 07:43, Nicolas George wrote:
> > [In the FFmpeg project,] [t]here is work in making highly-optimized
> > decoders, this work is impressive and creative…. But as far as I can see,
> > that is mostly all there is going on. The rest seems to be rather basic:
> > fixing bugs…, implementing support for
> > features that were decided and designed elsewhere.
> >
> > And it is not just that it is not happening: there is genuine opposition
> > to creativity: things that are not already justified externally, things
> > that do not look like well-known patterns, are met with scepticism and
> > eventually rejected.
> >
> > At this point, we should ask ourselves:
> >
> > Is it what we want the project to be, or is it just what we have let it
> > become?
> >
> > I do not think this evolution is the result of a deliberate choice. I
> > think it is more the result of the stress of success and the stress of a
> > fork. Success can stifle creativity, because creativity implies the risk
> > of failure: the project has become advert to risk.
> >
> > It has evolved that way, but are we fine with it?
> >
> > I personally am not….
>
> I am really happy to see this discussion starting up. It is good timing;
> some new governance committees are forming. They might be able to take
> it on. From my perspective as an outside observer, I think the project
> will benefit from you — the people who are at the heart of the project —
> having this discussion.
>
> For what purpose do all of you contribute to FFmpeg? What is the good
> you see FFmpeg doing? What is FFmpeg's purpose?  What stands in the way
> of FFmpeg achieving its purpose, and of you achieving your own
> individual purpose?
>
> For me, several comments in the thread resonated. They have a theme:
> bringing in new participants:
>
> On 2020-07-04 08:37, James Almer wrote:
> > …Another thing worth mentioning is a lack of new blood. Despite
> > participating in GSoC for a long while, i can't name a student that
> > stuck around after the fact. Mind, there are new devs that started
> > contributing for other reasons, but perhaps not enough?
>
>
> On 2020-07-04 11:20, Soft Works wrote:
>
> > …As a developer (without a well-known name) who wants to contribute a
> patch,
> > things can be quite frustrating here. When that patch accidentally hits
> an
> > area of one the very few who are caring and friendly - you're lucky.
> > But otherwise, a patch will either be ignored or talked into infinity.
> >
> > I have a number of things to contribute, but after it didn’t work well
> > with small things, I decided not to bother with the bigger ones.
>
> On 2020-07-05 11:42, Steinar H. Gunderson wrote:
> > On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> >> As a fresh contributor, setting up git send-email was a hassle, but
> >> not an insurmountable obstacle.
> > Speaking only for myself, having sent a single-digit number of patches
> > to FFmpeg ever: Setting up git send-email was not a big turnoff. Having
> your
> > patch being not responded to (whether being forgotten, not found
> interesting
> > enough, or whatever other reason) was.
>
>
> To the extent you decide that you want new participants to join you on
> FFmpeg, I'm sorry to say, I think you have a problem. My own experience
> is that this project is more hostile to newcomers than many other free
> culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal,
> MusicBrainz, Wikipedia). It's not just your rudeness to each other on
> the email lists. It's not just the inattention to patches from new
> developers. It's also a simple lack of telling newcomers: welcome, we
> are glad you are here, we want your help, we will help you learn.
>

As someone who recently tried to send their first patch to FFmpeg,
I'd also like to +1 this. It was completely ignored, despite sending
three reminders (sending a reminder is suggested in the FFmpeg
documentation for submitting patches). Perhaps it was ignored for
a good reason, but a non-response does not tell me that, and nor
does it encourage further involvement.

I've also been quite shocked by some of the rudeness on this mailing
list, and the level to which it appears to be tolerated (or at least, the
extent to which there appear to be no repercussions for those who
repeatedly behave in a way that I'd consider unacceptable in a
professional context).


> Even more deeply, the culture of this project is focussed on checking in
> compileable code to the exclusion of other kinds of contribution:
> testing, documentation, support. Those contributions seem not welcome
> simply because they are not code, and code is all that matters.
>
> I suspect that you may find that some of the things that frustrate you
> are linked to work the project does not value. Repetitive questions on
> the ffmpeg-users list may in part result from the inadequate
> documentation, which doesn't tell users what they need 

Re: [FFmpeg-devel] Project orientation

[Kieran Kunhya]

> Is it? It works easily for me just using msmtp or a similar
> sendmail implementation that speaks SMTP.
> No need for a mail server.
> If you think it's an issue, maybe it needs to be documented?


See the comments about Gmail above from a few people.
Yes it can be done but it's another barrier to entry.

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] Project orientation

[Reimar Döffinger]

On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> To Achieve this, we could try to
> * attract more developers doing reviews, i have generally suggested
>   contributors to help review other peoples patches. Maybe i should
>   take a step back and ask developers to ask developers to do this
>   instead. It is a way out of this problem
> * make people have a burning desire to review patches. I understand
>   this would work very well but iam not sure how to achieve this
> * pay developers to do reviews, i think we do not yet have the funds
>   for this as reviews take alot of time and thus this would not be
>   cheap

Maybe there's not enough people like me to matter, but for me it's
that I don't have time to read the whole mailing list to find the
patches I might be able to contribute to with a review.
I also add the caveat I wouldn't be able to do a super-deep technical
review, but there seem to be enough integer overflow issues (and
I mean the we-all-agree-it's-a-bug type) and other bugs getting
through that anyone familiar with reviewing code would be able
to contribute.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Reimar Döffinger]

On Sun, Jul 05, 2020 at 06:18:20PM +0100, Kieran Kunhya wrote:
> On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya  wrote:
> >
> > Going back to the original point in hand.
> > Many patches aren't getting reviewed and pushed any more.
> >
> > In part this is because in 2020 whether we like it or not mailing
> > lists are not the way to do Git based development.
> > The kernel is the exception to the rule, as Linus says it has a whole
> > load of grey-bearded system maintainers who are paid full time to work
> > on it.
> >
> > For new contributors git send-email is annoying. For people wanting to
> > push, the .mbox format is annoying, Gmail doesn't support it any more.
> > And you can't get new contributors to start using CLI based email
> > clients or run their own mail server, that's not going to happen.
> >
> > A solution like Gitlab is the only way forward. It has worked well for
> > dav1d, it can run regression tests on all platforms for all commits:
> > https://code.videolan.org/videolan/dav1d
> >
> > Merges are done with one push of a button. Yes, the branch sprawl is
> > not great but it's better than now.
> > It has inline patch reviews which are nice.
> >
> > Whether we like it or not web interfaces are the way 95% of the world
> > does Git and we have to move with the times.
>
> Not my intention to top post but gmail hides quoted text.
> Forgot to add that git send-email is quite complex to setup now
> without your own mail server.
> This also restricts our ability to add new developers.

Is it? It works easily for me just using msmtp or a similar
sendmail implementation that speaks SMTP.
No need for a mail server.
If you think it's an issue, maybe it needs to be documented?
That said, email lists are bad for quick drive-by patches
and there is far too much on this list.
Then again, github/gitlab aren't good for reviews either,
and plain atrocious for community and discussion, IMHO.

Best regards,
Reimar
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Steinar H. Gunderson]

On Sun, Jul 05, 2020 at 11:42:19PM +, Soft Works wrote:
> When then reviewer would not have to look for code style and could
> assume that this is all right, he would be free to focus on the actual things.

FWIW: At work, we went to clang-format to simply automate away 90%
of these things completely. (Some things, like naming conventions, are still
manual.) I was skeptical at first, but it showed to be a huge win; maybe not
as much because it made the reviewer's job easier, but because it made it
_harder_. When you can no longer make a few easy comments about braces and
that's the review, you're forced to go more in-depth, and quality of review
goes up.

This is probably too drastic a step for FFmpeg at this point, but I wanted
to mention it anyway.

/* Steinar */
-- 
Homepage: https://www.sesse.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] Project orientation

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Jim
> DeLaHunt
> Sent: Monday, July 6, 2020 6:54 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On 2020-07-04 07:43, Nicolas George wrote:
> > Hi.
> > 
> > When I first started progressively to contribute do FFmpeg, the project was
> > far from mature, but it was very much alive.
> > 
> > There was attempts at implementing new and better codecs, directly in lavc's
> > code base. There were attempts at designing new formats with useful
> > features.
> > 
> > Even outside the specialized work on specific codecs and formats, there was
> > creativity. At the API and framework level, there was work being done to do
> > things in a smarter way, either more convenient or more efficient or both.
> > 
> > For example, the format negotiation in liabvfilter (which was mostly 
> > designed
> > before I got involved: I am not singing my own praise here), with its 
> > pointers
> > to pointers to pointers, is not run-of-the-mill code.
> > Even if parts of it are made of common algorithms, the whole is very 
> > specific
> > to FFmpeg, and its design was creative. Creativity was necessary later to
> > extend it to support audio.
> > 
> > Nowadays, not so much. There is work in making highly-optimized decoders,
> > this work is impressive and creative, there is no doubt about it. But as 
> > far as I
> > can see, that is mostly all there is going on. The rest seems to be rather 
> > basic:
> > fixing bugs (and things that are not bugs, like harmless integer overflows),
> > implementing support for features that were decided and designed
> > elsewhere.
> > 
> > And it is not just that it is not happening: there is genuine opposition to
> > creativity: things that are not already justified externally, things that 
> > do not
> > look like well-known patterns, are met with scepticism and eventually
> > rejected.
> > 
> > At this point, we should ask ourselves:
> > 
> > Is it what we want the project to be, or is it just what we have let it 
> > become?
> > 
> > I do not think this evolution is the result of a deliberate choice. I think 
> > it is
> > more the result of the stress of success and the stress of a fork. Success 
> > can
> > stifle creativity, because creativity implies the risk of failure: the 
> > project has
> > become advert to risk.
> > 
> > It has evolved that way, but are we fine with it?
> > 
> > I personally am not.
> > 
> > I find the new ambiance boring.
> > 
> > Creativity is the reason I practice development, and the reason I do not
> > practice it professionally: my creativity cannot be put on a schedule.
> > 
> > My skills are not for micro-optimizing codec code: I cannot help on these
> > tasks. If I am allowed to analyze this myself, I would say that my skills 
> > lie in
> > general organization: making sure that the right code gets called at the 
> > right
> > time, finding more convenient ways of doing tasks, etc.
> > 
> > I have several ideas for the project. Some are not directly related to
> > multimedia at all; rather, the are invented for FFmpeg precisely, for 
> > FFmpeg's
> > exact needs and ways of doing things. They relate to options and
> > introspection, to inter-thread scheduling and asynchronous operation, to
> > error reporting to the application, to handling of strings and 
> > serialization, to
> > partial configurations of filters, to avoiding global state and allowing 
> > multiple
> > instances, etc.
> > 
> > I have shown the first steps of some of my ideas (AVWriter a few months
> > ago, avrefcount_template.h more recently), and the outcome was rather
> > disheartening and discouraging: "it's too complex" (of course: I am putting 
> > all
> > the complexity in one place so that the rest of the code can be simple, if 
> > you
> > look at just that part it looks complex!), "why don't you just" do thing the
> > usual way? (because I am trying to find a better way than the usual way.) It
> > seems my fellow developers do not look beyond the immediate strangeness
> > of the proposal to see the promised benefits, but remember: strangeness is
> > just lack of familiarity, it goes away fast all by itself, and all that 
> > remains are
> > the benefits.
> > 
> > These proposals would probably be better met if they were complete: if I
> > proposed a patch series that eliminates e

Re: [FFmpeg-devel] Project orientation

[Jim DeLaHunt]

On 2020-07-04 07:43, Nicolas George wrote:

[In the FFmpeg project,] [t]here is work in making highly-optimized
decoders, this work is impressive and creative…. But as far as I can see,
that is mostly all there is going on. The rest seems to be rather basic:
fixing bugs…, implementing support for
features that were decided and designed elsewhere.

And it is not just that it is not happening: there is genuine opposition
to creativity: things that are not already justified externally, things
that do not look like well-known patterns, are met with scepticism and
eventually rejected.

At this point, we should ask ourselves:

Is it what we want the project to be, or is it just what we have let it
become?

I do not think this evolution is the result of a deliberate choice. I
think it is more the result of the stress of success and the stress of a
fork. Success can stifle creativity, because creativity implies the risk
of failure: the project has become advert to risk.

It has evolved that way, but are we fine with it?

I personally am not….


I am really happy to see this discussion starting up. It is good timing; 
some new governance committees are forming. They might be able to take 
it on. From my perspective as an outside observer, I think the project 
will benefit from you — the people who are at the heart of the project — 
having this discussion.


For what purpose do all of you contribute to FFmpeg? What is the good 
you see FFmpeg doing? What is FFmpeg's purpose?  What stands in the way 
of FFmpeg achieving its purpose, and of you achieving your own 
individual purpose?


For me, several comments in the thread resonated. They have a theme: 
bringing in new participants:


On 2020-07-04 08:37, James Almer wrote:

…Another thing worth mentioning is a lack of new blood. Despite
participating in GSoC for a long while, i can't name a student that
stuck around after the fact. Mind, there are new devs that started
contributing for other reasons, but perhaps not enough?



On 2020-07-04 11:20, Soft Works wrote:


…As a developer (without a well-known name) who wants to contribute a patch,
things can be quite frustrating here. When that patch accidentally hits an
area of one the very few who are caring and friendly - you're lucky.
But otherwise, a patch will either be ignored or talked into infinity.

I have a number of things to contribute, but after it didn’t work well
with small things, I decided not to bother with the bigger ones.


On 2020-07-05 11:42, Steinar H. Gunderson wrote:

On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:

As a fresh contributor, setting up git send-email was a hassle, but
not an insurmountable obstacle.

Speaking only for myself, having sent a single-digit number of patches
to FFmpeg ever: Setting up git send-email was not a big turnoff. Having your
patch being not responded to (whether being forgotten, not found interesting
enough, or whatever other reason) was.



To the extent you decide that you want new participants to join you on 
FFmpeg, I'm sorry to say, I think you have a problem. My own experience 
is that this project is more hostile to newcomers than many other free 
culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal, 
MusicBrainz, Wikipedia). It's not just your rudeness to each other on 
the email lists. It's not just the inattention to patches from new 
developers. It's also a simple lack of telling newcomers: welcome, we 
are glad you are here, we want your help, we will help you learn.


Even more deeply, the culture of this project is focussed on checking in 
compileable code to the exclusion of other kinds of contribution: 
testing, documentation, support. Those contributions seem not welcome 
simply because they are not code, and code is all that matters.


I suspect that you may find that some of the things that frustrate you 
are linked to work the project does not value. Repetitive questions on 
the ffmpeg-users list may in part result from the inadequate 
documentation, which doesn't tell users what they need to know. Feeling 
stretched thin over too much code without enough tooling might result 
from the too little of the right unit tests. And so on.


I wish you success as you ask yourself these big questions. I hope it 
helps you have a more pleasant time in this project. I am confident it 
will result in a better FFmpeg.


  —Jim DeLaHunt, software engineer, Vancouver, Canada


___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andriy Gelman
> Sent: Monday, July 6, 2020 2:31 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, 05. Jul 23:42, Soft Works wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Monday, July 6, 2020 1:18 AM
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Project orientation
> > >
> > > On Sun, Jul 05, 2020 at 09:56:02PM +, Soft Works wrote:
> > > > ... A significant part of code reviews are code-style violations.
> > > > This is really not something where humans should need to spend
> > > > time for when reviewing a patch.
> > >
> > > you are correct but that is also the easy part of reviews.
> > > Its not what makes reviews time consuming.
> > > Rather while reviewing for technical stuff one notices maybe a
> > > formating issue
> >
> > When then reviewer would not have to look for code style and could
> > assume that this is all right, he would be free to focus on the actual 
> > things.
> > And when it's only about code-style, a reviewer would not need to
> > review a patch two times (original + corrected) for checking whether
> > there were no other changes (imagine a multi-part patch).
> > Also, the contributor would not have to wait two times for his patch
> > to get reviewed.
> >
> 
> > Continuous integration processing could also list compiler warnings
> > isolated to the patch and help a reviewer spot issues that he might
> > have overlooked otherwise.
> 
> This is done already... and checked for every single commit in the series.
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200701164348.41647
> -1-hanish...@gmail.com/


But still the "Michael-Machine" needed to respond manually:

> This breaks build on non x86
> 
> src/libavfilter/vf_fbdetile.c:81:10: fatal error: x86intrin.h: No such file 
> or directory
>  #include 
>   ^
> 
> [...]

And everybody in the mailinglist had to read/read this patch even though it
had an error.


softworkz


___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Andriy Gelman]

On Sun, 05. Jul 23:42, Soft Works wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Monday, July 6, 2020 1:18 AM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Project orientation
> > 
> > On Sun, Jul 05, 2020 at 09:56:02PM +, Soft Works wrote:
> > > ... A significant part of code reviews are code-style violations. This
> > > is really not something where humans should need to spend time for
> > > when reviewing a patch.
> > 
> > you are correct but that is also the easy part of reviews.
> > Its not what makes reviews time consuming.
> > Rather while reviewing for technical stuff one notices maybe a formating
> > issue
> 
> When then reviewer would not have to look for code style and could
> assume that this is all right, he would be free to focus on the actual things.
> And when it's only about code-style, a reviewer would not need to
> review a patch two times (original + corrected) for checking whether 
> there were no other changes (imagine a multi-part patch).
> Also, the contributor would not have to wait two times for his patch 
> to get reviewed.
> 

> Continuous integration processing could also list compiler warnings
> isolated to the patch and help a reviewer spot issues that he might 
> have overlooked otherwise.

This is done already... and checked for every single commit in the series.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200701164348.41647-1-hanish...@gmail.com/

-- 
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Monday, July 6, 2020 1:18 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, Jul 05, 2020 at 09:56:02PM +, Soft Works wrote:
> > ... A significant part of code reviews are code-style violations. This
> > is really not something where humans should need to spend time for
> > when reviewing a patch.
> 
> you are correct but that is also the easy part of reviews.
> Its not what makes reviews time consuming.
> Rather while reviewing for technical stuff one notices maybe a formating
> issue

When then reviewer would not have to look for code style and could
assume that this is all right, he would be free to focus on the actual things.
And when it's only about code-style, a reviewer would not need to
review a patch two times (original + corrected) for checking whether 
there were no other changes (imagine a multi-part patch).
Also, the contributor would not have to wait two times for his patch 
to get reviewed.

Continuous integration processing could also list compiler warnings
isolated to the patch and help a reviewer spot issues that he might 
have overlooked otherwise.

> > Neither should it be required that Michael responds manually each time
> > by stating "breaks FATE".
> 
> We already have fully automatic build and fate tests for submitted patches its
> done by patchwork which should send a private mail to the submitter of a
> patch affected.

And still you're sending those e-mails..

> Still not every environment is the same, and it passing on the patchwork box
> doesnt mean it builds on my mingw or mips environments for example.

Such things could be set up easily, either for free or for little money... ;-)

softworkz


___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Timo Rothenpieler]

On 06.07.2020 01:18, Michael Niedermayer wrote:

On Sun, Jul 05, 2020 at 09:56:02PM +, Soft Works wrote:

... A significant part of code reviews are code-style violations. This is
really not something where humans should need to spend time for when
reviewing a patch.


you are correct but that is also the easy part of reviews.
Its not what makes reviews time consuming.
Rather while reviewing for technical stuff one notices maybe a formating
issue



Neither should it be required that Michael responds manually each time
by stating "breaks FATE".


We already have fully automatic build and fate tests for submitted patches
its done by patchwork which should send a private mail to the submitter of
a patch affected.

Still not every environment is the same, and it passing on the patchwork
box doesnt mean it builds on my mingw or mips environments for example.



It also very frequently fails to properly handle large and complex 
series, with some of the patches getting new versions.


Also can't properly handle testing patches for stuff it cannot build, 
because it's for a different arch or needs a very specific library.
But that would equally affect any kind of Gitlab/Github Workflow we 
could set up.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Michael Niedermayer]

On Sun, Jul 05, 2020 at 09:56:02PM +, Soft Works wrote:
> ... A significant part of code reviews are code-style violations. This is
> really not something where humans should need to spend time for when 
> reviewing a patch.

you are correct but that is also the easy part of reviews.
Its not what makes reviews time consuming.
Rather while reviewing for technical stuff one notices maybe a formating
issue


> Neither should it be required that Michael responds manually each time 
> by stating "breaks FATE".

We already have fully automatic build and fate tests for submitted patches
its done by patchwork which should send a private mail to the submitter of
a patch affected.

Still not every environment is the same, and it passing on the patchwork
box doesnt mean it builds on my mingw or mips environments for example.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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] Project orientation

[Anamitra Ghorui]

July 5, 2020 11:43 PM, "Manolis Stamatogiannakis"  wrote:

> On Sun, 5 Jul 2020 at 19:01, Kieran Kunhya  wrote:
> 
>> For new contributors git send-email is annoying. For people wanting to
>> push, the .mbox format is annoying, Gmail doesn't support it any more.
>> And you can't get new contributors to start using CLI based email
>> clients or run their own mail server, that's not going to happen.
> 
> As a fresh contributor, setting up git send-email was a hassle, but
> not an insurmountable obstacle.
> 
> Though I'd argue that git send-email is a bigger liability for regular
> developers. A lot of developers seem to be using Gmail, which means they
> need to have "less secure apps" enabled at the time they use git
> send-email. So they are forced to choose between security and convenience.
> I.e. having to temporarily enable "less secure apps" every time they
> submit, or accept the risk of weakened security for their account.

Although not exactly convenient, Gmail now has a feature called app
passwords that allows you to create specialised passwords for things
like e-mail clients. You however have to enable 2 factor authentication
for this.

https://support.google.com/accounts/answer/185833?hl=en

>> A solution like Gitlab is the only way forward. It has worked well for
>> dav1d, it can run regression tests on all platforms for all commits:
>> https://code.videolan.org/videolan/dav1d
>> 
>> Merges are done with one push of a button. Yes, the branch sprawl is
>> not great but it's better than now.
>> It has inline patch reviews which are nice.
> 
> FWIW, I'd add that branch-based PRs as implemented with GitHub greatly
> reduce the turnaround for receiving feedback and addressing the raised
> issues.
> All you have to do is force-push on your PR branch, and the PR is cleanly
> updated.
> This is in contrast with having to use git send-email, where the emails
> containing the stale patches will continue to litter patchwork and your
> mailboxes.
> 
> Also, IIRC, when you update a branch, the regression tests for all pending
> PRs on the branch are automatically rerun.
> This should help address the conflicts in the pending PRs sooner rather
> than later.
> 
> Not sure what the status of GitLab is wrt to these features, but I'd expect
> it to not be very far behind.
> 
> Best regards,
> Manolis


Regards,
Anamitra

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Jean-Baptiste Kempf
> Sent: Sunday, July 5, 2020 11:48 PM
> To: ffmpeg-devel 
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> On Sun, Jul 5, 2020, at 22:50, Michael Niedermayer wrote:
> > > Having your
> > > patch being not responded to (whether being forgotten, not found
> > > interesting enough, or whatever other reason) was.
> >
> > At least for me the reason to not review a patch is often simply time.
> > But i agree the amount of not reviewed patches is a problem.
> 
> Yes.
> 
> > How can we solve this ?
> 
> With tools and organization.
> 
> Today, any patchset that has several patches (like the 36 ones for VP9 of the
> other day) or multiple revisions gets everyone a ton of emails. When you are
> at the revision 3 or 7, you completely lost track, unless you know exactly
> what to look for. Seeing the difference from the 2 revisions is very hard. So
> either you spend a lot of time understanding and re-reading or you drop it.
> So, either inefficiency for the reviewer, and therefore less reviews, or
> forgotten patches.
> 
> Today the patchwork has 64 pages of patches...
> 
> Noone human can know all that is happening.
> 
> So either you split the mailing list and patches per library (different for
> libavcodec, format), with submaintainers for each library, basically, like the
> Linux Kernel does.
> Or you move to github/gitlab which gives you by default a tracking of the MR
> that got merged or not, where you can see quickly the differences between
> 2 revisions of a patchset and where you can use tags to mark the merge
> requests, where the CI is automatic, so you don't have to check manually
> that the code compiles or that FATE is not broken, etc...

+1 for this. A significant part of code reviews are code-style violations. This 
is
really not something where humans should need to spend time for when 
reviewing a patch.
Neither should it be required that Michael responds manually each time 
by stating "breaks FATE".
Also, this would allow review comments stay connected to the commented
code parts forever. When in the future somebody wonders why something
has been done in a certain way, it will be easy to find that discussion.

softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Jean-Baptiste Kempf]

On Sun, Jul 5, 2020, at 22:50, Michael Niedermayer wrote:
> > Having your
> > patch being not responded to (whether being forgotten, not found interesting
> > enough, or whatever other reason) was.
> 
> At least for me the reason to not review a patch is often simply
> time.
> But i agree the amount of not reviewed patches is a problem.

Yes.

> How can we solve this ?

With tools and organization.

Today, any patchset that has several patches (like the 36 ones for VP9 of the 
other day) or multiple revisions gets everyone a ton of emails. When you are at 
the revision 3 or 7, you completely lost track, unless you know exactly what to 
look for. Seeing the difference from the 2 revisions is very hard. So either 
you spend a lot of time understanding and re-reading or you drop it.
So, either inefficiency for the reviewer, and therefore less reviews, or 
forgotten patches.

Today the patchwork has 64 pages of patches...

Noone human can know all that is happening.

So either you split the mailing list and patches per library (different for 
libavcodec, format), with submaintainers for each library, basically, like the 
Linux Kernel does.
Or you move to github/gitlab which gives you by default a tracking of the MR 
that got merged or not, where you can see quickly the differences between 2 
revisions of a patchset and where you can use tags to mark the merge requests, 
where the CI is automatic, so you don't have to check manually that the code 
compiles or that FATE is not broken, etc...


--
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] Project orientation

[Jean-Baptiste Kempf]

On Sun, Jul 5, 2020, at 18:25, Marton Balint wrote:
> > People aren't using it because people don't use MPEG-2.
> > There is no maintenance to be done on a format that's 25 years old, do
> > you want me to randomly change cosmetics to make you feel happy?
> 
> If you'd get off your high horse for once, that would make me feel happy.

This kind of tone is unwelcome.

-- 
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] Project orientation

[Jean-Baptiste Kempf]

On Sun, Jul 5, 2020, at 14:28, Marton Balint wrote:
> having AMQP/ZMQ protocol support is much more useful then Lego Racers 
> demuxer... 

You are missing the point here:
Lego Racers demuxer is in the scope of "play everything under the sun" that the 
FFmpeg project is, while AMQP/ZMQ is not.

The issue is not usefulness, but correctly defining the scope of the project 
(aka the orienttation).
 If you don't, you will integrate a webserver, an email sender, a full webRTC 
stack with p2p and a coffee controller.

Some codecs and formats are not useful, sure, but they are in the scope, and 
there is little debate about it.
But custom protocols or complex filters that bring huge dependencies are very 
debatable, and I doubt they are the consensus.

Also in this example, noone is telling them to fork, just to use the API to 
register their custom protocol.
-- 
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] Project orientation

[Kieran Kunhya]

On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya  wrote:
>
> Going back to the original point in hand.
> Many patches aren't getting reviewed and pushed any more.
>
> In part this is because in 2020 whether we like it or not mailing
> lists are not the way to do Git based development.
> The kernel is the exception to the rule, as Linus says it has a whole
> load of grey-bearded system maintainers who are paid full time to work
> on it.
>
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.
>
> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
>
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
>
> Whether we like it or not web interfaces are the way 95% of the world
> does Git and we have to move with the times.

Not my intention to top post but gmail hides quoted text.
Forgot to add that git send-email is quite complex to setup now
without your own mail server.
This also restricts our ability to add new developers.

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] Project orientation

[Steinar H. Gunderson]

On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> At least for me the reason to not review a patch is often simply
> time.
> But i agree the amount of not reviewed patches is a problem.
> 
> [...]
>
> The second thing is more reviews.
> That can happen by
> * More reviewers
> * More reviews per reviewer
> * Less work per review

I think this depends on whether the problem is time at any given instant,
or over a longer period of time. If the problem is “people don't have time
right now”, what is needed is a way to make sure patches are not forgotten
until the point where someone has time (so, effectively more reviews per
reviewer). If the problem is that reviewers are generally overworked,
one needs more reviewers or less work per review, as you say.

/* Steinar */
-- 
Homepage: https://www.sesse.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] Project orientation

[Kieran Kunhya]

Going back to the original point in hand.
Many patches aren't getting reviewed and pushed any more.

In part this is because in 2020 whether we like it or not mailing
lists are not the way to do Git based development.
The kernel is the exception to the rule, as Linus says it has a whole
load of grey-bearded system maintainers who are paid full time to work
on it.

For new contributors git send-email is annoying. For people wanting to
push, the .mbox format is annoying, Gmail doesn't support it any more.
And you can't get new contributors to start using CLI based email
clients or run their own mail server, that's not going to happen.

A solution like Gitlab is the only way forward. It has worked well for
dav1d, it can run regression tests on all platforms for all commits:
https://code.videolan.org/videolan/dav1d

Merges are done with one push of a button. Yes, the branch sprawl is
not great but it's better than now.
It has inline patch reviews which are nice.

Whether we like it or not web interfaces are the way 95% of the world
does Git and we have to move with the times.

Kieran

On Sun, Jul 5, 2020 at 5:38 PM Kieran Kunhya  wrote:
>
> > > People aren't using it because people don't use MPEG-2.
> > > There is no maintenance to be done on a format that's 25 years old, do
> > > you want me to randomly change cosmetics to make you feel happy?
> >
> > If you'd get off your high horse for once, that would make me feel happy.
>
> Please let me know what "maintenance" you'd like me to do on x262?
>
> > I don't think I told anybody to implement the missing features for free.
> > But I do believe that payed or free development has a higher chance of
> > happening if existing code is already available in a popular
> > package/project. And yes, I believe that some "maintenance burden" should
> > be accepted by the base project to give more chance to further
> > advancement, payed or free.
>
> It's not your pejorative to say that x264 developers have to accept
> and maintain a merge back of x262.
> Also this is quite complex now owing the combined 8/10-bit single
> binary. Furthermore any change to H.264 they would now have to test
> and maintain for MPEG-2.
> You seem to imply that this work is quite simple which is easy for you
> to say when you are the one not doing it.
> Do you plan to do this work?
>
> 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] Project orientation

[Henrik Gramner]

On Sun, Jul 5, 2020 at 9:10 PM Marton Balint  wrote:
> I don't know enough about x262/x264 to do this with reasonable amount of
> work. Do you think there is a chance of this happening if I post a bounty
> or get a sponsorship?

x264 is an H.264/AVC encoder and as such an MPEG-2 encoder is not in
scope to be included.

Just because a use case exists doesn't mean it's a good idea to accept
every feature under the sun upstream. Having a separate fork for that
is perfectly reasonable.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Michael Niedermayer]

On Sun, Jul 05, 2020 at 08:42:13PM +0200, Steinar H. Gunderson wrote:
> On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> > As a fresh contributor, setting up git send-email was a hassle, but
> > not an insurmountable obstacle.
> 
> Speaking only for myself, having sent a single-digit number of patches
> to FFmpeg ever: Setting up git send-email was not a big turnoff. 

> Having your
> patch being not responded to (whether being forgotten, not found interesting
> enough, or whatever other reason) was.

At least for me the reason to not review a patch is often simply
time.
But i agree the amount of not reviewed patches is a problem.

How can we solve this ?
From a mathematical point of view
either more reviews must happen or fewer patches have to be sent.

Fewer patches would only make sense if they are replaced by selfreview and
direct commits. This could reduce the load on reviewers. We did this
in the past and we had fewer non reviewed patches back then. I do not know
what peoples oppinion is about this but there has been opposition to
this long ago when it was commonly done.

The second thing is more reviews.
That can happen by
* More reviewers
* More reviews per reviewer
* Less work per review

To Achieve this, we could try to
* attract more developers doing reviews, i have generally suggested
  contributors to help review other peoples patches. Maybe i should
  take a step back and ask developers to ask developers to do this
  instead. It is a way out of this problem
* make people have a burning desire to review patches. I understand
  this would work very well but iam not sure how to achieve this
* pay developers to do reviews, i think we do not yet have the funds
  for this as reviews take alot of time and thus this would not be
  cheap
  
Also to make reviews less work
* Code documentation should be improved
* Testcases in fate should be mandatory for newly added "parts", this allows
  easy testing of changes and allows filtering out some bugs automatically
  
Some simple suggestion
* If you submmit a patch and its reviewed by someone, please pick some
  other patch by someone in an area you reasonably understand and review it
  (If everyone does this we have no lack of reviewers anymore)
  
Anyway i dont think the unreviewed patches amount is a unsolveable problem
  
Thanks
  
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are 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] Project orientation

[Kieran Kunhya]

> > People aren't using it because people don't use MPEG-2.
> > There is no maintenance to be done on a format that's 25 years old, do
> > you want me to randomly change cosmetics to make you feel happy?
>
> If you'd get off your high horse for once, that would make me feel happy.

Please let me know what "maintenance" you'd like me to do on x262?

> I don't think I told anybody to implement the missing features for free.
> But I do believe that payed or free development has a higher chance of
> happening if existing code is already available in a popular
> package/project. And yes, I believe that some "maintenance burden" should
> be accepted by the base project to give more chance to further
> advancement, payed or free.

It's not your pejorative to say that x264 developers have to accept
and maintain a merge back of x262.
Also this is quite complex now owing the combined 8/10-bit single
binary. Furthermore any change to H.264 they would now have to test
and maintain for MPEG-2.
You seem to imply that this work is quite simple which is easy for you
to say when you are the one not doing it.
Do you plan to do this work?

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] Project orientation

[Kieran Kunhya]

> x264 is practically feature complete, but x262 still miss some things,
> like 4:2:2 interlaced. Sure, x262 can work well enough for some use cases,
> but it is still not packaged in e.g. Ubuntu, so users are stuck with the
> - in some ways - inferior mpeg2 encoder of ffmpeg.
>
> The point I am trying to make is that you and some other people made a
> fast and modern mpeg2 encoder, in some ways superior to existing open
> source alternatives, but very few people is using it because it was not
> merged to a bigger/more popular project like x264 or ffmpeg. So it
> receives no mainteance, no distribution support, no user base and
> ultimately no further development. Or at least that is how I see it.

People aren't using it because people don't use MPEG-2.
There is no maintenance to be done on a format that's 25 years old, do
you want me to randomly change cosmetics to make you feel happy?
I know of people using it 24/7 for many years and have had no issues.

Have you opened bug reports on x264-devel about the issues you see?
MPEG-2 4:2:2 interlaced users are infinitesimally small and professional users.
If you want your pet feature to work, lo and behold you have to work
on it or pay someone to work on it.
If you want people to work on it out of nowhere then you are part of
the Free Rider Problem:
https://en.wikipedia.org/wiki/Free-rider_problem

x264 is heavily used but the changes these days are very minor in
spite of all these things. So your argument is incorrect.

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] Project orientation

[Marton Balint]

On Sun, 5 Jul 2020, Kieran Kunhya wrote:


People aren't using it because people don't use MPEG-2.

> There is no maintenance to be done on a format that's 25 years old, do
> you want me to randomly change cosmetics to make you feel happy?

If you'd get off your high horse for once, that would make me feel happy.


Please let me know what "maintenance" you'd like me to do on x262?


I don't want you to do anything. But for example some code changes need to 
be merged back from x264 if somebody wants to make x262 compile using the 
latest ffmpeg.





I don't think I told anybody to implement the missing features for free.
But I do believe that payed or free development has a higher chance of
happening if existing code is already available in a popular
package/project. And yes, I believe that some "maintenance burden" should
be accepted by the base project to give more chance to further
advancement, payed or free.


It's not your pejorative to say that x264 developers have to accept
and maintain a merge back of x262.


I am not saying they have to. I am saying that x262 would have benefited 
from it and the maintenance burden as I estimate it would not have been 
unsurmountable for x264.



Also this is quite complex now owing the combined 8/10-bit single
binary. Furthermore any change to H.264 they would now have to test
and maintain for MPEG-2.
You seem to imply that this work is quite simple which is easy for you
to say when you are the one not doing it.


I honestly don't know how much work it is. I assumed it is not too much, 
especially if somebody is familiar with the codebase. Now that the trees 
have diverged, obviously it has become harder. But dealing with the 
changes is usually easier if the feature is in-tree already.



Do you plan to do this work?


I don't know enough about x262/x264 to do this with reasonable amount of 
work. Do you think there is a chance of this happening if I post a bounty 
or get a sponsorship?


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Project orientation

[Steinar H. Gunderson]

On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> As a fresh contributor, setting up git send-email was a hassle, but
> not an insurmountable obstacle.

Speaking only for myself, having sent a single-digit number of patches
to FFmpeg ever: Setting up git send-email was not a big turnoff. Having your
patch being not responded to (whether being forgotten, not found interesting
enough, or whatever other reason) was.

/* Steinar */
-- 
Homepage: https://www.sesse.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] Project orientation

[Manolis Stamatogiannakis]

On Sun, 5 Jul 2020 at 19:01, Kieran Kunhya  wrote:

>
> For new contributors git send-email is annoying. For people wanting to
> push, the .mbox format is annoying, Gmail doesn't support it any more.
> And you can't get new contributors to start using CLI based email
> clients or run their own mail server, that's not going to happen.
>

As a fresh contributor, setting up git send-email was a hassle, but
not an insurmountable obstacle.

Though I'd argue that git send-email is a bigger liability for regular
developers. A lot of developers seem to be using Gmail, which means they
need to have  "less secure apps" enabled at the time they use git
send-email. So they are forced to choose between security and convenience.
I.e. having to temporarily enable  "less secure apps" every time they
submit, or accept the risk of weakened security for their account.



>
> A solution like Gitlab is the only way forward. It has worked well for
> dav1d, it can run regression tests on all platforms for all commits:
> https://code.videolan.org/videolan/dav1d
>
> Merges are done with one push of a button. Yes, the branch sprawl is
> not great but it's better than now.
> It has inline patch reviews which are nice.
>

FWIW, I'd add that branch-based PRs as implemented with GitHub greatly
reduce the turnaround for receiving feedback and addressing the raised
issues.
All you have to do is force-push on your PR branch, and the PR is cleanly
updated.
This is in contrast with having to use git send-email, where the emails
containing the stale patches will continue to litter patchwork and your
mailboxes.

Also, IIRC, when you update a branch, the regression tests for all pending
PRs on the branch are automatically rerun.
This should help address the conflicts in the pending PRs sooner rather
than later.

Not sure what the status of GitLab is wrt to these features, but I'd expect
it to not be very far behind.

Best regards,
Manolis
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Marton Balint]

On Sun, 5 Jul 2020, Kieran Kunhya wrote:


x264 is practically feature complete, but x262 still miss some things,
like 4:2:2 interlaced. Sure, x262 can work well enough for some use cases,
but it is still not packaged in e.g. Ubuntu, so users are stuck with the
- in some ways - inferior mpeg2 encoder of ffmpeg.

The point I am trying to make is that you and some other people made a
fast and modern mpeg2 encoder, in some ways superior to existing open
source alternatives, but very few people is using it because it was not
merged to a bigger/more popular project like x264 or ffmpeg. So it
receives no mainteance, no distribution support, no user base and
ultimately no further development. Or at least that is how I see it.


People aren't using it because people don't use MPEG-2.
There is no maintenance to be done on a format that's 25 years old, do
you want me to randomly change cosmetics to make you feel happy?


If you'd get off your high horse for once, that would make me feel happy.


I know of people using it 24/7 for many years and have had no issues.

Have you opened bug reports on x264-devel about the issues you see?
MPEG-2 4:2:2 interlaced users are infinitesimally small and professional users.
If you want your pet feature to work, lo and behold you have to work
on it or pay someone to work on it.
If you want people to work on it out of nowhere then you are part of
the Free Rider Problem:
https://en.wikipedia.org/wiki/Free-rider_problem


I don't think I told anybody to implement the missing features for free. 
But I do believe that payed or free development has a higher chance of 
happening if existing code is already available in a popular 
package/project. And yes, I believe that some "maintenance burden" should 
be accepted by the base project to give more chance to further 
advancement, payed or free.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Project orientation

[Tomas Härdin]

sön 2020-07-05 klockan 14:28 +0200 skrev Marton Balint:
> 
> On Sun, 5 Jul 2020, Tomas Härdin wrote:
> 
> > sön 2020-07-05 klockan 12:42 +0200 skrev Marton Balint:
> > > On Sun, 5 Jul 2020, Tomas Härdin wrote:
> > > 
> > > > sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> > > > > On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > > > > > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > > > > > wrote:
> > > > > > [...]
> > > > > > > At some point, the project needs to decide what is in and what is
> > > > > > > out, and since FFmpeg has numerous APIs, people can plug them
> > > > > > > externally. It's not a problem to say "No" to a feature,
> > > > > > > especially when, the number of people using that feature is under
> > > > > > > 0,01% of FFmpeg users, and when people can build that externally
> > > > > > > anyway.
> > > > > > 
> > > > > > what we need is not to say "no" but to say 
> > > > > > "use this API, implement the module in your own repository, and
> > > > > > register your module there"
> > > > > 
> > > > > Once again, Michael, we agree, on this topic.
> > > > > 
> > > > > No, means "not in the ffmpeg repo" does not mean "no, this is not
> > > > > useful".
> > > > 
> > > > I'd like to express a general agreement with this point. The project
> > > > has experienced quite a lot of scope creep lately. We don't have to
> > > > accommodate everyone, especially with the finite number of developers
> > > > available.
> > > > 
> > > > We can encourage people to maintain their own forks of FFmpeg, see for
> > > > example FFmbc.
> > > 
> > > And see how dead that project is. Or ffserver. Or x262.
> > 
> > That may be because Baptiste is focusing on other things. The code is
> > still there. It still compiles.
> 
> That is the point. Baptise is focusing on other things, and the code he 
> used to do rots in an external repository. I guess most of the features he 
> implemented crept back to ffmpeg (I did the backporting of some features 
> myself), but still, it was duplicate work.

It's not duplicate work if the work wouldn't have happened at all in
the first place.

We could probably work toward merging more features from FFmbc into
FFmpeg since presumably Baptiste doesn't depend on the license trolling
aspect of the former any more. I could probably do it if Baptiste would
be willing to dual license them and we could find a bit of funding for
it.

> Forks are good, if you are submitting the code back to master. If not, 
> then forks are not so good because they often dont't live on alone and you 
> lose the features in it.

Here is where scope/feature creep becomes a problem. Features aren't
free. Every feature is a liability and needs to be maintained. I for
one don't have infinite time to spend. This is why I focus mostly on
MXF.

> > Would you want something experimental like x262 to be part of the
> > FFmpeg codebase, for us to have to maintain forever? If you don't limit
> > scope then that is what would happen.
> 
> x262 is another example of a fork, where the fork alone was not 
> popular/interesting enough to live on. If it were merged to x264, I am 
> fairly certain it would not be experimental anymore, and we'd have an 
> MPEG2 encoder which would scale much better to multiple cores than what we 
> have now in ffmpeg.
> 
> So having something merged and maintained in ffmpeg has the benefit that 
> more people have the ability to test the code and to develop it. Also it 
> is more likely for the project to get developers if their code live in the 
> core ffmpeg respository. I also don't see that maitenance burden to be so 
> huge. And usefulness is also questionable. I think it is safe to say that 
> having AMQP/ZMQ protocol support is much more useful then Lego Racers 
> demuxer... (and I quite liked Lego Racers!!!).
> 
> So my opinion would be to be inclusive when merging stuff. I am not saying 
> everything has to be merged, I rejected not very long ago the NIT table 
> parsing or the EPG "data decoder", these were really out of scope and more 
> importantly out of the current capabilites of the framework. And if 
> distros are worried about dependencies, they can always make two packages, 
> a normal and a full.

Decent enough points. I just prefer being a bit more conservative with
what gets in, due to the maintainance burden.

> And I'd also like to point to the linux kernel as an example of a 
> monolitic code repository which seems to work quite well.

Kernel development being quite well-delegated may contribute to this.
Perhaps FFmpeg should move more in such a direction? Might be
interesting.

/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] Project orientation

[Marton Balint]

On Sun, 5 Jul 2020, Kieran Kunhya wrote:


Would you want something experimental like x262 to be part of the

> FFmpeg codebase, for us to have to maintain forever? If you don't limit
> scope then that is what would happen.

x262 is another example of a fork, where the fork alone was not
popular/interesting enough to live on. If it were merged to x264, I am
fairly certain it would not be experimental anymore, and we'd have an
MPEG2 encoder which would scale much better to multiple cores than what we
have now in ffmpeg.



Highly unlikely, x264 development has essentially ground to a halt. And
people use H.264 a lot still.
x262 works well enough for an old format like MPEG-2. There's no real need
to develop it unless someone needs to eke out an extra 2% compression
because they have a million MPEG-2 receivers they can't change.


x264 is practically feature complete, but x262 still miss some things, 
like 4:2:2 interlaced. Sure, x262 can work well enough for some use cases, 
but it is still not packaged in e.g. Ubuntu, so users are stuck with the 
- in some ways - inferior mpeg2 encoder of ffmpeg.


The point I am trying to make is that you and some other people made a 
fast and modern mpeg2 encoder, in some ways superior to existing open 
source alternatives, but very few people is using it because it was not 
merged to a bigger/more popular project like x264 or ffmpeg. So it 
receives no mainteance, no distribution support, no user base and 
ultimately no further development. Or at least that is how I see it.


Regards,
Marton



The original x264 developers didn't want a merge back by the way.

And I'd also like to point to the linux kernel as an example of a

monolitic code repository which seems to work quite well.



Exception that proves the rule. A lot of developers there are paid full
time to work on the kernel and just do cleanup, merge old patches etc.

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".

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Kieran Kunhya]

>
> So having something merged and maintained in ffmpeg has the benefit that
> more people have the ability to test the code and to develop it. Also it
> is more likely for the project to get developers if their code live in the
> core ffmpeg respository. I also don't see that maitenance burden to be so
> huge. And usefulness is also questionable. I think it is safe to say that
> having AMQP/ZMQ protocol support is much more useful then Lego Racers
> demuxer... (and I quite liked Lego Racers!!!).
>

Maybe also a full implementation of WebRTC? Or QUIC?
The problem is that libavformat is not a network stack and adding more
protocols means that it's harder and harder to build a real network stack.
See the way UDP has a hacky thread built in to stop packet loss.

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] Project orientation

[Kieran Kunhya]

>
> > Would you want something experimental like x262 to be part of the
> > FFmpeg codebase, for us to have to maintain forever? If you don't limit
> > scope then that is what would happen.
>
> x262 is another example of a fork, where the fork alone was not
> popular/interesting enough to live on. If it were merged to x264, I am
> fairly certain it would not be experimental anymore, and we'd have an
> MPEG2 encoder which would scale much better to multiple cores than what we
> have now in ffmpeg.
>

Highly unlikely, x264 development has essentially ground to a halt. And
people use H.264 a lot still.
x262 works well enough for an old format like MPEG-2. There's no real need
to develop it unless someone needs to eke out an extra 2% compression
because they have a million MPEG-2 receivers they can't change.

The original x264 developers didn't want a merge back by the way.

And I'd also like to point to the linux kernel as an example of a
> monolitic code repository which seems to work quite well.
>

Exception that proves the rule. A lot of developers there are paid full
time to work on the kernel and just do cleanup, merge old patches etc.

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] Project orientation

[Marton Balint]

On Sun, 5 Jul 2020, Tomas Härdin wrote:


sön 2020-07-05 klockan 12:42 +0200 skrev Marton Balint:


On Sun, 5 Jul 2020, Tomas Härdin wrote:

> sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> > On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > > wrote:
> > > [...]
> > > > At some point, the project needs to decide what is in and what is
> > > > out, and since FFmpeg has numerous APIs, people can plug them
> > > > externally. It's not a problem to say "No" to a feature,
> > > > especially when, the number of people using that feature is under
> > > > 0,01% of FFmpeg users, and when people can build that externally
> > > > anyway.
> > > 
> > > what we need is not to say "no" but to say 
> > > "use this API, implement the module in your own repository, and

> > > register your module there"
> > 
> > Once again, Michael, we agree, on this topic.
> > 
> > No, means "not in the ffmpeg repo" does not mean "no, this is not

> > useful".
> 
> I'd like to express a general agreement with this point. The project

> has experienced quite a lot of scope creep lately. We don't have to
> accommodate everyone, especially with the finite number of developers
> available.
> 
> We can encourage people to maintain their own forks of FFmpeg, see for

> example FFmbc.

And see how dead that project is. Or ffserver. Or x262.


That may be because Baptiste is focusing on other things. The code is
still there. It still compiles.


That is the point. Baptise is focusing on other things, and the code he 
used to do rots in an external repository. I guess most of the features he 
implemented crept back to ffmpeg (I did the backporting of some features 
myself), but still, it was duplicate work.


Forks are good, if you are submitting the code back to master. If not, 
then forks are not so good because they often dont't live on alone and you 
lose the features in it.




Would you want something experimental like x262 to be part of the
FFmpeg codebase, for us to have to maintain forever? If you don't limit
scope then that is what would happen.


x262 is another example of a fork, where the fork alone was not 
popular/interesting enough to live on. If it were merged to x264, I am 
fairly certain it would not be experimental anymore, and we'd have an 
MPEG2 encoder which would scale much better to multiple cores than what we 
have now in ffmpeg.


So having something merged and maintained in ffmpeg has the benefit that 
more people have the ability to test the code and to develop it. Also it 
is more likely for the project to get developers if their code live in the 
core ffmpeg respository. I also don't see that maitenance burden to be so 
huge. And usefulness is also questionable. I think it is safe to say that 
having AMQP/ZMQ protocol support is much more useful then Lego Racers 
demuxer... (and I quite liked Lego Racers!!!).


So my opinion would be to be inclusive when merging stuff. I am not saying 
everything has to be merged, I rejected not very long ago the NIT table 
parsing or the EPG "data decoder", these were really out of scope and more 
importantly out of the current capabilites of the framework. And if 
distros are worried about dependencies, they can always make two packages, 
a normal and a full.


And I'd also like to point to the linux kernel as an example of a 
monolitic code repository which seems to work quite well.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Project orientation

[Anton Khirnov]

Quoting Tomas Härdin (2020-07-05 13:19:25)
> sön 2020-07-05 klockan 12:42 +0200 skrev Marton Balint:
> > 
> > On Sun, 5 Jul 2020, Tomas Härdin wrote:
> > 
> > > sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> > > > On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > > > > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > > > > wrote:
> > > > > [...]
> > > > > > At some point, the project needs to decide what is in and what is
> > > > > > out, and since FFmpeg has numerous APIs, people can plug them
> > > > > > externally. It's not a problem to say "No" to a feature,
> > > > > > especially when, the number of people using that feature is under
> > > > > > 0,01% of FFmpeg users, and when people can build that externally
> > > > > > anyway.
> > > > > 
> > > > > what we need is not to say "no" but to say 
> > > > > "use this API, implement the module in your own repository, and
> > > > > register your module there"
> > > > 
> > > > Once again, Michael, we agree, on this topic.
> > > > 
> > > > No, means "not in the ffmpeg repo" does not mean "no, this is not
> > > > useful".
> > > 
> > > I'd like to express a general agreement with this point. The project
> > > has experienced quite a lot of scope creep lately. We don't have to
> > > accommodate everyone, especially with the finite number of developers
> > > available.
> > > 
> > > We can encourage people to maintain their own forks of FFmpeg, see for
> > > example FFmbc.
> > 
> > And see how dead that project is. Or ffserver. Or x262.
> 
> That may be because Baptiste is focusing on other things. The code is
> still there. It still compiles.
> 
> Would you want something experimental like x262 to be part of the
> FFmpeg codebase, for us to have to maintain forever? If you don't limit
> scope then that is what would happen.

I have been thinking about something like a staging branch. Or multiple
such "experimental" branches in the main repository, which would still
be "official" in some sense, even though they wouldn't be the master
one.

There obviously seems to be a conflict of visions between people who
want ffmpeg to be a stable consistent coherent tool for our downstreams
and those who want to play with experimental concepts, cute hacks and
fringe features. I would count myself among the former, but the latter
is also a valid worldview and should not be disregarded. I would like to
hope some kind of a compromise can be found.

Will write a more complete reply to OP later.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Tomas Härdin]

sön 2020-07-05 klockan 12:42 +0200 skrev Marton Balint:
> 
> On Sun, 5 Jul 2020, Tomas Härdin wrote:
> 
> > sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> > > On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > > > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > > > wrote:
> > > > [...]
> > > > > At some point, the project needs to decide what is in and what is
> > > > > out, and since FFmpeg has numerous APIs, people can plug them
> > > > > externally. It's not a problem to say "No" to a feature,
> > > > > especially when, the number of people using that feature is under
> > > > > 0,01% of FFmpeg users, and when people can build that externally
> > > > > anyway.
> > > > 
> > > > what we need is not to say "no" but to say 
> > > > "use this API, implement the module in your own repository, and
> > > > register your module there"
> > > 
> > > Once again, Michael, we agree, on this topic.
> > > 
> > > No, means "not in the ffmpeg repo" does not mean "no, this is not
> > > useful".
> > 
> > I'd like to express a general agreement with this point. The project
> > has experienced quite a lot of scope creep lately. We don't have to
> > accommodate everyone, especially with the finite number of developers
> > available.
> > 
> > We can encourage people to maintain their own forks of FFmpeg, see for
> > example FFmbc.
> 
> And see how dead that project is. Or ffserver. Or x262.

That may be because Baptiste is focusing on other things. The code is
still there. It still compiles.

Would you want something experimental like x262 to be part of the
FFmpeg codebase, for us to have to maintain forever? If you don't limit
scope then that is what would happen.

/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] Project orientation

[Marton Balint]

On Sun, 5 Jul 2020, Tomas Härdin wrote:


sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:


On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> wrote:
> [...]
> > At some point, the project needs to decide what is in and what is
> > out, and since FFmpeg has numerous APIs, people can plug them
> > externally. It's not a problem to say "No" to a feature,
> > especially when, the number of people using that feature is under
> > 0,01% of FFmpeg users, and when people can build that externally
> > anyway.
> 
> what we need is not to say "no" but to say 
> "use this API, implement the module in your own repository, and

> register your module there"

Once again, Michael, we agree, on this topic.

No, means "not in the ffmpeg repo" does not mean "no, this is not
useful".


I'd like to express a general agreement with this point. The project
has experienced quite a lot of scope creep lately. We don't have to
accommodate everyone, especially with the finite number of developers
available.

We can encourage people to maintain their own forks of FFmpeg, see for
example FFmbc.


And see how dead that project is. Or ffserver. Or x262.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Project orientation

[Tomas Härdin]

sön 2020-07-05 klockan 00:10 +0200 skrev Jean-Baptiste Kempf:
> 
> On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> > On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf
> > wrote:
> > [...]
> > > At some point, the project needs to decide what is in and what is
> > > out, and since FFmpeg has numerous APIs, people can plug them
> > > externally. It's not a problem to say "No" to a feature,
> > > especially when, the number of people using that feature is under
> > > 0,01% of FFmpeg users, and when people can build that externally
> > > anyway.
> > 
> > what we need is not to say "no" but to say 
> > "use this API, implement the module in your own repository, and
> > register your module there"
> 
> Once again, Michael, we agree, on this topic.
> 
> No, means "not in the ffmpeg repo" does not mean "no, this is not
> useful".

I'd like to express a general agreement with this point. The project
has experienced quite a lot of scope creep lately. We don't have to
accommodate everyone, especially with the finite number of developers
available.

We can encourage people to maintain their own forks of FFmpeg, see for
example FFmbc.

/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] Project orientation

[Jean-Baptiste Kempf]

On Sat, Jul 4, 2020, at 23:51, Michael Niedermayer wrote:
> On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf wrote:
> [...]
> > At some point, the project needs to decide what is in and what is out, and 
> > since FFmpeg has numerous APIs, people can plug them externally. It's not a 
> > problem to say "No" to a feature, especially when, the number of people 
> > using that feature is under 0,01% of FFmpeg users, and when people can 
> > build that externally anyway.
> 
> what we need is not to say "no" but to say 
> "use this API, implement the module in your own repository, and register your 
> module there"

Once again, Michael, we agree, on this topic.

No, means "not in the ffmpeg repo" does not mean "no, this is not useful".

An API for registering 3rd party avio and avfilters have been requested quite a 
few times, indeed.


--
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] Project orientation

[Jean-Baptiste Kempf]

On Sun, Jul 5, 2020, at 00:06, Paul B Mahol wrote:
> > For example and in my opinion, I don't see why there is support in avformat
> > for things that are not standards, like AMQP/ZMQ, who are neither a
> > multimedia format nor a multimedia protocol.
> > In the same way, if you start to need tensorflow or openvinno for a filter,
> > the code has no place in FFmpeg: you can use the api and use that
> > externally. Importing tensorflow is probably more lines of code, than
> > FFMpeg.
> > Or speech-recognition (sphinx) or OCR (tesseract)...
> 
> This is personal attack against me and my work.

No, it is not.
You and your work are 2 different things: you should start learning that 
speaking about a codebase does not mean anything against the author. 

And tbh, a few other people around here should learn about that too...

-- 
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] Project orientation

[Paul B Mahol]

On 7/4/20, Jean-Baptiste Kempf  wrote:
> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
>> Another area as we are already on the subject is stuff falling a little
>> outside what FFmpeg covers.
>> Not every filter that anyone wants to write should have to be in FFmpeg
>
> Thank $deity that you are saying this!
>
> FFmpeg is used more and more and numerous people want to put everything in
> it.
>
> The project needs to learn to say no to features and define the scope of
> each library.
>
> For libavcodec, the scope is quite clear, even if there are some debates
> about experimental codecs.
>
> But for the other libraries, including avformat and avfilter, there are
> dubious things in.
>
> For example and in my opinion, I don't see why there is support in avformat
> for things that are not standards, like AMQP/ZMQ, who are neither a
> multimedia format nor a multimedia protocol.
> In the same way, if you start to need tensorflow or openvinno for a filter,
> the code has no place in FFmpeg: you can use the api and use that
> externally. Importing tensorflow is probably more lines of code, than
> FFMpeg.
> Or speech-recognition (sphinx) or OCR (tesseract)...

This is personal attack against me and my work.

> And now comes the debate with synthesizers or complex filters that are
> almost reinventing GStreamer inside libavfilter ("let's use libavcodec as a
> filter, since everything is a filter")...
>
> When you look at the FFmpeg dependency graph on distributions like Debian,
> this is getting scrary, and this increases a lot the binary size and
> resources usage.

Nobody forces them to enable every single thing.

>
> At some point, the project needs to decide what is in and what is out, and
> since FFmpeg has numerous APIs, people can plug them externally. It's not a
> problem to say "No" to a feature, especially when, the number of people
> using that feature is under 0,01% of FFmpeg users, and when people can build
> that externally anyway.
>
>
> --
> 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Michael Niedermayer]

On Sat, Jul 04, 2020 at 11:25:31PM +0200, Jean-Baptiste Kempf wrote:
[...]
> At some point, the project needs to decide what is in and what is out, and 
> since FFmpeg has numerous APIs, people can plug them externally. It's not a 
> problem to say "No" to a feature, especially when, the number of people using 
> that feature is under 0,01% of FFmpeg users, and when people can build that 
> externally anyway.

what we need is not to say "no" but to say 
"use this API, implement the module in your own repository, and register your 
module there"

So that anyone using FFmpeg no matter if its self build git master or
a 2 year old binary from a linux distribution or something else can
simply and safely build and use compatible filters, formats and so on.
With a simple and standarized command.
That is not the case currently

So when we say "no" currently its really saying "you are out of luck" 
and it should not be that way.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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] Project orientation

[Jean-Baptiste Kempf]

On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
> Another area as we are already on the subject is stuff falling a little
> outside what FFmpeg covers.
> Not every filter that anyone wants to write should have to be in FFmpeg

Thank $deity that you are saying this!

FFmpeg is used more and more and numerous people want to put everything in it.

The project needs to learn to say no to features and define the scope of each 
library.

For libavcodec, the scope is quite clear, even if there are some debates about 
experimental codecs.

But for the other libraries, including avformat and avfilter, there are dubious 
things in.

For example and in my opinion, I don't see why there is support in avformat for 
things that are not standards, like AMQP/ZMQ, who are neither a multimedia 
format nor a multimedia protocol.
In the same way, if you start to need tensorflow or openvinno for a filter, the 
code has no place in FFmpeg: you can use the api and use that externally. 
Importing tensorflow is probably more lines of code, than FFMpeg.
Or speech-recognition (sphinx) or OCR (tesseract)...
And now comes the debate with synthesizers or complex filters that are almost 
reinventing GStreamer inside libavfilter ("let's use libavcodec as a filter, 
since everything is a filter")...

When you look at the FFmpeg dependency graph on distributions like Debian, this 
is getting scrary, and this increases a lot the binary size and resources usage.

At some point, the project needs to decide what is in and what is out, and 
since FFmpeg has numerous APIs, people can plug them externally. It's not a 
problem to say "No" to a feature, especially when, the number of people using 
that feature is under 0,01% of FFmpeg users, and when people can build that 
externally anyway.


--
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] Project orientation

[Jean-Baptiste Kempf]

On Sat, Jul 4, 2020, at 17:23, James Almer wrote:
> >> So, I ask one last time: What kind of project do you want FFmpeg to be?
> > 
> > Certainly one where you are not part of it.
> 
> Can you just fuck off already?

2 Wrongs don't make a right.

Insults are not welcome, whatever was said before.

-- 
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] Project orientation

[Jean-Baptiste Kempf]

On Sat, Jul 4, 2020, at 16:51, Paul B Mahol wrote:
> > So, I ask one last time: What kind of project do you want FFmpeg to be?
> 
> Certainly one where you are not part of it.

That is unnecessary.

"If you don't have something nice to say, or something constructive, don't say 
anything at all."
-- 
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] Project orientation

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> James Almer
> Sent: Saturday, July 4, 2020 5:37 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Project orientation
> 
> Another thing worth mentioning is a lack of new blood. Despite participating
> in GSoC for a long while, i can't name a student that stuck around after the
> fact. Mind, there are new devs that started contributing for other reasons,
> but perhaps not enough?

My time as a student is long gone. Over the years, I have seen a lot and done a 
lot 
of things as a developer. From my perspective, ffmpeg is one of the least 
attractive software projects for contributing, that I know. There are so many
reasons, I don't even know where to start.

Let's take this one: While writing this e-mail, I have to insert manual line 
breaks
in order to adapt to how mails were written until the 1980ies. I cannot use 
bullet points or font formatting (e.g. to indicate code snippets).

Communication via a mailing list is anachronistic.  The world has changed 
and much better ways exist to communicate. The fact alone, that this mailing-
list approach forces me to continuously read everything - including that
sociopathic talk that is happening here as well, would be reason enough
for me to walk away. 
With something like a forum or GitHub issues, I could not only step out of 
those conversations, but also better choose topics where I'm interested in
and where not.

And using patch files with plus and minus signs for collaborating on code 
changes? Really? It's not just that it would be a matter of taste - there are 
obvious shortcomings when comparing with modern ways, like that it's 
impossible to connect code and discussion about that code.

Another problem is, that there is almost no connection to users of ffmpeg.
The user mailing list is strictly separated and developers seem to be living 
inside some kind of bubble with little contact to those who are actually 
using ffmpeg. That's my impression at least. I'm sure there is one or the 
other who does differently.

As a developer (without a well-known name) who wants to contribute a patch,
things can be quite frustrating here. When that patch accidentally hits an
area of one the very few who are caring and friendly - you're lucky.
But otherwise, a patch will either be ignored or talked into infinity.

I have a number of things to contribute, but after it didn’t work well 
with small things, I decided not to bother with the bigger ones.
As an example, I gave my QuickSync/DX11 code to Intel, in order to let
them deal with getting it merged, but even that didn't work out so far.
AMD AMF hardware decoders are still missing. They had submitted 
something 1 or 2 years ago, but they didn't get any feedback and were
discouraged to proceed. 
Windows Media Foundation HW acceleration has recently been merged,
but the actual patch existed for several(!) years. 
Things running not really smooth here, a lot more progress could be made
in some areas.

I know, the project is community driven, but sometimes I think there is
missing someone who is "in charge" of things and connects the many
loose ends that exist.

-

I don't really have a problem with how things are. I accommodate, we got  
our own fork and platform builds and just do our changes there.

This is my very personal view. People have different opinions (luckily), 
and I didn't write this to discuss all those points in detail or to initiate
some change to the project.

But when somebody starts wondering, why there aren't any new developers
joining the project, one should maybe think about whether one or two 
of the things I listed above could be the reason...

Kind regards,
softworkz

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Project orientation

[Nicolas George]

Kieran Kunhya (12020-07-04):
> > i do hope the planned technical committee will help with some of the
> > problems you discussed here.
> > But sometimes people are also rather rigid in discussions less interrested
> > to find a good compromise to move forward with and more interrested in
> > "winning" a discussion. That is also not helping and i dont think the
> > technical committee should be seen as the solution to this. Its better
> > people discuss and agree than to go to some arbitration to decide
> >
> 
> The technical committee was created exactly to resolve situations like this.
> Instead of the current case where issues are filibustered or blocked by
> "maintainers".

I am not sure this is all that is needed.

The technical committee can answer for precise questions with a few
alternatives: are A's arguments or B's arguments stronger, and should we
accept or reject the patch as is?

But I do not think it is meant to arbitrate questions about more remote
concerns: do we want the project to go in that direction or this
direction? It is a different kind of decision.

Regards,

-- 
  Nicolas George


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] Project orientation

[Paul B Mahol]

On 7/4/20, James Almer  wrote:
> On 7/4/2020 11:51 AM, Paul B Mahol wrote:
>> On 7/4/20, Nicolas George  wrote:
>>> Hi.
>>>
>>> When I first started progressively to contribute do FFmpeg, the project
>>> was far from mature, but it was very much alive.
>>>
>>> There was attempts at implementing new and better codecs, directly in
>>> lavc's code base. There were attempts at designing new formats with
>>> useful features.
>>>
>>> Even outside the specialized work on specific codecs and formats, there
>>> was creativity. At the API and framework level, there was work being
>>> done to do things in a smarter way, either more convenient or more
>>> efficient or both.
>>>
>>> For example, the format negotiation in liabvfilter (which was mostly
>>> designed before I got involved: I am not singing my own praise here),
>>> with its pointers to pointers to pointers, is not run-of-the-mill code.
>>> Even if parts of it are made of common algorithms, the whole is very
>>> specific to FFmpeg, and its design was creative. Creativity was
>>> necessary later to extend it to support audio.
>>>
>>> Nowadays, not so much. There is work in making highly-optimized
>>> decoders, this work is impressive and creative, there is no doubt about
>>> it. But as far as I can see, that is mostly all there is going on. The
>>> rest seems to be rather basic: fixing bugs (and things that are not
>>> bugs, like harmless integer overflows), implementing support for
>>> features that were decided and designed elsewhere.
>>>
>>> And it is not just that it is not happening: there is genuine opposition
>>> to creativity: things that are not already justified externally, things
>>> that do not look like well-known patterns, are met with scepticism and
>>> eventually rejected.
>>>
>>> At this point, we should ask ourselves:
>>>
>>> Is it what we want the project to be, or is it just what we have let it
>>> become?
>>>
>>> I do not think this evolution is the result of a deliberate choice. I
>>> think it is more the result of the stress of success and the stress of a
>>> fork. Success can stifle creativity, because creativity implies the risk
>>> of failure: the project has become advert to risk.
>>>
>>> It has evolved that way, but are we fine with it?
>>>
>>> I personally am not.
>>>
>>> I find the new ambiance boring.
>>>
>>> Creativity is the reason I practice development, and the reason I do not
>>> practice it professionally: my creativity cannot be put on a schedule.
>>>
>>> My skills are not for micro-optimizing codec code: I cannot help on
>>> these tasks. If I am allowed to analyze this myself, I would say that my
>>> skills lie in general organization: making sure that the right code gets
>>> called at the right time, finding more convenient ways of doing tasks,
>>> etc.
>>>
>>> I have several ideas for the project. Some are not directly related to
>>> multimedia at all; rather, the are invented for FFmpeg precisely, for
>>> FFmpeg's exact needs and ways of doing things. They relate to options
>>> and introspection, to inter-thread scheduling and asynchronous
>>> operation, to error reporting to the application, to handling of strings
>>> and serialization, to partial configurations of filters, to avoiding
>>> global state and allowing multiple instances, etc.
>>>
>>> I have shown the first steps of some of my ideas (AVWriter a few months
>>> ago, avrefcount_template.h more recently), and the outcome was rather
>>> disheartening and discouraging: "it's too complex" (of course: I am
>>> putting all the complexity in one place so that the rest of the code can
>>> be simple, if you look at just that part it looks complex!), "why don't
>>> you just" do thing the usual way? (because I am trying to find a better
>>> way than the usual way.) It seems my fellow developers do not look beyond
>>> the immediate strangeness of the proposal to see the promised benefits,
>>> but remember: strangeness is just lack of familiarity, it goes away fast
>>> all by itself, and all that remains are the benefits.
>>>
>>> These proposals would probably be better met if they were complete: if I
>>> proposed a patch series that eliminates escaping hell or gets
>>> non-blocking operation working all at once, it would be easier to get it
>>> accepted. But it is too big a task, especially with the rest of the code
>>> moving under my feet, with conflicts at each rebase.
>>>
>>> Lacking that, they require a little trust: trust enough to look, beyond
>>> the immediate strangeness, where I am going and to try to see what I
>>> want to achieve, and see that it is achievable. But for now, I have seen
>>> more doubt and dismissal than trust and enthusiasm. And the projects are
>>> too big, I am not prepared to fight an uphill battle to get accepted
>>> every small step.
>>>
>>> If I cannot express my creativity by developing for FFmpeg, I will find
>>> other projects, mine or existing, to express it. I suspect others have
>>> orbited away from the projects for similar 

Re: [FFmpeg-devel] Project orientation

[Kieran Kunhya]

>
> i do hope the planned technical committee will help with some of the
> problems you discussed here.
> But sometimes people are also rather rigid in discussions less interrested
> to find a good compromise to move forward with and more interrested in
> "winning" a discussion. That is also not helping and i dont think the
> technical committee should be seen as the solution to this. Its better
> people discuss and agree than to go to some arbitration to decide
>

The technical committee was created exactly to resolve situations like this.
Instead of the current case where issues are filibustered or blocked by
"maintainers".

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] Project orientation

[Michael Niedermayer]

Hi

On Sat, Jul 04, 2020 at 04:43:54PM +0200, Nicolas George wrote:
> Hi.
> 
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
> 
> There was attempts at implementing new and better codecs, directly in
> lavc's code base. There were attempts at designing new formats with
> useful features.
> 
> Even outside the specialized work on specific codecs and formats, there
> was creativity. At the API and framework level, there was work being
> done to do things in a smarter way, either more convenient or more
> efficient or both.
> 
> For example, the format negotiation in liabvfilter (which was mostly
> designed before I got involved: I am not singing my own praise here),
> with its pointers to pointers to pointers, is not run-of-the-mill code.
> Even if parts of it are made of common algorithms, the whole is very
> specific to FFmpeg, and its design was creative. Creativity was
> necessary later to extend it to support audio.
> 
> Nowadays, not so much. There is work in making highly-optimized
> decoders, this work is impressive and creative, there is no doubt about
> it. But as far as I can see, that is mostly all there is going on. The
> rest seems to be rather basic: fixing bugs (and things that are not
> bugs, like harmless integer overflows), implementing support for
> features that were decided and designed elsewhere.
> 
> And it is not just that it is not happening: there is genuine opposition
> to creativity: things that are not already justified externally, things
> that do not look like well-known patterns, are met with scepticism and
> eventually rejected.
> 
> At this point, we should ask ourselves:
> 
> Is it what we want the project to be, or is it just what we have let it
> become?
> 
> I do not think this evolution is the result of a deliberate choice. I
> think it is more the result of the stress of success and the stress of a
> fork. Success can stifle creativity, because creativity implies the risk
> of failure: the project has become advert to risk.
> 
> It has evolved that way, but are we fine with it?
> 
> I personally am not.
> 
> I find the new ambiance boring.

not sure we are thinking of 100% the same thing but i also feel that
theres less design and healthy/friendly discussions about design going on
than what should be and what was really long ago.

Another area as we are already on the subject is stuff falling a little
outside what FFmpeg covers.
Not every filter that anyone wants to write should have to be in FFmpeg
This is a bit like requiring every C program to be in the repository of
the C compiler. You know, that would have issues for C and it does for
FFmpeg too.

Similarly are encoders/decoders. someone can write a rather advanced codec for a
fringe format thats either faster or compresses better and volunteer
to maintain it. But it gets rejected because Its just a fringe format
the majority in FFmpeg doesnt care enough about in relation the the
complex code.
I dont think this sort of thing is good, we loose new blood this way
and what remains is simple but unmaintained code for that codec.


[...]
> I have several ideas for the project. Some are not directly related to
> multimedia at all; rather, the are invented for FFmpeg precisely, for
> FFmpeg's exact needs and ways of doing things. They relate to options
> and introspection, to inter-thread scheduling and asynchronous
> operation, to error reporting to the application, to handling of strings
> and serialization, to partial configurations of filters, to avoiding
> global state and allowing multiple instances, etc.
> 
> I have shown the first steps of some of my ideas (AVWriter a few months
> ago, avrefcount_template.h more recently), and the outcome was rather
> disheartening and discouraging: "it's too complex" (of course: I am
> putting all the complexity in one place so that the rest of the code can
> be simple, if you look at just that part it looks complex!), "why don't
> you just" do thing the usual way? (because I am trying to find a better
> way than the usual way.) It seems my fellow developers do not look beyond
> the immediate strangeness of the proposal to see the promised benefits,
> but remember: strangeness is just lack of familiarity, it goes away fast
> all by itself, and all that remains are the benefits.

A bit toward this topic, would be a more generally useable utilities
library. something like libavutil but not just for multimedia.


> 
> These proposals would probably be better met if they were complete: if I
> proposed a patch series that eliminates escaping hell or gets
> non-blocking operation working all at once, it would be easier to get it
> accepted. But it is too big a task, especially with the rest of the code
> moving under my feet, with conflicts at each rebase.
> 
> Lacking that, they require a little trust: trust enough to look, beyond
> the immediate strangeness, where I am going and to try to see what I
> 

Re: [FFmpeg-devel] Project orientation

[James Almer]

On 7/4/2020 11:43 AM, Nicolas George wrote:
> Hi.
> 
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
> 
> There was attempts at implementing new and better codecs, directly in
> lavc's code base. There were attempts at designing new formats with
> useful features.
> 
> Even outside the specialized work on specific codecs and formats, there
> was creativity. At the API and framework level, there was work being
> done to do things in a smarter way, either more convenient or more
> efficient or both.
> 
> For example, the format negotiation in liabvfilter (which was mostly
> designed before I got involved: I am not singing my own praise here),
> with its pointers to pointers to pointers, is not run-of-the-mill code.
> Even if parts of it are made of common algorithms, the whole is very
> specific to FFmpeg, and its design was creative. Creativity was
> necessary later to extend it to support audio.
> 
> Nowadays, not so much. There is work in making highly-optimized
> decoders, this work is impressive and creative, there is no doubt about
> it. But as far as I can see, that is mostly all there is going on. The
> rest seems to be rather basic: fixing bugs (and things that are not
> bugs, like harmless integer overflows), implementing support for
> features that were decided and designed elsewhere.
> 
> And it is not just that it is not happening: there is genuine opposition
> to creativity: things that are not already justified externally, things
> that do not look like well-known patterns, are met with scepticism and
> eventually rejected.
> 
> At this point, we should ask ourselves:
> 
> Is it what we want the project to be, or is it just what we have let it
> become?
> 
> I do not think this evolution is the result of a deliberate choice. I
> think it is more the result of the stress of success and the stress of a
> fork. Success can stifle creativity, because creativity implies the risk
> of failure: the project has become advert to risk.
> 
> It has evolved that way, but are we fine with it?
> 
> I personally am not.
> 
> I find the new ambiance boring.
> 
> Creativity is the reason I practice development, and the reason I do not
> practice it professionally: my creativity cannot be put on a schedule.
> 
> My skills are not for micro-optimizing codec code: I cannot help on
> these tasks. If I am allowed to analyze this myself, I would say that my
> skills lie in general organization: making sure that the right code gets
> called at the right time, finding more convenient ways of doing tasks,
> etc.
> 
> I have several ideas for the project. Some are not directly related to
> multimedia at all; rather, the are invented for FFmpeg precisely, for
> FFmpeg's exact needs and ways of doing things. They relate to options
> and introspection, to inter-thread scheduling and asynchronous
> operation, to error reporting to the application, to handling of strings
> and serialization, to partial configurations of filters, to avoiding
> global state and allowing multiple instances, etc.
> 
> I have shown the first steps of some of my ideas (AVWriter a few months
> ago, avrefcount_template.h more recently), and the outcome was rather
> disheartening and discouraging: "it's too complex" (of course: I am
> putting all the complexity in one place so that the rest of the code can
> be simple, if you look at just that part it looks complex!), "why don't
> you just" do thing the usual way? (because I am trying to find a better
> way than the usual way.) It seems my fellow developers do not look beyond
> the immediate strangeness of the proposal to see the promised benefits,
> but remember: strangeness is just lack of familiarity, it goes away fast
> all by itself, and all that remains are the benefits.
> 
> These proposals would probably be better met if they were complete: if I
> proposed a patch series that eliminates escaping hell or gets
> non-blocking operation working all at once, it would be easier to get it
> accepted. But it is too big a task, especially with the rest of the code
> moving under my feet, with conflicts at each rebase.
> 
> Lacking that, they require a little trust: trust enough to look, beyond
> the immediate strangeness, where I am going and to try to see what I
> want to achieve, and see that it is achievable. But for now, I have seen
> more doubt and dismissal than trust and enthusiasm. And the projects are
> too big, I am not prepared to fight an uphill battle to get accepted
> every small step.
> 
> If I cannot express my creativity by developing for FFmpeg, I will find
> other projects, mine or existing, to express it. I suspect others have
> orbited away from the projects for similar reasons.
> 
> So, I ask one last time: What kind of project do you want FFmpeg to be?
> 
> Sorry for the interruption, you can resume your normal occupation.
> 
> Regards,

Just a few quick Saturday morning thoughts that don't cover your 

Re: [FFmpeg-devel] Project orientation

[James Almer]

On 7/4/2020 11:51 AM, Paul B Mahol wrote:
> On 7/4/20, Nicolas George  wrote:
>> Hi.
>>
>> When I first started progressively to contribute do FFmpeg, the project
>> was far from mature, but it was very much alive.
>>
>> There was attempts at implementing new and better codecs, directly in
>> lavc's code base. There were attempts at designing new formats with
>> useful features.
>>
>> Even outside the specialized work on specific codecs and formats, there
>> was creativity. At the API and framework level, there was work being
>> done to do things in a smarter way, either more convenient or more
>> efficient or both.
>>
>> For example, the format negotiation in liabvfilter (which was mostly
>> designed before I got involved: I am not singing my own praise here),
>> with its pointers to pointers to pointers, is not run-of-the-mill code.
>> Even if parts of it are made of common algorithms, the whole is very
>> specific to FFmpeg, and its design was creative. Creativity was
>> necessary later to extend it to support audio.
>>
>> Nowadays, not so much. There is work in making highly-optimized
>> decoders, this work is impressive and creative, there is no doubt about
>> it. But as far as I can see, that is mostly all there is going on. The
>> rest seems to be rather basic: fixing bugs (and things that are not
>> bugs, like harmless integer overflows), implementing support for
>> features that were decided and designed elsewhere.
>>
>> And it is not just that it is not happening: there is genuine opposition
>> to creativity: things that are not already justified externally, things
>> that do not look like well-known patterns, are met with scepticism and
>> eventually rejected.
>>
>> At this point, we should ask ourselves:
>>
>> Is it what we want the project to be, or is it just what we have let it
>> become?
>>
>> I do not think this evolution is the result of a deliberate choice. I
>> think it is more the result of the stress of success and the stress of a
>> fork. Success can stifle creativity, because creativity implies the risk
>> of failure: the project has become advert to risk.
>>
>> It has evolved that way, but are we fine with it?
>>
>> I personally am not.
>>
>> I find the new ambiance boring.
>>
>> Creativity is the reason I practice development, and the reason I do not
>> practice it professionally: my creativity cannot be put on a schedule.
>>
>> My skills are not for micro-optimizing codec code: I cannot help on
>> these tasks. If I am allowed to analyze this myself, I would say that my
>> skills lie in general organization: making sure that the right code gets
>> called at the right time, finding more convenient ways of doing tasks,
>> etc.
>>
>> I have several ideas for the project. Some are not directly related to
>> multimedia at all; rather, the are invented for FFmpeg precisely, for
>> FFmpeg's exact needs and ways of doing things. They relate to options
>> and introspection, to inter-thread scheduling and asynchronous
>> operation, to error reporting to the application, to handling of strings
>> and serialization, to partial configurations of filters, to avoiding
>> global state and allowing multiple instances, etc.
>>
>> I have shown the first steps of some of my ideas (AVWriter a few months
>> ago, avrefcount_template.h more recently), and the outcome was rather
>> disheartening and discouraging: "it's too complex" (of course: I am
>> putting all the complexity in one place so that the rest of the code can
>> be simple, if you look at just that part it looks complex!), "why don't
>> you just" do thing the usual way? (because I am trying to find a better
>> way than the usual way.) It seems my fellow developers do not look beyond
>> the immediate strangeness of the proposal to see the promised benefits,
>> but remember: strangeness is just lack of familiarity, it goes away fast
>> all by itself, and all that remains are the benefits.
>>
>> These proposals would probably be better met if they were complete: if I
>> proposed a patch series that eliminates escaping hell or gets
>> non-blocking operation working all at once, it would be easier to get it
>> accepted. But it is too big a task, especially with the rest of the code
>> moving under my feet, with conflicts at each rebase.
>>
>> Lacking that, they require a little trust: trust enough to look, beyond
>> the immediate strangeness, where I am going and to try to see what I
>> want to achieve, and see that it is achievable. But for now, I have seen
>> more doubt and dismissal than trust and enthusiasm. And the projects are
>> too big, I am not prepared to fight an uphill battle to get accepted
>> every small step.
>>
>> If I cannot express my creativity by developing for FFmpeg, I will find
>> other projects, mine or existing, to express it. I suspect others have
>> orbited away from the projects for similar reasons.
>>
>> So, I ask one last time: What kind of project do you want FFmpeg to be?
> 
> Certainly one where you are not part 

Re: [FFmpeg-devel] Project orientation

[Paul B Mahol]

On 7/4/20, Nicolas George  wrote:
> Hi.
>
> When I first started progressively to contribute do FFmpeg, the project
> was far from mature, but it was very much alive.
>
> There was attempts at implementing new and better codecs, directly in
> lavc's code base. There were attempts at designing new formats with
> useful features.
>
> Even outside the specialized work on specific codecs and formats, there
> was creativity. At the API and framework level, there was work being
> done to do things in a smarter way, either more convenient or more
> efficient or both.
>
> For example, the format negotiation in liabvfilter (which was mostly
> designed before I got involved: I am not singing my own praise here),
> with its pointers to pointers to pointers, is not run-of-the-mill code.
> Even if parts of it are made of common algorithms, the whole is very
> specific to FFmpeg, and its design was creative. Creativity was
> necessary later to extend it to support audio.
>
> Nowadays, not so much. There is work in making highly-optimized
> decoders, this work is impressive and creative, there is no doubt about
> it. But as far as I can see, that is mostly all there is going on. The
> rest seems to be rather basic: fixing bugs (and things that are not
> bugs, like harmless integer overflows), implementing support for
> features that were decided and designed elsewhere.
>
> And it is not just that it is not happening: there is genuine opposition
> to creativity: things that are not already justified externally, things
> that do not look like well-known patterns, are met with scepticism and
> eventually rejected.
>
> At this point, we should ask ourselves:
>
> Is it what we want the project to be, or is it just what we have let it
> become?
>
> I do not think this evolution is the result of a deliberate choice. I
> think it is more the result of the stress of success and the stress of a
> fork. Success can stifle creativity, because creativity implies the risk
> of failure: the project has become advert to risk.
>
> It has evolved that way, but are we fine with it?
>
> I personally am not.
>
> I find the new ambiance boring.
>
> Creativity is the reason I practice development, and the reason I do not
> practice it professionally: my creativity cannot be put on a schedule.
>
> My skills are not for micro-optimizing codec code: I cannot help on
> these tasks. If I am allowed to analyze this myself, I would say that my
> skills lie in general organization: making sure that the right code gets
> called at the right time, finding more convenient ways of doing tasks,
> etc.
>
> I have several ideas for the project. Some are not directly related to
> multimedia at all; rather, the are invented for FFmpeg precisely, for
> FFmpeg's exact needs and ways of doing things. They relate to options
> and introspection, to inter-thread scheduling and asynchronous
> operation, to error reporting to the application, to handling of strings
> and serialization, to partial configurations of filters, to avoiding
> global state and allowing multiple instances, etc.
>
> I have shown the first steps of some of my ideas (AVWriter a few months
> ago, avrefcount_template.h more recently), and the outcome was rather
> disheartening and discouraging: "it's too complex" (of course: I am
> putting all the complexity in one place so that the rest of the code can
> be simple, if you look at just that part it looks complex!), "why don't
> you just" do thing the usual way? (because I am trying to find a better
> way than the usual way.) It seems my fellow developers do not look beyond
> the immediate strangeness of the proposal to see the promised benefits,
> but remember: strangeness is just lack of familiarity, it goes away fast
> all by itself, and all that remains are the benefits.
>
> These proposals would probably be better met if they were complete: if I
> proposed a patch series that eliminates escaping hell or gets
> non-blocking operation working all at once, it would be easier to get it
> accepted. But it is too big a task, especially with the rest of the code
> moving under my feet, with conflicts at each rebase.
>
> Lacking that, they require a little trust: trust enough to look, beyond
> the immediate strangeness, where I am going and to try to see what I
> want to achieve, and see that it is achievable. But for now, I have seen
> more doubt and dismissal than trust and enthusiasm. And the projects are
> too big, I am not prepared to fight an uphill battle to get accepted
> every small step.
>
> If I cannot express my creativity by developing for FFmpeg, I will find
> other projects, mine or existing, to express it. I suspect others have
> orbited away from the projects for similar reasons.
>
> So, I ask one last time: What kind of project do you want FFmpeg to be?

Certainly one where you are not part of it.

>
> Sorry for the interruption, you can resume your normal occupation.
>
> Regards,
>
> --
>   Nicolas George
>