Hi, On Sun, Oct 22, 2017 at 9:43 AM, James Almer <jamr...@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 > <mich...@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 > >> <mich...@niedermayer.cc > >>>> wrote: > >>> > >>>> This is different from FF_API_VISMV which is supported through > >> codecview. > >>>> > >>>> Signed-off-by: Michael Niedermayer <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel