[FFmpeg-devel] avcodec/version: Postpone FF_API_DEBUG_MV

Submitted by Michael Niedermayer on Oct. 22, 2017, 12:37 a.m.

Details

Message ID 20171022003722.32215-1-michael@niedermayer.cc
State New
Headers show

Commit Message

Michael Niedermayer Oct. 22, 2017, 12:37 a.m.
This is different from FF_API_VISMV which is supported through codecview.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Ronald S. Bultje Oct. 22, 2017, 12:52 a.m.
Hi,

On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer <michael@niedermayer.cc
> wrote:

> This is different from FF_API_VISMV which is supported through codecview.
>
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/version.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 8584bb7006..25696690d7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -79,7 +79,7 @@
>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
>  #endif
>  #ifndef FF_API_DEBUG_MV
> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif
>

Can you give an explanation for why this should be delayed? (It's missing
in the commit message, and this is hard to evaluate without a
justification/explanation.)

Ronald
Michael Niedermayer Oct. 22, 2017, 1:23 a.m.
On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer <michael@niedermayer.cc
> > wrote:
> 
> > This is different from FF_API_VISMV which is supported through codecview.
> >
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavcodec/version.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 8584bb7006..25696690d7 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -79,7 +79,7 @@
> >  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
> >  #endif
> >  #ifndef FF_API_DEBUG_MV
> > -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
> > +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
> >  #endif
> >
> 
> Can you give an explanation for why this should be delayed? (It's missing
> in the commit message, and this is hard to evaluate without a
> justification/explanation.)

It was not agreed on ffmpeg-devel to remove this feature.

Its used for example by me occasionally to analyze videos in bug
reports for debuging them.

There is no replacement or alternative iam aware of

[...]
James Almer Oct. 22, 2017, 1:30 a.m.
On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer <michael@niedermayer.cc
>>> wrote:
>>
>>> This is different from FF_API_VISMV which is supported through codecview.
>>>
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>  libavcodec/version.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>> index 8584bb7006..25696690d7 100644
>>> --- a/libavcodec/version.h
>>> +++ b/libavcodec/version.h
>>> @@ -79,7 +79,7 @@
>>>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
>>>  #endif
>>>  #ifndef FF_API_DEBUG_MV
>>> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
>>> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
>>>  #endif
>>>
>>
>> Can you give an explanation for why this should be delayed? (It's missing
>> in the commit message, and this is hard to evaluate without a
>> justification/explanation.)
> 
> It was not agreed on ffmpeg-devel to remove this feature.

I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
c6c03dfdf1692137111fe4aea0b72a1cff08f71e.

The commit even states it should have removed "all traces of its use",
but it looks like with the years more and more code was added to it,
seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
libav doesn't even feature the massive amount of code we have under this
deprecation wrapper in mpegvideo.
So basically, the functionality was deprecated, but then further
developed to the point removing it is almost impossible.

How the hell did this happen?

> 
> Its used for example by me occasionally to analyze videos in bug
> reports for debuging them.
> 
> There is no replacement or alternative iam aware of
> 
> [...]
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Michael Niedermayer Oct. 22, 2017, 2:03 a.m.
On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> > On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer <michael@niedermayer.cc
> >>> wrote:
> >>
> >>> This is different from FF_API_VISMV which is supported through codecview.
> >>>
> >>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> >>> ---
> >>>  libavcodec/version.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>> index 8584bb7006..25696690d7 100644
> >>> --- a/libavcodec/version.h
> >>> +++ b/libavcodec/version.h
> >>> @@ -79,7 +79,7 @@
> >>>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
> >>>  #endif
> >>>  #ifndef FF_API_DEBUG_MV
> >>> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
> >>> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>  #endif
> >>>
> >>
> >> Can you give an explanation for why this should be delayed? (It's missing
> >> in the commit message, and this is hard to evaluate without a
> >> justification/explanation.)
> > 
> > It was not agreed on ffmpeg-devel to remove this feature.
> 
> I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
> c6c03dfdf1692137111fe4aea0b72a1cff08f71e.

thats one i think was the code which we now have in codecview.
So that itself should be ok to remove


> 
> The commit even states it should have removed "all traces of its use",
> but it looks like with the years more and more code was added to it,
> seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
> libav doesn't even feature the massive amount of code we have under this
> deprecation wrapper in mpegvideo.
> So basically, the functionality was deprecated, but then further
> developed to the point removing it is almost impossible.
> 
> How the hell did this happen?

I dont know, maybe,
Libav deprecating and removing as much FFmpeg code as they can
FFmpeg continuing to work on the FFmpeg code

[...]
James Almer Oct. 22, 2017, 2:23 a.m.
On 10/21/2017 11:03 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
>> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
>>> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>>>> Hi,
>>>>
>>>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer <michael@niedermayer.cc
>>>>> wrote:
>>>>
>>>>> This is different from FF_API_VISMV which is supported through codecview.
>>>>>
>>>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>>>> ---
>>>>>  libavcodec/version.h | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>>>> index 8584bb7006..25696690d7 100644
>>>>> --- a/libavcodec/version.h
>>>>> +++ b/libavcodec/version.h
>>>>> @@ -79,7 +79,7 @@
>>>>>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
>>>>>  #endif
>>>>>  #ifndef FF_API_DEBUG_MV
>>>>> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
>>>>> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
>>>>>  #endif
>>>>>
>>>>
>>>> Can you give an explanation for why this should be delayed? (It's missing
>>>> in the commit message, and this is hard to evaluate without a
>>>> justification/explanation.)
>>>
>>> It was not agreed on ffmpeg-devel to remove this feature.
>>
>> I'm sorry, but you merged this deprecation in 2013. See ffmpeg commit
>> c6c03dfdf1692137111fe4aea0b72a1cff08f71e.
> 
> thats one i think was the code which we now have in codecview.
> So that itself should be ok to remove
> 
> 
>>
>> The commit even states it should have removed "all traces of its use",
>> but it looks like with the years more and more code was added to it,
>> seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
>> libav doesn't even feature the massive amount of code we have under this
>> deprecation wrapper in mpegvideo.
>> So basically, the functionality was deprecated, but then further
>> developed to the point removing it is almost impossible.
>>
>> How the hell did this happen?
> 
> I dont know, maybe,
> Libav deprecating and removing as much FFmpeg code as they can
> FFmpeg continuing to work on the FFmpeg code

No, i mean, why did a feature marked as deprecated keep getting
development? Shouldn't the replacement have gotten it instead? And if a
replacement was never planned, why wasn't the deprecation undone,
instead of getting pushed further into the future indefinitely?
Clément Bœsch Oct. 22, 2017, 8:25 a.m.
On Sat, Oct 21, 2017 at 11:23:29PM -0300, James Almer wrote:
[...]
> >> The commit even states it should have removed "all traces of its use",
> >> but it looks like with the years more and more code was added to it,
> >> seeing the removal commit 8933ac2079644fb09916f1875c569103aefe84b1 in
> >> libav doesn't even feature the massive amount of code we have under this
> >> deprecation wrapper in mpegvideo.
> >> So basically, the functionality was deprecated, but then further
> >> developed to the point removing it is almost impossible.
> >>
> >> How the hell did this happen?
> > 
> > I dont know, maybe,
> > Libav deprecating and removing as much FFmpeg code as they can
> > FFmpeg continuing to work on the FFmpeg code
> 
> No, i mean, why did a feature marked as deprecated keep getting
> development? Shouldn't the replacement have gotten it instead? And if a
> replacement was never planned, why wasn't the deprecation undone,
> instead of getting pushed further into the future indefinitely?

