Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Sat, 10 Dec 2016 11:28:07 +0100
Carl Eugen Hoyos  wrote:

> 2016-12-08 15:53 GMT+01:00 wm4 :
> > advanced hardware transcoding (I'm still waiting for related
> > work to be merged from Libav).  
> 
> Didn't you tell the responsible developer not to send his patches
> here implying you did not want them committed to FFmpeg?

The answer to that is "no".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-12-08 15:53 GMT+01:00 wm4 :
> advanced hardware transcoding (I'm still waiting for related
> work to be merged from Libav).

Didn't you tell the responsible developer not to send his patches
here implying you did not want them committed to FFmpeg?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Andreas Cadhalpun]

On 09.12.2016 10:26, wm4 wrote:
> On Fri, 9 Dec 2016 00:30:24 +0100
> Andreas Cadhalpun  wrote:
> 
>> On 08.12.2016 15:53, wm4 wrote:
>>> (I'm still waiting for related work to be merged from Libav).  
>>
>> Why don't you merge it yourself instead of waiting for others?
> 
> The commit to be merged next appears to have some intrusive h264 decoder
> changes. I'm not going to touch that.

You could skip that commit and mention it in the TODO/FIXME/UNMERGED
section of doc/libav-merge.txt.

>>> So yes, removing things can mean progress.  
>>
>> However, removing ffserver now doesn't, because the libraries
>> have to keep backwards-compatibility until the next major bump
>> anyway.
> 
> I'd agree with this, except I know that if the time comes for a major
> bump that necessitates immediate removal of ffserver, a new discussion
> about ffserver will break out, and the bump (or removal of the
> deprecated things ffserver relies on) would be delayed.

Prediction is very difficult, especially about the future.

> If this is how development work (maybe it does, maybe it doesn't), then
> shitflinging is an inherent part of the project's developer culture and
> the only way to achieve something. Blergh.

According to our code of conduct this should not be part of FFmpeg's
developer culture.

> Maybe this is not a problem anymore. ffserver.c still brings up some
> deprecation warnings, but surely michaelni will send a patch soon to
> fix those.

I wouldn't be so sure about that, as these warnings aren't particularly
urgent and other parts of the code base produce similar warnings.

> This discussion is worth leading in general anyway.
> 
>>> Nobody would care if ffserver actually used the ffmpeg libs correctly.
>>> But it still requires ffserver-specific code in libavformat. And even
>>> after all of michaelni's oddly-timed hard work to cleanup ffserver,
>>> ffserver itself uses internal libavformat stuff (see
>>> libavformat/libavformat.v - it also includes internal headers).  
>>
>> Yes, that's the last point that needs to be fixed before the next
>> major bump if ffserver is to be kept.
> 
> I didn't check whether the internal libavformat would break ffserver on
> the next bump,

If these symbols get removed from libavformat/libavformat.v and are thus
not exported in the shared library anymore, ffserver can't use them
(except when linked statically).

> or if there are other hidden internal or deprecated API uses, but yeah.

Since there is now ffservertest it should be easy to check if something
important breaks when the major bump happens.

>>> This project is frustrating because it puts features (even broken,
>>> half-implemented ones) over robust implementation and ease of use, and
>>> on top of it is unable to enforce any policy or decisions the community
>>> may have made. You have to waste your time discussing about nothing to
>>> overly... self-confident... people when trying to make a change.  
>>
>> You don't have to waste everyone's time complaining like that.
>> It'd be much better if you'd instead spend the time working on reducing
>> the backlog in the merges from Libav.
> 
> I could as well say: you don't have to waste everyone's time defending
> ffserver,

That's not an accurate description of my position[1] on this.

> you could just spend time on fixing it instead.

That's exactly what I did. [2][3][4]

> You don't have to say anything about the general way ffmpeg development
> works?

It mainly works by sending patches to the mailing list, where they are
discussed based on technical arguments.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203575.html
2: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203672.html
3: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203670.html
4: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203671.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Fri, 9 Dec 2016 00:30:24 +0100
Andreas Cadhalpun  wrote:

> On 08.12.2016 15:53, wm4 wrote:
> > (I'm still waiting for related work to be merged from Libav).  
> 
> Why don't you merge it yourself instead of waiting for others?

The commit to be merged next appears to have some intrusive h264 decoder
changes. I'm not going to touch that.

> > So yes, removing things can mean progress.  
> 
> However, removing ffserver now doesn't, because the libraries
> have to keep backwards-compatibility until the next major bump
> anyway.

I'd agree with this, except I know that if the time comes for a major
bump that necessitates immediate removal of ffserver, a new discussion
about ffserver will break out, and the bump (or removal of the
deprecated things ffserver relies on) would be delayed. If this is how
development work (maybe it does, maybe it doesn't), then shitflinging
is an inherent part of the project's developer culture and the only way
to achieve something. Blergh.

Maybe this is not a problem anymore. ffserver.c still brings up some
deprecation warnings, but surely michaelni will send a patch soon to
fix those.

This discussion is worth leading in general anyway.

> > Nobody would care if ffserver actually used the ffmpeg libs correctly.
> > But it still requires ffserver-specific code in libavformat. And even
> > after all of michaelni's oddly-timed hard work to cleanup ffserver,
> > ffserver itself uses internal libavformat stuff (see
> > libavformat/libavformat.v - it also includes internal headers).  
> 
> Yes, that's the last point that needs to be fixed before the next
> major bump if ffserver is to be kept.

I didn't check whether the internal libavformat would break ffserver on
the next bump, or if there are other hidden internal or deprecated API
uses, but yeah.

> > This project is frustrating because it puts features (even broken,
> > half-implemented ones) over robust implementation and ease of use, and
> > on top of it is unable to enforce any policy or decisions the community
> > may have made. You have to waste your time discussing about nothing to
> > overly... self-confident... people when trying to make a change.  
> 
> You don't have to waste everyone's time complaining like that.
> It'd be much better if you'd instead spend the time working on reducing
> the backlog in the merges from Libav.

I could as well say: you don't have to waste everyone's time defending
ffserver, you could just spend time on fixing it instead.

You don't have to say anything about the general way ffmpeg development
works?

> The next bump, which is already discussed on the Libav mailing list, will
> be merged that much sooner.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Andreas Cadhalpun]

On 08.12.2016 15:53, wm4 wrote:
> (I'm still waiting for related work to be merged from Libav).

Why don't you merge it yourself instead of waiting for others?

> So yes, removing things can mean progress.

However, removing ffserver now doesn't, because the libraries
have to keep backwards-compatibility until the next major bump
anyway.

> Nobody would care if ffserver actually used the ffmpeg libs correctly.
> But it still requires ffserver-specific code in libavformat. And even
> after all of michaelni's oddly-timed hard work to cleanup ffserver,
> ffserver itself uses internal libavformat stuff (see
> libavformat/libavformat.v - it also includes internal headers).

Yes, that's the last point that needs to be fixed before the next
major bump if ffserver is to be kept.

> This project is frustrating because it puts features (even broken,
> half-implemented ones) over robust implementation and ease of use, and
> on top of it is unable to enforce any policy or decisions the community
> may have made. You have to waste your time discussing about nothing to
> overly... self-confident... people when trying to make a change.

You don't have to waste everyone's time complaining like that.
It'd be much better if you'd instead spend the time working on reducing
the backlog in the merges from Libav.
The next bump, which is already discussed on the Libav mailing list, will
be merged that much sooner.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Thu, 8 Dec 2016 16:33:20 +0100
Nicolas George  wrote:

> L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> > I explained it. Read it.  
> 
> It prooves you still do not understand the principle.

You've demonstrated the complete inability to counter my arguments.
Maybe you didn't even understand them (hey I can do it too).

If you have nothing to say, then don't block progress.

> Fortunately, the others do.

Who?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> I explained it. Read it.

It prooves you still do not understand the principle.

Fortunately, the others do.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Thu, 8 Dec 2016 16:02:18 +0100
Nicolas George  wrote:

> L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> > 3. It's entangled with the rest of the project and stops people from
> > doing useful work.  
> 
> If it does not prevent build failures and is not present in the normal
> execution path, what does it even MEANS? Nothing!

I explained it. Read it.

> >   Proof: Libav.  
> 
> Well, so long and thanks for all the code.

What is that even supposed to mean? Surely you welcome all the
important features coming in from Libav.

> > >   1. Make an honest attempt at fixing it yourself. Emphasis on the word
> > >  "honest".  
> > So "we" are supposed to fix ffserver? This is where feature bloat slows
> > down development.  
> 
> I see that the word "honest" was lost on you.

Oh, I had a look at ffserver too. From what I understood (and others
did), it required access to the decoder/encoder from within the
demuxer. This is something the new API fundamentally does not allow
(for the better, I can explain in detail why that's better). It seemed
unfixable. People who actually sent patches were seemingly not able to
fix this either. I'm sure you don't want to call them all dishonest or
maybe even incompetent?

Only recently michaelni fixed it (with very odd timing).

Anyway, it seems much, much more was lost on you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> 3. It's entangled with the rest of the project and stops people from
> doing useful work.

If it does not prevent build failures and is not present in the normal
execution path, what does it even MEANS? Nothing!

> Proof: Libav.

Well, so long and thanks for all the code.

> >   1. Make an honest attempt at fixing it yourself. Emphasis on the word
> >  "honest".
> So "we" are supposed to fix ffserver? This is where feature bloat slows
> down development.

I see that the word "honest" was lost on you.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Wed, 7 Dec 2016 19:29:58 +0100
Nicolas George  wrote:

> Le quintidi 15 frimaire, an CCXXV, Rostislav Pehlivanov a écrit :
> > I need more time to decide.  
> 
> You supported dropping ffserver since before the vote started, and now
> you are hesitating? Seriously?
> 
> Arriving at the last minute when it became obvious the tide turned to
> ensure a longer delay. Where did I see that? This whole circus is
> looking more and more like the libmpcodec travesty.
> 
> Let us see where we are:
> 
> dropJames Almer
> dropPaul B Mahol
> dropRonald S. Bultje (slightly invalid)
> 
> keepAndreas Cadhalpun
> keepMarton Balint
> keepMichael Niedermayer (slightly invalid)
> keepNicolas George
> keepReynaldo H. Verdejo Pinochet (slightly invalid)
> 
> spoilt  wm4 

Incorrect.

> blank   Lukasz Marek
> 
> Well, for now, you cannot remove ffserver. You can continue discussing
> if you want.
> 
> For the people who want to actually move forward, I suggest the
> following guidelines:
> 
> For any fringe component of the project, ffserver or anything that shows
> the same issues in the future:
> 
> - There is a problem if, during the course of development, either:
> 
>   1. the component is present in the default execution path of the
>  important tools (at probing, for example) and that causes execution
>  bugs;
> 
>   2. the component causes a compilation failure with default /
>  reasonable options.

3. It's entangled with the rest of the project and stops people from
doing useful work.

It's awesome how you just ignore this point. I'll give you the benefit
of the doubt and will just assume that you actually don't know why we
want to remove ffserver.

Removing unneeded stuff works much better for development as keeping
everything forever. Proof: Libav. Without Libav, FFmpeg would still
have no reference counted AVFrames, no simple way to do direct rendering
(look at the old now-removed code ffmpeg.c used to enable direct
rendering with libavfilter - it was horrible), advanced hardware
transcoding (I'm still waiting for related work to be merged from
Libav).

So yes, removing things can mean progress.

> - If there is no such problem, leave it alone and get working on
>   something useful!

Nobody would care if ffserver actually used the ffmpeg libs correctly.
But it still requires ffserver-specific code in libavformat. And even
after all of michaelni's oddly-timed hard work to cleanup ffserver,
ffserver itself uses internal libavformat stuff (see
libavformat/libavformat.v - it also includes internal headers).

> - If you are hit by one such problem, then:
> 
>   1. Make an honest attempt at fixing it yourself. Emphasis on the word
>  "honest".

So "we" are supposed to fix ffserver? This is where feature bloat slows
down development.

I think those who want to keep a feature should work for it. Where are
YOUR patches to fix ffserver anyway?

>   2. If that proves impossible, post the description of the problem on
>  the mailing-list and demand the maintainers to fix it. If necessary
>  (depending on the urgency of your own development, the availability
>  of the developers), set an ultimatum, even with a short deadline.

This was done. The deadline was even extended. Nobody made any notable
progress. The promise that ffserver would get fixed in time was
disappointed. This is why we call for moving ffserver out of the
master branch so we can go on.

Only michaelni has made significant progress on fixing parts of it
recently (after having watched from the sides for months).

>   3. If the ultimatum expires, disable the component. Disable, not
>  remove: that is what requires the least amount of work from you,
>  and also what will require the least amount of work from the
>  maintainer later.

We ALREADY announced ffserver removal for the current release (and then
delayed it).

What you demand all already happened. What a joke.

>   4. If the component has been disabled for some time, then we can
>  discuss removing it.

We've discussed it for months. Where the were you?

I guess if you'd actually made any sense, you'd advocate disabling
ffserver NOW.

> The short version of it is:
> 
> If you do not LIKE a component, IGNORE it but do not HATE it.

It's hard to ignore something if it hinders your progress. Do you think
we started about talking removing ffserver just because we wanted to
be mean?

> Hate is what spoils the ambiance in projects.

This project is frustrating because it puts features (even broken,
half-implemented ones) over robust implementation and ease of use, and
on top of it is unable to enforce any policy or decisions the community
may have made. You have to waste your time discussing about nothing to
overly... self-confident... people when trying to make a change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/7/2016 3:45 PM, Carl Eugen Hoyos wrote:
> 2016-12-05 16:03 GMT+01:00 James Almer :
> 
>>> Which reasons were not adressed?
>>
>> <@wbs>
> 
> I am unfortunately unable to express how offensive and mean I
> consider your answer.

Thanks for not expressing it. I'm not interested in hearing about your
personal grudges in the slightest.

> It's really extraordinarily disappointing.

You wanted technical reasons that remain to be addressed, i gave them
to you.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

Le septidi 17 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> I believe you missed Carl Eugen's vote (or at least I read it as a vote):
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203915.html

Indeed, thanks for noticing. I belive it counts as "keep (slightly
invalid)".

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Ronald S. Bultje]

Hi,

On Wed, Dec 7, 2016 at 1:29 PM, Nicolas George  wrote:

> keepAndreas Cadhalpun
> keepMarton Balint
> keepMichael Niedermayer (slightly invalid)
> keepNicolas George
> keepReynaldo H. Verdejo Pinochet (slightly invalid)


I believe you missed Carl Eugen's vote (or at least I read it as a vote):
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-December/203915.html

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-12-05 16:03 GMT+01:00 James Almer :

>> Which reasons were not adressed?
>
> <@wbs>

I am unfortunately unable to express how offensive and mean I
consider your answer.
It's really extraordinarily disappointing.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

Le quintidi 15 frimaire, an CCXXV, Rostislav Pehlivanov a écrit :
> I need more time to decide.

You supported dropping ffserver since before the vote started, and now
you are hesitating? Seriously?

Arriving at the last minute when it became obvious the tide turned to
ensure a longer delay. Where did I see that? This whole circus is
looking more and more like the libmpcodec travesty.

Let us see where we are:

dropJames Almer
dropPaul B Mahol
dropRonald S. Bultje (slightly invalid)

keepAndreas Cadhalpun
keepMarton Balint
keepMichael Niedermayer (slightly invalid)
keepNicolas George
keepReynaldo H. Verdejo Pinochet (slightly invalid)

spoilt  wm4 
blank   Lukasz Marek

Well, for now, you cannot remove ffserver. You can continue discussing
if you want.

For the people who want to actually move forward, I suggest the
following guidelines:

For any fringe component of the project, ffserver or anything that shows
the same issues in the future:

- There is a problem if, during the course of development, either:

  1. the component is present in the default execution path of the
 important tools (at probing, for example) and that causes execution
 bugs;

  2. the component causes a compilation failure with default /
 reasonable options.

- If there is no such problem, leave it alone and get working on
  something useful!

- If you are hit by one such problem, then:

  1. Make an honest attempt at fixing it yourself. Emphasis on the word
 "honest".

  2. If that proves impossible, post the description of the problem on
 the mailing-list and demand the maintainers to fix it. If necessary
 (depending on the urgency of your own development, the availability
 of the developers), set an ultimatum, even with a short deadline.

  3. If the ultimatum expires, disable the component. Disable, not
 remove: that is what requires the least amount of work from you,
 and also what will require the least amount of work from the
 maintainer later.

  4. If the component has been disabled for some time, then we can
 discuss removing it.

The short version of it is:

If you do not LIKE a component, IGNORE it but do not HATE it.

Hate is what spoils the ambiance in projects.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Rostislav Pehlivanov]

On 5 Dec 2016 6:45 a.m., "wm4"  wrote:

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
>
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
>
> I support the decision. Pros:
>
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
>
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
>
> A decision was made, a project should stick to it stubbornly.
>
> Regards,
>

I need more time to decide.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Me too, I'm not sure now because IMO fixing it would be better and it
started getting attention now
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/5/2016 11:45 AM, Carl Eugen Hoyos wrote:
> 2016-12-05 15:23 GMT+01:00 James Almer :
>> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 21:53 GMT+01:00 James Almer :
 On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>>>
>> He's trying to override an announced project decision of removing a 
>> feature.
>
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.

 That's not what was announced, at all. Please, read the news entry in 
 question
 and inform yourself in the subject before trying to participate in a 
 discussion.
>>>
>>> That is exactly what I would like you to do.
>>> What else would have been the reason for the announcement?
>>
>> How about you actually *try* reading the news entry, instead of passing the
>> ball? You might just find out if you do it carefully and pay attention to
>> each sentence. Especially the part where it invites people to write a
>> replacement, and says nothing about voiding the decision if "issues are
>> fixed".
> 
> You misunderstand:
> I did not claim that the news entry says that the issues should be fixed,
> I wrote that the only reasonable base on which the entry was written is
> imo the search for somebody to fix the issues.

That's an odd interpretation of a news entry consisting on very few, very
clear paragraphs, and ending with a sentence that goes completely against
said interpretation.

> 
> Or are you arguing that ffserver should be removed because some
> developers don't like it?
> 
>>> I believe that it is absolutely unacceptable to remove a used feature of
>>> FFmpeg without a technical reason and I therefore believe that this
>>> vote does not make much sense.
>>
>> The technical reasons are there, described in the news entry you seem to
>> not want to read, or at least properly parse.
>> These past week however saw one developer working against the clock doing
>> what the actual people interested in ffserver should have done for the past
>> few months and even years. That is, he addressed most, but not all, of those
>> and other reasons.
> 
> Which reasons were not adressed?

<@wbs> I don't think it's still "fixed" in the sense that ffserver and ffmpeg 
can be built from differing major versions
<@wbs> since it sends literal enum values over the wire, and those enum values 
are free to be changed at any major bump 
<@wbs> and also, it doesn't even specify which major version it is talking 
about in the protocol
<@wbs> so api-wise it might be "fixed"; design wise, not yet
<+wm4> so my question would be does ffserver always use ffm for input/output, 
require it only for one of them, or is it completely optional?
<@wbs> wm4: afaik both ffmpeg and ffserver uses ffm, so if ffmpeg were to be 
able to communicate with ffserver, it needs an ffm demuxer/muxer as well
<@wbs> wm4: and it's all pretty backwards compare to most other protocols; if 
ffmpeg is to send data to ffserver, ffserver first tells it what codecs and 
encoder parameters to use, and then switches(?) communication direction to 
ffmpeg sending, ffserver receiving
<+wm4> huh
<@wbs> all of this is custom code in ffmpeg.c ofc
<+wm4> lol really?
<+wm4> so ffmpeg.c has explicit ffserver handling, outside of the ffm 
libavformat parts?
<@wbs> yes
<@wbs> see ffmpeg_opt.c, read_ffserver_streams etc
<@wbs> was the first I found with a quick grep
<+wm4> ah
<@wbs> so yes, it no longer uses deprecated api (avstream->avcodeccontext), but 
it still uses a bunch of networking internals from lavf, and the design is 
buried deep in ffmpeg
<+wm4> just looked at ffserver.c
<+wm4> #include "libavformat/avio_internal.h"
<+wm4> ...yeah
<+wm4> even #include "libavformat/internal.h"
<@wbs> and it uses a bunch of internal rtp/udp functions that don't fit in in 
the normal avio/urlprotocol api
<@wbs> so it's not "fixed" yet. one of the deprecated details in codecpar might 
be worked around

Also, the part about "confusing configuration file syntax", but i guess that
can be considered subjective.

> 
>> You and Nicolas sure love your historical revisionism.
> 
> I am sure you know that I was strongly against adding mailing list rules.
> But if you continue calling people names in this thread, I suggest you go
> elsewhere.

Saying you and Nicolas are ignoring events (or rewriting history) to support you
position on this subject is not name calling.

And i suggest you go hunt instead the people that actually called others names.
I pointed them to you in a previous email.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Ronald S. Bultje]

Hi,

On Mon, Dec 5, 2016 at 9:45 AM, Carl Eugen Hoyos  wrote:

> 2016-12-05 15:23 GMT+01:00 James Almer :
> > The technical reasons are there, described in the news entry you seem to
> > not want to read, or at least properly parse.
> > These past week however saw one developer working against the clock doing
> > what the actual people interested in ffserver should have done for the
> past
> > few months and even years. That is, he addressed most, but not all, of
> those
> > and other reasons.
>
> Which reasons were not adressed?


ffm is a pretty important one?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-12-05 15:23 GMT+01:00 James Almer :
> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
>> 2016-11-29 21:53 GMT+01:00 James Almer :
>>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
 2016-11-29 21:11 GMT+01:00 James Almer :
>>
> He's trying to override an announced project decision of removing a 
> feature.

 We - obviously - announced it to find somebody who would fix the issues
 raised. If they are fixed, the "decision" is of course void, and we don't
 have to vote about it.
>>>
>>> That's not what was announced, at all. Please, read the news entry in 
>>> question
>>> and inform yourself in the subject before trying to participate in a 
>>> discussion.
>>
>> That is exactly what I would like you to do.
>> What else would have been the reason for the announcement?
>
> How about you actually *try* reading the news entry, instead of passing the
> ball? You might just find out if you do it carefully and pay attention to
> each sentence. Especially the part where it invites people to write a
> replacement, and says nothing about voiding the decision if "issues are
> fixed".

You misunderstand:
I did not claim that the news entry says that the issues should be fixed,
I wrote that the only reasonable base on which the entry was written is
imo the search for somebody to fix the issues.

Or are you arguing that ffserver should be removed because some
developers don't like it?

>> I believe that it is absolutely unacceptable to remove a used feature of
>> FFmpeg without a technical reason and I therefore believe that this
>> vote does not make much sense.
>
> The technical reasons are there, described in the news entry you seem to
> not want to read, or at least properly parse.
> These past week however saw one developer working against the clock doing
> what the actual people interested in ffserver should have done for the past
> few months and even years. That is, he addressed most, but not all, of those
> and other reasons.

Which reasons were not adressed?

> You and Nicolas sure love your historical revisionism.

I am sure you know that I was strongly against adding mailing list rules.
But if you continue calling people names in this thread, I suggest you go
elsewhere.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision. Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
> 
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
> 
> A decision was made, a project should stick to it stubbornly.
> 
> Regards,
> 

I need more time to decide.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/28/2016 3:15 PM, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

As asked before, what would be the deadline? 3.3 or next major bump?

There are still some unsolved technical problems, even after Michael
fixed years of complains alone in one week. So at the current state,
even with this vote passing ffserver will still be scheduled for
removal in an upcoming release.

In any case, I confirm I'm against this motion to revoke the decision.
I have stated the reasons why i still want the current course of action
to remain as such more than once in the other thread.
I'm not going to repeat myself, and I'm pretty much done being ganged
up on, insulted and fallaciously threatened with the CoC by people here.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:53 GMT+01:00 James Almer :
>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 21:11 GMT+01:00 James Almer :
> 
 He's trying to override an announced project decision of removing a 
 feature.
>>>
>>> We - obviously - announced it to find somebody who would fix the issues
>>> raised. If they are fixed, the "decision" is of course void, and we don't
>>> have to vote about it.
>>
>> That's not what was announced, at all. Please, read the news entry in 
>> question
>> and inform yourself in the subject before trying to participate in a 
>> discussion.
> 
> That is exactly what I would like you to do.
> What else would have been the reason for the announcement?

How about you actually *try* reading the news entry, instead of passing the
ball? You might just find out if you do it carefully and pay attention to
each sentence. Especially the part where it invites people to write a
replacement, and says nothing about voiding the decision if "issues are
fixed".

> 
> I believe that it is absolutely unacceptable to remove a used feature of
> FFmpeg without a technical reason and I therefore believe that this
> vote does not make much sense.

The technical reasons are there, described in the news entry you seem to
not want to read, or at least properly parse.
These past week however saw one developer working against the clock doing
what the actual people interested in ffserver should have done for the past
few months and even years. That is, he addressed most, but not all, of those
and other reasons.

You and Nicolas sure love your historical revisionism.

> In any case, I am - still - all for keeping ffserver.
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-11-29 21:53 GMT+01:00 James Almer :
> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
>> 2016-11-29 21:11 GMT+01:00 James Almer :

>>> He's trying to override an announced project decision of removing a feature.
>>
>> We - obviously - announced it to find somebody who would fix the issues
>> raised. If they are fixed, the "decision" is of course void, and we don't
>> have to vote about it.
>
> That's not what was announced, at all. Please, read the news entry in question
> and inform yourself in the subject before trying to participate in a 
> discussion.

That is exactly what I would like you to do.
What else would have been the reason for the announcement?

I believe that it is absolutely unacceptable to remove a used feature of
FFmpeg without a technical reason and I therefore believe that this
vote does not make much sense.
In any case, I am - still - all for keeping ffserver.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Reynaldo H. Verdejo Pinochet]

I support the decision to keep ffserver

Bests,

--
Reynaldo H. Verdejo Pinochet
Open Source Group - Samsung Research America

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Andreas Cadhalpun]

On 28.11.2016 19:15, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision.

I support the decision, too.

> Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.

Also 'make ffservertest' covers libavformat/tcp.c, which no other FATE
test does.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Marton Balint]

On Mon, 28 Nov 2016, Nicolas George wrote:


Deadline: 2016-12-06 00:00 UTC.

I propose, and put to the discussion, that the decision to drop ffserver
is revoked, conditioned to the fixing of the technical issues that lead
to it.



I vote for keeping ffserver, as there are people working on it and keeping 
it (for the moment) does not block other development efforts.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Sat, Dec 03, 2016 at 03:11:33PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> > Deadline: 2016-12-06 00:00 UTC.
> > 
> > I propose, and put to the discussion, that the decision to drop ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> > 
> > In other words, if the technical problems that require dropping ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
> > 
> > I support the decision. Pros:
> > 
> > ffserver has users, if there are no reason to drop it, doing so is a
> > gratuitous annoyance to them.
> > 
> > Apparently James Almer opposes the decision. Cons, if I understand
> > correctly:
> > 
> > A decision was made, a project should stick to it stubbornly.
> 
> I vote for treating all the applications equally.
> I vote for reverting any code removial decission when the reasons for
> the removial no longer apply

Ive been told on IRC:
 michaelni: I really don’t think it helps the vote to open discussions on 
unrelated topics in that very thread
 michaelni: I’d recommend to open a discussion into these questions in a 
new email thread

I agree that would make sense, i think someone else should
start this discussion though.


 michaelni: and then clearly specify your vote in your email, right now 
you’re saying something about treating applications equally, I think I know 
what you mean but in a legal sense, your vote would be declared invalid if this 
was a regular parliamentary election
 just say “I’d like to keep ffserver” (which is what I think you mean, but 
it’s very unclear), or “I’d prefer to get rid of ffserver”

I honestly dont think my vote was unclear, and there also is no
"I’d like to keep ffserver" option but let me also in addition vote
for "I’d like to keep ffserver" if that helps anyone count my vote

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision. Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
> 
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
> 
> A decision was made, a project should stick to it stubbornly.

I vote for treating all the applications equally.
I vote for reverting any code removial decission when the reasons for
the removial no longer apply


Now there are a few things around this that keep nagging me and
id like to comment on them. This list here is not so much me taking a
postion on things even though i have one on some of these points
than that id like to bring these aspects to peoples attention.

* Who can make "binding" decissions about some code ?
 I belive that is the maintainer of some code and the vote comittee.
 Has this actually happened in case of the refered decission to remove
 FFserver ?


