| Message ID | 20171022003722.32215-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
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
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 [...]
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 >
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 [...]
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?
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.
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
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.
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.
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
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.
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
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,
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. [...]
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)
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(-)