If I remember correctly (this needs double check), FFmpeg didn't continue
development of the frame debugging in MPEG after Libav deprecated it. On
the other hand, Libav did remove some code because it was broken by one of
their previous commit (see 37045e422; it was still working in FFmpeg at
that time unless I'm mistaken), so they had less code to deprecate in the
future.

Around that time, I was trying to export the motion vectors and render
them in a filter instead (known as codecview), which would soon become the
first step at dropping that code from the MPEG codec. I was less
interested in the macroblock type debugging which is also part of the
visual MPEG debugging "toolkit", so I left it as an exercise for people
interested in it. It would be nice to have it in codecview, but I wasn't
motivated to do all the work.

So anyway, implementing this requires to export the information as side
data, and port the code from the MPEG codec to the codecview filter. I
don't think it's wise to drop the MPEG code until this is done since it's
useful in practice. Delaying (again) the drop is fine with me.
Ronald S. Bultje Oct. 22, 2017, 11:26 a.m.
Hi,

On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer <michael@niedermayer.cc
> wrote:

> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
> <michael@niedermayer.cc
> > > wrote:
> >
> > > This is different from FF_API_VISMV which is supported through
> codecview.
> > >
> > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > ---
> > >  libavcodec/version.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > > index 8584bb7006..25696690d7 100644
> > > --- a/libavcodec/version.h
> > > +++ b/libavcodec/version.h
> > > @@ -79,7 +79,7 @@
> > >  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
> > >  #endif
> > >  #ifndef FF_API_DEBUG_MV
> > > -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
> > > +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
> > >  #endif
> > >
> >
> > Can you give an explanation for why this should be delayed? (It's missing
> > in the commit message, and this is hard to evaluate without a
> > justification/explanation.)
>
> It was not agreed on ffmpeg-devel to remove this feature.
>
> Its used for example by me occasionally to analyze videos in bug
> reports for debuging them.
>
> There is no replacement or alternative iam aware of
>

The replacement will never be written if:
a) nobody cares; AND
b) we keep delaying the removal

I'm considering veto'ing this patch.

Ronald
James Almer Oct. 22, 2017, 1:43 p.m.
On 10/22/2017 8:26 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer <michael@niedermayer.cc
>> wrote:
> 
>> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
>> <michael@niedermayer.cc
>>>> wrote:
>>>
>>>> This is different from FF_API_VISMV which is supported through
>> codecview.
>>>>
>>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>>> ---
>>>>  libavcodec/version.h | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>>> index 8584bb7006..25696690d7 100644
>>>> --- a/libavcodec/version.h
>>>> +++ b/libavcodec/version.h
>>>> @@ -79,7 +79,7 @@
>>>>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
>>>>  #endif
>>>>  #ifndef FF_API_DEBUG_MV
>>>> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
>>>> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
>>>>  #endif
>>>>
>>>
>>> Can you give an explanation for why this should be delayed? (It's missing
>>> in the commit message, and this is hard to evaluate without a
>>> justification/explanation.)
>>
>> It was not agreed on ffmpeg-devel to remove this feature.
>>
>> Its used for example by me occasionally to analyze videos in bug
>> reports for debuging them.
>>
>> There is no replacement or alternative iam aware of
>>
> 
> The replacement will never be written if:
> a) nobody cares; AND
> b) we keep delaying the removal
> 
> I'm considering veto'ing this patch.

Personally I'm with Clement in this. The deprecation was poorly handled,
and the feature currently has no replacement. Michael uses it for
debugging, so removing it does not seem productive.

But, also agreeing with Clement, this should absolutely be ported to the
codecview filter before the next bump, or it will be removed.
Clément Bœsch Oct. 22, 2017, 3:01 p.m.
On Sun, Oct 22, 2017 at 10:43:35AM -0300, James Almer wrote:
[...]
> Personally I'm with Clement in this. The deprecation was poorly handled,
> and the feature currently has no replacement. Michael uses it for
> debugging, so removing it does not seem productive.