* Everyone assumes there will be an API change, but in fact the API
 of FFmpeg is decided by the FFmpeg developers and there was no
 decission to make or not make such change. It may be likely but it is
 not certain.


* Should major changes that affect our users and us (like API
 changes) be discussed on the ffmpeg-devel ML before they are done.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Lukasz Marek]

On 28.11.2016 19:53, Lou Logan wrote:

On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:


ffserver has users


I don't know of any. Do you have an estimation of how many users there
may be? How much feedback has there been from these alleged users
regarding the removal plans?


I don't have an estimation, but some time ago I got emails from users 
directly into my email regarding some issues or asking for help. It was 
the time when I worked on config stuff of ffserver. I am not albe to 
tell you if it was 2, 3 or more, but there are some users for sure.


Regarding voting I will not vote, but arguing ffserver must be deleted, 
because it was decided basing on facts that may change soon is funny. Of 
course it is an important rule of the universe that in regular periods 
of time very determined person to delete something is spawned (or to 
block something), but being reasonable is also good rule of thumb :P



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Steven Liu]

2016-11-30 23:29 GMT+08:00 Nicolas George :

> Le nonidi 9 frimaire, an CCXXV, James Almer a écrit :
> > Seeing Nicolas is apparently very invested in ffserver, can we expect
> him to
> > maintain it, improve and extend it if it were to remain in the tree? Or
> is he
> > just fighting this fight to not remove code for the sake of not removing
> code,
> > and will forget about it and expect someone else to deal with it if it
> starts
> > bitrotting again?
>
> You admitted you did not care about ffserver, yet you spend an awful lot
> of time and energy fighting for its removal, probably as a matter of
> principle. Am I not allowed to do the same? Double standards much?
>
> I will take this opportunity to answer various points that lie all over
> the place in the thread.
>
> First, you complain that I called you a dictator. This was actually an
> argument, and if it was taken as anything else I apologize. At the time,
> you were trying to dictate what can be put to the vote. Democracy does
> not work that way. Nowhere in the voting rules is there anything
> preventing voting again and making a different decision. Just like any
> parliament can revoke a law passed by its predecessors.
>
> (As a side note, I would like to emphasize that no valid vote were cast
> yet.)
>
> Second, you complain that I called you a imbecile. That is not true. I
> called people who never change advice out of principle imbeciles. You, I
> think, are only misguided. Let me explain.
>
> Not changing advice as a matter of principle: imagine a doctor not
> changing the decided treatment when new symptoms arise? a general not
> changing the decided battle plans when new intelligence is known? a
> prosecutor not changing the decided plea when new evidence is found? How
> can any of these not be imbecile?
>
> And surely, if someone were to offer a huge sponsorship to keep ffserver
> in the project, including money, immediate good-quality patches for the
> most urgent problems and a full-time developer for the rest, you would
> at least consider changing your mind, would you not?
>
> Never ever changing one's mind, whatever the circumstances changes, is
> imbecile, there is no way around it. What you can argue, on the other
> hand, is that in this particular instance, the circumstances have not
> changed enough.
>
> Because it all boils down to this question: have the circumstances
> changed enough to warrant a change of advice?
>
> You and others think that no. I think they have. Let us discuss that.
>
> Some people argue that the recent patches fixing the most urgent
> problems were only submitted because of the deadline. Maybe it is true,
> I will no longer argue that point. But so what? How is it relevant?
> Developers have a limited time: they will work on what they think most
> urgent. A deadline change the urgency of things: of course, that will
> change the priorities of the developers. What did you expect?
>
> You, mostly, have argued that changing our mind would send a bad signal
> to the users community. I do not agree. The users community knows how
> Libre software works, they know we have limited manpower. I cannot
> imagine anybody criticizing a change in that direction. Everybody will
> agree that keeping it if it is possible is better than dropping it. Even
> those who do not care about ffserver, because they will remember that it
> can happen to a feature they care about just the same.
>
> If you are still not convinced, look at what happens in Linux: the
> kernel hackers spend their time changing their mind, deprecating a
> feature that was introduced two versions ago, and then undeprecating it
> on the next one, reimplementing something a different way, etc. Do
> people complain? Yes, they do, when the changes affect their workflow
> and they have to spend time to adapt.
>
> The same goes for Google. They are endlessly starting new projects,
> reattaching them to other projects, axing them, etc. Do people complain?
> Again: only when it affects them negatively.
>
> Keeping ffserver instead of dropping it does not affect anybody
> negatively.
>
> Now, to the technical questions.
>
> If ffserver is blocking or hindering the development of the rest of the
> project, and if the people who care about do not fix it soon enough,
> then dropping is acceptable. Setting a deadline for the fix is
> acceptable enough.
>
> As I understand things, ffserver used to access private APIs in a way
> that conflicts with merges from the fork, and the patches that were
> posted recently are enough to fix it. The reason to remove ffserver
> immediately is therefore gone. If it is not enough, then of course the
> previous paragraph still applies.
>
> Clément requested "zero internal API usage" and "FATE coverage". I agree
> that it should be the goal. But it should not be the condition for not
> removing it now. Otherwise, it feels like "do this change that I want
> right now, or I remove your code". We do not do that, it is 

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Nicolas George]

