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 FF
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 githu
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 ne
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 discuss
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 b
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 glitche
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 cli
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-Bap
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
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
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
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 a
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 so
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, "
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 t
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.
N
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
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
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
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 c
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 le
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 we
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.
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 cor
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
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
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 orienttati
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
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 i
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
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
> 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 c
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 m
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 a
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
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
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 butto
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 se
> 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 t
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 develope
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 mai
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 compl
> -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.
> >
&g
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
> -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.
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&g
> -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, 202
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
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 wh
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 contributor
> -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:
> > >
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 amoun
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 o
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
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 t
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
> *
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 gre
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
s
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
> > 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 kn
> 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 tr
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 m
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
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
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 en
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
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
>
> 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
>
> > 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.
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
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:
> > > > >
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 K
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
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
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
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 tenso
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 th
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
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 an
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.
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."
--
> -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 parti
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
> > "winni
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
>
> 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 he
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. Th
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 des
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'
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 f
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
90 matches
Mail list logo