Not just Michael, it's generally a good study case for understanding
codecs.

See https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors

Apparently, some people were caring about it enough to document it.
Ronald S. Bultje Oct. 22, 2017, 4:09 p.m.
Hi,

On Sun, Oct 22, 2017 at 9:43 AM, James Almer <jamrial@gmail.com> wrote:

> On 10/22/2017 8:26 AM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sat, Oct 21, 2017 at 9:23 PM, Michael Niedermayer
> <michael@niedermayer.cc
> >> wrote:
> >
> >> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
> >> <michael@niedermayer.cc
> >>>> wrote:
> >>>
> >>>> This is different from FF_API_VISMV which is supported through
> >> codecview.
> >>>>
> >>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> >>>> ---
> >>>>  libavcodec/version.h | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>>> index 8584bb7006..25696690d7 100644
> >>>> --- a/libavcodec/version.h
> >>>> +++ b/libavcodec/version.h
> >>>> @@ -79,7 +79,7 @@
> >>>>  #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
> >>>>  #endif
> >>>>  #ifndef FF_API_DEBUG_MV
> >>>> -#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
> >>>> +#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>>  #endif
> >>>>
> >>>
> >>> Can you give an explanation for why this should be delayed? (It's
> missing
> >>> in the commit message, and this is hard to evaluate without a
> >>> justification/explanation.)
> >>
> >> It was not agreed on ffmpeg-devel to remove this feature.
> >>
> >> Its used for example by me occasionally to analyze videos in bug
> >> reports for debuging them.
> >>
> >> There is no replacement or alternative iam aware of
> >>
> >
> > The replacement will never be written if:
> > a) nobody cares; AND
> > b) we keep delaying the removal
> >
> > I'm considering veto'ing this patch.
>
> Personally I'm with Clement in this. The deprecation was poorly handled,
> and the feature currently has no replacement. Michael uses it for
> debugging, so removing it does not seem productive.
>
> But, also agreeing with Clement, this should absolutely be ported to the
> codecview filter before the next bump, or it will be removed.
>

But this is the whole problem. We're stuck in a stalemate between nothing
and nobody. As with ffserver, we'll keep postponing this forever more until
the stalemate is broken.

What incentive is there for anyone to write a replacement for this feature?
And stack that incentive against the pool of available developers that have
time and interest in this feature, and what are you left with?

Nothing.

==

We need to move away from this stalemate-driven development. "ffserver"
shows how that can work. What we could propose is to accept this patch,
based on the understanding that we also - at the same time - agree on
timeline for final, conclusive, non-veto'able removal of this feature
within half a year, either replaced with an improved version that went
through real review and is for once not a total hack, or just not replaced
with anything at all.

==

If debugging using this feature really only happens once in a blue moon,
why not debug on a release branch? I'm thinking of Kieran complaining about
how hard it is to work on mpegvideo (10-bits anyone?) and all of this is
just not helping at all...

Ronald
Clément Bœsch Oct. 23, 2017, 8:27 a.m.
On Sun, Oct 22, 2017 at 12:09:04PM -0400, Ronald S. Bultje wrote:
[...]
> > > The replacement will never be written if:
> > > a) nobody cares; AND
> > > b) we keep delaying the removal
> > >
> > > I'm considering veto'ing this patch.
> >
> > Personally I'm with Clement in this. The deprecation was poorly handled,
> > and the feature currently has no replacement. Michael uses it for
> > debugging, so removing it does not seem productive.
> >
> > But, also agreeing with Clement, this should absolutely be ported to the
> > codecview filter before the next bump, or it will be removed.
> >
> 
> But this is the whole problem. We're stuck in a stalemate between nothing
> and nobody. As with ffserver, we'll keep postponing this forever more until
> the stalemate is broken.

Well, AFAIK contrary to ffserver, this is not exactly much a hinder for
further development; MPEG related development is pretty much stalled these
days, and there is no real API abuse here, it's just in the wrong place.