Le nonidi 9 frimaire, an CCXXV, James Almer a écrit :
> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree? Or is he
> just fighting this fight to not remove code for the sake of not removing code,
> and will forget about it and expect someone else to deal with it if it starts
> bitrotting again?

You admitted you did not care about ffserver, yet you spend an awful lot
of time and energy fighting for its removal, probably as a matter of
principle. Am I not allowed to do the same? Double standards much?

I will take this opportunity to answer various points that lie all over
the place in the thread.

First, you complain that I called you a dictator. This was actually an
argument, and if it was taken as anything else I apologize. At the time,
you were trying to dictate what can be put to the vote. Democracy does
not work that way. Nowhere in the voting rules is there anything
preventing voting again and making a different decision. Just like any
parliament can revoke a law passed by its predecessors.

(As a side note, I would like to emphasize that no valid vote were cast
yet.)

Second, you complain that I called you a imbecile. That is not true. I
called people who never change advice out of principle imbeciles. You, I
think, are only misguided. Let me explain.

Not changing advice as a matter of principle: imagine a doctor not
changing the decided treatment when new symptoms arise? a general not
changing the decided battle plans when new intelligence is known? a
prosecutor not changing the decided plea when new evidence is found? How
can any of these not be imbecile?

And surely, if someone were to offer a huge sponsorship to keep ffserver
in the project, including money, immediate good-quality patches for the
most urgent problems and a full-time developer for the rest, you would
at least consider changing your mind, would you not?

Never ever changing one's mind, whatever the circumstances changes, is
imbecile, there is no way around it. What you can argue, on the other
hand, is that in this particular instance, the circumstances have not
changed enough.

Because it all boils down to this question: have the circumstances
changed enough to warrant a change of advice?

You and others think that no. I think they have. Let us discuss that.

Some people argue that the recent patches fixing the most urgent
problems were only submitted because of the deadline. Maybe it is true,
I will no longer argue that point. But so what? How is it relevant?
Developers have a limited time: they will work on what they think most
urgent. A deadline change the urgency of things: of course, that will
change the priorities of the developers. What did you expect?

You, mostly, have argued that changing our mind would send a bad signal
to the users community. I do not agree. The users community knows how
Libre software works, they know we have limited manpower. I cannot
imagine anybody criticizing a change in that direction. Everybody will
agree that keeping it if it is possible is better than dropping it. Even
those who do not care about ffserver, because they will remember that it
can happen to a feature they care about just the same.

If you are still not convinced, look at what happens in Linux: the
kernel hackers spend their time changing their mind, deprecating a
feature that was introduced two versions ago, and then undeprecating it
on the next one, reimplementing something a different way, etc. Do
people complain? Yes, they do, when the changes affect their workflow
and they have to spend time to adapt.

The same goes for Google. They are endlessly starting new projects,
reattaching them to other projects, axing them, etc. Do people complain?
Again: only when it affects them negatively.

Keeping ffserver instead of dropping it does not affect anybody
negatively.

Now, to the technical questions.

If ffserver is blocking or hindering the development of the rest of the
project, and if the people who care about do not fix it soon enough,
then dropping is acceptable. Setting a deadline for the fix is
acceptable enough.

As I understand things, ffserver used to access private APIs in a way
that conflicts with merges from the fork, and the patches that were
posted recently are enough to fix it. The reason to remove ffserver
immediately is therefore gone. If it is not enough, then of course the
previous paragraph still applies.

Clément requested "zero internal API usage" and "FATE coverage". I agree
that it should be the goal. But it should not be the condition for not
removing it now. Otherwise, it feels like "do this change that I want
right now, or I remove your code". We do not do that, it is not an
acceptable practice in Libre software development.

I ask to all the people who want drop ffserver to sincerely think about
their reasons for dropping it. As long as it is not obstructing you, why
do you care? Why do you care if it is 

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Paul B Mahol]

On 11/29/16, Carl Eugen Hoyos  wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>>
 Seeing Nicolas is apparently very invested in ffserver, can we expect
 him to
 maintain it, improve and extend it if it were to remain in the tree?
>>>
>>> How is this related?
>>> For which part of FFmpeg can we "expect" anybody to maintain it?
>>
>> He's trying to override an announced project decision of removing a
>> feature.
>
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.
> (We could vote to overturn our decision although there are still
> issues.)
>
>> If he has no interest in making sure said feature doesn't go back to the
>> state that prompted its removal, then he's simply trying to force the
>> project
>> to keep code someone else will have to deal with.
>>
>> It would make much more sense in that case if the actual person interested
>> and
>> willing to deal with the code to be behind these decision revoking
>> attempts.
>>
>>>
 Or is he just fighting this fight to not remove code for the sake of
 not removing code, and will forget about it and expect someone
 else to deal with it if it starts bitrotting again?
>>>
>>> This is a violation of our code-of-conduct or do I misunderstand you?
>>
>> How so? If he's not going to maintain the code he's campaigning to keep in
>> place, then he obviously expects someone else will, right? How is stating
>> that a violation of the CoC?
>
> I am not a native speaker but this is not how I read your accusation.
> "is he just fighting the fight to not remove code for the sake of not
> removing code" sounds to me as if you are not assuming good faith.

And your assumption that James doesn't act in good faith is also then violation
of CoC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 21:11 GMT+01:00 James Almer :
>> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>>
 Seeing Nicolas is apparently very invested in ffserver, can we expect him 
 to
 maintain it, improve and extend it if it were to remain in the tree?
>>>
>>> How is this related?
>>> For which part of FFmpeg can we "expect" anybody to maintain it?
>>
>> He's trying to override an announced project decision of removing a feature.
> 
> We - obviously - announced it to find somebody who would fix the issues
> raised. If they are fixed, the "decision" is of course void, and we don't
> have to vote about it.