Also, contrary to ffserver, maybe it lacked some visibility by the
interested parties to do the actual portage work.
Ronald S. Bultje Oct. 23, 2017, 12:18 p.m.
Hi,

On Mon, Oct 23, 2017 at 4:27 AM, Clément Bœsch <u@pkh.me> wrote:

> On Sun, Oct 22, 2017 at 12:09:04PM -0400, Ronald S. Bultje wrote:
> [...]
> > > > The replacement will never be written if:
> > > > a) nobody cares; AND
> > > > b) we keep delaying the removal
> > > >
> > > > I'm considering veto'ing this patch.
> > >
> > > Personally I'm with Clement in this. The deprecation was poorly
> handled,
> > > and the feature currently has no replacement. Michael uses it for
> > > debugging, so removing it does not seem productive.
> > >
> > > But, also agreeing with Clement, this should absolutely be ported to
> the
> > > codecview filter before the next bump, or it will be removed.
> > >
> >
> > But this is the whole problem. We're stuck in a stalemate between nothing
> > and nobody. As with ffserver, we'll keep postponing this forever more
> until
> > the stalemate is broken.
>
> Well, AFAIK contrary to ffserver, this is not exactly much a hinder for
> further development; MPEG related development is pretty much stalled these
> days
>

You cut the second half of my message. Ask Kieran if the above statement is
true.

Ronald
Nicolas George Oct. 24, 2017, 2:15 p.m.
Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> But this is the whole problem. We're stuck in a stalemate between nothing
> and nobody. As with ffserver, we'll keep postponing this forever more until
> the stalemate is broken.
> 
> What incentive is there for anyone to write a replacement for this feature?
> And stack that incentive against the pool of available developers that have
> time and interest in this feature, and what are you left with?
> 
> Nothing.

The problem we have here is a lack of leadership.

We all work on the parts of the code and features that are of interest
to us, but there is nobody with the authority to demand work on the
boring tasks.

It is the kind of problems that grow at an accelerating rate, which is
the reason we did not see much for ~6 years and they are now popping all
over the place. For example, the recent discussion about the output of
statistics filters also showed a lack of leadership.

Note that I am not proposing myself as a leader, by far. A leader should
know the whole code well and have good human skills, and I fail both
conditions.

But we need to start looking for a solution, because otherwise this
project will eventually stagnate and bitrot.

Regards,
Michael Niedermayer Oct. 25, 2017, 12:42 a.m.
On Tue, Oct 24, 2017 at 04:15:01PM +0200, Nicolas George wrote:
> Le primidi 1er brumaire, an CCXXVI, Ronald S. Bultje a écrit :
> > But this is the whole problem. We're stuck in a stalemate between nothing
> > and nobody. As with ffserver, we'll keep postponing this forever more until
> > the stalemate is broken.
> > 
> > What incentive is there for anyone to write a replacement for this feature?
> > And stack that incentive against the pool of available developers that have
> > time and interest in this feature, and what are you left with?
> > 
> > Nothing.
> 
> The problem we have here is a lack of leadership.

I think the problem is primarely a mismatch of supply and demand.
There is more demand on "cleanup" than volunteers willing/able to do
said cleanup.

I also doubt that adding artifical pain like threatened removials
will attract any manpower, quite the contrary i think it will make
the gap wider in the long run.

[...]

Patch hide | download patch | download mbox

diff --git a/libavcodec/version.h b/libavcodec/version.h
index 8584bb7006..25696690d7 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -79,7 +79,7 @@ 
 #define FF_API_SET_DIMENSIONS    (LIBAVCODEC_VERSION_MAJOR < 58)
 #endif
 #ifndef FF_API_DEBUG_MV
-#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 58)
+#define FF_API_DEBUG_MV          (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
 #ifndef FF_API_AC_VLC
 #define FF_API_AC_VLC            (LIBAVCODEC_VERSION_MAJOR < 58)