That's not what was announced, at all. Please, read the news entry in question
and inform yourself in the subject before trying to participate in a discussion.

> (We could vote to overturn our decision although there are still
> issues.)
> 
>> If he has no interest in making sure said feature doesn't go back to the
>> state that prompted its removal, then he's simply trying to force the project
>> to keep code someone else will have to deal with.
>>
>> It would make much more sense in that case if the actual person interested 
>> and
>> willing to deal with the code to be behind these decision revoking attempts.
>>
>>>
 Or is he just fighting this fight to not remove code for the sake of
 not removing code, and will forget about it and expect someone
 else to deal with it if it starts bitrotting again?
>>>
>>> This is a violation of our code-of-conduct or do I misunderstand you?
>>
>> How so? If he's not going to maintain the code he's campaigning to keep in
>> place, then he obviously expects someone else will, right? How is stating
>> that a violation of the CoC?
> 
> I am not a native speaker but this is not how I read your accusation.
> "is he just fighting the fight to not remove code for the sake of not
> removing code" sounds to me as if you are not assuming good faith.

I'm not assuming anything and I don't know the nature of his intentions, but i
do know everything points said intentions are to keep code he has no plan to 
deal
with afterwards. That's all i stated.

If you're interested in waving the CoC around, you could reply to the two emails
where Nicolas called me a dictator and an imbecile. It would be nice to know I'm
not being ganged up by two or three people on this whole deal.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-11-29 21:11 GMT+01:00 James Almer :
> On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
>> 2016-11-29 20:38 GMT+01:00 James Almer :
>>
>>> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
>>> maintain it, improve and extend it if it were to remain in the tree?
>>
>> How is this related?
>> For which part of FFmpeg can we "expect" anybody to maintain it?
>
> He's trying to override an announced project decision of removing a feature.

We - obviously - announced it to find somebody who would fix the issues
raised. If they are fixed, the "decision" is of course void, and we don't
have to vote about it.
(We could vote to overturn our decision although there are still
issues.)

> If he has no interest in making sure said feature doesn't go back to the
> state that prompted its removal, then he's simply trying to force the project
> to keep code someone else will have to deal with.
>
> It would make much more sense in that case if the actual person interested and
> willing to deal with the code to be behind these decision revoking attempts.
>
>>
>>> Or is he just fighting this fight to not remove code for the sake of
>>> not removing code, and will forget about it and expect someone
>>> else to deal with it if it starts bitrotting again?
>>
>> This is a violation of our code-of-conduct or do I misunderstand you?
>
> How so? If he's not going to maintain the code he's campaigning to keep in
> place, then he obviously expects someone else will, right? How is stating
> that a violation of the CoC?

I am not a native speaker but this is not how I read your accusation.
"is he just fighting the fight to not remove code for the sake of not
removing code" sounds to me as if you are not assuming good faith.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/29/2016 5:04 PM, Carl Eugen Hoyos wrote:
> 2016-11-29 20:38 GMT+01:00 James Almer :
> 
>> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
>> maintain it, improve and extend it if it were to remain in the tree?
> 
> How is this related?
> For which part of FFmpeg can we "expect" anybody to maintain it?

He's trying to override an announced project decision of removing a feature.
If he has no interest in making sure said feature doesn't go back to the
state that prompted its removal, then he's simply trying to force the project
to keep code someone else will have to deal with.

It would make much more sense in that case if the actual person interested and
willing to deal with the code to be behind these decision revoking attempts.

> 
>> Or is he just fighting this fight to not remove code for the sake of
>> not removing code, and will forget about it and expect someone
>> else to deal with it if it starts bitrotting again?
> 
> This is a violation of our code-of-conduct or do I misunderstand you?

How so? If he's not going to maintain the code he's campaigning to keep in
place, then he obviously expects someone else will, right? How is stating that
a violation of the CoC?

> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-11-28 19:15 GMT+01:00 Nicolas George :
> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.

Could you point me to this decision?
What were the reasons at the time? Does any of the given reasons
still apply? If not, why is this vote necessary?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Carl Eugen Hoyos]

2016-11-29 20:38 GMT+01:00 James Almer :

> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree?

How is this related?
For which part of FFmpeg can we "expect" anybody to maintain it?

> Or is he just fighting this fight to not remove code for the sake of
> not removing code, and will forget about it and expect someone
> else to deal with it if it starts bitrotting again?

This is a violation of our code-of-conduct or do I misunderstand you?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Paul B Mahol]

On 11/29/16, James Almer  wrote:
> On 11/28/2016 5:52 PM, Clement Boesch wrote:
>> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
>>> Deadline: 2016-12-06 00:00 UTC.
>>>
>>> I propose, and put to the discussion, that the decision to drop ffserver
>>> is revoked, conditioned to the fixing of the technical issues that lead
>>> to it.
>>>
>>
>>> In other words, if the technical problems that require dropping ffserver
>>> are resolved at the time it is about to be dropped, then it must not be
>>> and the patch is not applied.
>>
>> Do we agree that the requirements are the following:
>>
>> - ZERO internal API usage
>> - at least partial FATE coverage
>>
>> ?
>>
>> What's the due date already? Next release?
>
> There are more important things to establish than just that.
>
> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree? Or is
> he
> just fighting this fight to not remove code for the sake of not removing
> code,
> and will forget about it and expect someone else to deal with it if it
> starts
> bitrotting again?
>
> And furthermore, how can we even trust anything that's agreed out of this,
> if
> the very existence of this vote derives from people being incapable of
> honoring
> previous agreements? Will people once again come out of the woodwork at the
> very
> last second, start flipping tables and decreeing on a whim that everything
> should
> be declared invalid, much like Nicolas is doing right now?
>
> This entire situation is simply embarrassing, no matter how you look at it
> or how
> you try to rationalize it.

I'm against keeping ffserver as such in FFmpeg repo.
It can be readded later when it is mature and properly implemented.

I vote No for this attempt to revoke previous decisions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/28/2016 5:52 PM, Clément Bœsch wrote:
> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
>> Deadline: 2016-12-06 00:00 UTC.
>>
>> I propose, and put to the discussion, that the decision to drop ffserver
>> is revoked, conditioned to the fixing of the technical issues that lead
>> to it.
>>
> 
>> In other words, if the technical problems that require dropping ffserver
>> are resolved at the time it is about to be dropped, then it must not be
>> and the patch is not applied.
> 
> Do we agree that the requirements are the following:
> 
> - ZERO internal API usage
> - at least partial FATE coverage
> 
> ?
> 
> What's the due date already? Next release?

There are more important things to establish than just that.

Seeing Nicolas is apparently very invested in ffserver, can we expect him to
maintain it, improve and extend it if it were to remain in the tree? Or is he
just fighting this fight to not remove code for the sake of not removing code,
and will forget about it and expect someone else to deal with it if it starts
bitrotting again?

And furthermore, how can we even trust anything that's agreed out of this, if
the very existence of this vote derives from people being incapable of honoring
previous agreements? Will people once again come out of the woodwork at the very
last second, start flipping tables and decreeing on a whim that everything 
should
be declared invalid, much like Nicolas is doing right now?

This entire situation is simply embarrassing, no matter how you look at it or 
how
you try to rationalize it.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Mon, 28 Nov 2016 19:15:28 +0100
Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
> 
> I support the decision. Pros:
> 
> ffserver has users, if there are no reason to drop it, doing so is a
> gratuitous annoyance to them.
> 
> Apparently James Almer opposes the decision. Cons, if I understand
> correctly:
> 
> A decision was made, a project should stick to it stubbornly.
> 
> Regards,
> 

If I'm still qualified to vote: I don't acknowledge this vote. This is
not a yes, no, or abstention from voting.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/29/2016 3:46 PM, Stefano Sabatini wrote:
> On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
>> Deadline: 2016-12-06 00:00 UTC.
>>
>> I propose, and put to the discussion, that the decision to drop ffserver
>> is revoked, conditioned to the fixing of the technical issues that lead
>> to it.
>>
>> In other words, if the technical problems that require dropping ffserver
>> are resolved at the time it is about to be dropped, then it must not be
>> and the patch is not applied.
> 
> Someone please specify who is entitled to vote (such decisions are not
> so common, and the voting criteria were defined a long time ago IIRC).

Afaics, https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html
is the most recent approved list. A third extension was suggested, but it
didn't go through.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Ronald S. Bultje]

Hi Stefano,

On Tue, Nov 29, 2016 at 1:46 PM, Stefano Sabatini 
wrote:

> On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
> > Deadline: 2016-12-06 00:00 UTC.
> >
> > I propose, and put to the discussion, that the decision to drop ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> >
> > In other words, if the technical problems that require dropping ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
>
> Someone please specify who is entitled to vote (such decisions are not
> so common, and the voting criteria were defined a long time ago IIRC).


https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Stefano Sabatini]

On date Monday 2016-11-28 19:15:28 +0100, Nicolas George encoded:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

Someone please specify who is entitled to vote (such decisions are not
so common, and the voting criteria were defined a long time ago IIRC).
-- 
FFmpeg = Fundamental & Fantastic MultiPurpose Entertaining Geek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Ronald S. Bultje]

Hi,

On Mon, Nov 28, 2016 at 1:15 PM, Nicolas George  wrote:

> Deadline: 2016-12-06 00:00 UTC.
>
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
>
> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.
>
> I support the decision.


I vote to continue to drop ffserver.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 09:52:02PM +0100, Clément Bœsch wrote:
> On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> > Deadline: 2016-12-06 00:00 UTC.
> > 
> > I propose, and put to the discussion, that the decision to drop ffserver
> > is revoked, conditioned to the fixing of the technical issues that lead
> > to it.
> > 
> 
> > In other words, if the technical problems that require dropping ffserver
> > are resolved at the time it is about to be dropped, then it must not be
> > and the patch is not applied.
> 
> Do we agree that the requirements are the following:
> 
> - ZERO internal API usage


> - at least partial FATE coverage

with the 2 patches i just posted
make  ffservertest
passes on x86_32, x86_64, qemu-arm and qemu-mips linux
mingw doesnt support ffserver

arm & mips used native ffmpeg as the qemu i used seems to lack execvp()
interception. That would also imlpy that mixing ffserver and
ffmpeg between big and little endian works

it does not work 100% yet though, i saw one failure that was not
reproduceable and the real media output doesnt work, ive a rough
idea why rm doesnt work but had no time to look into it

But at least ffservertest should at this point be usefull to detect
if something changes without intend


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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 11/28/2016 5:40 PM, Michael Niedermayer wrote:
> On Mon, Nov 28, 2016 at 09:53:39AM -0900, Lou Logan wrote:
>> On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
>>>
>>> ffserver has users
>>
>> I don't know of any. Do you have an estimation of how many users there
>> may be? How much feedback has there been from these alleged users
>> regarding the removal plans?
> 
> iam not nicolas but just out of curiousity i checked our bug tracker
> there are 60 tickets marked as component = ffserver
> https://trac.ffmpeg.org/query?component=ffserver=id=summary=status=owner=type=priority=component=priority
> 
> to put this in perspective i tried component=ffmpeg
> which shows 313 tickets
> https://trac.ffmpeg.org/query?component=ffmpeg=id=summary=status=owner=type=priority=component=priority

How many are not tagged "ffmpeg" but are tagged as one of the libraries
and the bug in question was found by the user running ffmpeg? Now compare
that with users finding the bugs in their everyday usage of ffplay, ffprobe,
or ffserver.

Seeing we're close to six thousand bugs, it's safe to assume that number
for ffmpeg will be in the thousands, with ffprobe, ffplay and ffserver
very faw away with maybe two digit numbers.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Clément Bœsch]

On Mon, Nov 28, 2016 at 07:15:28PM +0100, Nicolas George wrote:
> Deadline: 2016-12-06 00:00 UTC.
> 
> I propose, and put to the discussion, that the decision to drop ffserver
> is revoked, conditioned to the fixing of the technical issues that lead
> to it.
> 

> In other words, if the technical problems that require dropping ffserver
> are resolved at the time it is about to be dropped, then it must not be
> and the patch is not applied.

Do we agree that the requirements are the following:

- ZERO internal API usage
- at least partial FATE coverage

?

What's the due date already? Next release?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Michael Niedermayer]

On Mon, Nov 28, 2016 at 09:53:39AM -0900, Lou Logan wrote:
> On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
> >
> > ffserver has users
> 
> I don't know of any. Do you have an estimation of how many users there
> may be? How much feedback has there been from these alleged users
> regarding the removal plans?

iam not nicolas but just out of curiousity i checked our bug tracker
there are 60 tickets marked as component = ffserver
https://trac.ffmpeg.org/query?component=ffserver=id=summary=status=owner=type=priority=component=priority

to put this in perspective i tried component=ffmpeg
which shows 313 tickets
https://trac.ffmpeg.org/query?component=ffmpeg=id=summary=status=owner=type=priority=component=priority

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[Lou Logan]

On Mon, Nov 28, 2016, at 09:15 AM, Nicolas George wrote:
>
> ffserver has users

I don't know of any. Do you have an estimation of how many users there
may be? How much feedback has there been from these alleged users
regarding the removal plans?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel