diff mbox

[FFmpeg-devel] cmdutils: fix printing of codecs

Message ID 20180207210737.GA23162@DESKTOP-UATPK6A.localdomain
State New
Headers show

Commit Message

Josh Dekker Feb. 7, 2018, 9:07 p.m. UTC
Yes, my bad. It looked like it worked initially (was more
worried about getting a fix out quickly), but it didnt. Try this one.

---
 fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
 1 file changed, 58 insertions(+), 46 deletions(-)

Comments

Michael Niedermayer Feb. 8, 2018, 12:32 a.m. UTC | #1
On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
> Yes, my bad. It looked like it worked initially (was more
> worried about getting a fix out quickly), but it didnt. Try this one.
> 
> ---
>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
>  1 file changed, 58 insertions(+), 46 deletions(-)

I dont know if this is supposed to fix the other lists
but
./ffmpeg -demuxers
still returns nonsense with this patch

File formats:
 D. = Demuxing supported
 .E = Muxing supported
 --
  E 3dostr          3DO STR
  E 4xm             4X Technologies
...
a while ago this was returned:

File formats:
 D. = Demuxing supported
 .E = Muxing supported
 --
 D  3dostr          3DO STR
 D  4xm             4X Technologies


 
[...]
James Almer Feb. 8, 2018, 12:35 a.m. UTC | #2
On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
>> Yes, my bad. It looked like it worked initially (was more
>> worried about getting a fix out quickly), but it didnt. Try this one.
>>
>> ---
>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
>>  1 file changed, 58 insertions(+), 46 deletions(-)
> 
> I dont know if this is supposed to fix the other lists
> but
> ./ffmpeg -demuxers
> still returns nonsense with this patch
> 
> File formats:
>  D. = Demuxing supported
>  .E = Muxing supported
>  --
>   E 3dostr          3DO STR
>   E 4xm             4X Technologies
> ...
> a while ago this was returned:
> 
> File formats:
>  D. = Demuxing supported
>  .E = Muxing supported
>  --
>  D  3dostr          3DO STR
>  D  4xm             4X Technologies

Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
then. If the new API may actually get changed in the coming days once
some consensus is reached then there's no point trying to get this
working with things as is.
Michael Niedermayer Feb. 8, 2018, 12:36 a.m. UTC | #3
On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
> Yes, my bad. It looked like it worked initially (was more
> worried about getting a fix out quickly), but it didnt. Try this one.
> 
> ---
>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
>  1 file changed, 58 insertions(+), 46 deletions(-)

The output of this differs from before
it now lists decoders and encoders even if theres just one with matching name
to the codec
a bugfix should not introduce such a change

- D.VI.S 012v                 Uncompressed 4:2:2 10-bit
- D.V.L. 4xm                  4X Movie
- D.VI.S 8bps                 QuickTime 8BPS video
+ D.VI.S 012v                 Uncompressed 4:2:2 10-bit (decoders: 012v )
+ D.V.L. 4xm                  4X Movie (decoders: 4xm )
+ D.VI.S 8bps                 QuickTime 8BPS video (decoders: 8bps )
  .EVIL. a64_multi            Multicolor charset for Commodore 64 (encoders: a64multi )
  .EVIL. a64_multi5           Multicolor charset for Commodore 64, extended with 5th color (colram) (encoders: a64multi5 )
- D.V..S aasc                 Autodesk RLE
- D.VIL. aic                  Apple Intermediate Codec
- DEVI.S alias_pix            Alias/Wavefront PIX image
- DEVIL. amv                  AMV Video
- D.V.L. anm                  Deluxe Paint Animation
- D.V.L. ansi                 ASCII/ANSI art
- DEV..S apng                 APNG (Animated Portable Network Graphics) image
- DEVIL. asv1                 ASUS V1
- DEVIL. asv2                 ASUS V2
- D.VIL. aura                 Auravision AURA
- D.VIL. aura2                Auravision Aura 2
+ D.V..S aasc                 Autodesk RLE (decoders: aasc )
+ D.VIL. aic                  Apple Intermediate Codec (decoders: aic )
+ DEVI.S alias_pix            Alias/Wavefront PIX image (decoders: alias_pix ) (encoders: alias_pix )
+ DEVIL. amv                  AMV Video (decoders: amv ) (encoders: amv )
+ D.V.L. anm                  Deluxe Paint Animation (decoders: anm )
+ D.V.L. ansi                 ASCII/ANSI art (decoders: ansi )
+ DEV..S apng                 APNG (Animated Portable Network Graphics) image (decoders: apng ) (encoders: apng )
+ DEVIL. asv1                 ASUS V1 (decoders: asv1 ) (encoders: asv1 )
+ DEVIL. asv2                 ASUS V2 (decoders: asv2 ) (encoders: asv2 )
+ D.VIL. aura                 Auravision AURA (decoders: aura )
+ D.VIL. aura2                Auravision Aura 2 (decoders: aura2 )
  ..V.L. av1                  Alliance for Open Media AV1


[...]
Muhammad Faiz Feb. 8, 2018, 1:08 a.m. UTC | #4
On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:
> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
>>> Yes, my bad. It looked like it worked initially (was more
>>> worried about getting a fix out quickly), but it didnt. Try this one.
>>>
>>> ---
>>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
>>>  1 file changed, 58 insertions(+), 46 deletions(-)
>>
>> I dont know if this is supposed to fix the other lists
>> but
>> ./ffmpeg -demuxers
>> still returns nonsense with this patch
>>
>> File formats:
>>  D. = Demuxing supported
>>  .E = Muxing supported
>>  --
>>   E 3dostr          3DO STR
>>   E 4xm             4X Technologies
>> ...
>> a while ago this was returned:
>>
>> File formats:
>>  D. = Demuxing supported
>>  .E = Muxing supported
>>  --
>>  D  3dostr          3DO STR
>>  D  4xm             4X Technologies
>
> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> then. If the new API may actually get changed in the coming days once
> some consensus is reached then there's no point trying to get this
> working with things as is.

+1.
Michael Niedermayer Feb. 8, 2018, 1:28 a.m. UTC | #5
On Wed, Feb 07, 2018 at 09:35:24PM -0300, James Almer wrote:
> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> > On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
> >> Yes, my bad. It looked like it worked initially (was more
> >> worried about getting a fix out quickly), but it didnt. Try this one.
> >>
> >> ---
> >>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++------------------------
> >>  1 file changed, 58 insertions(+), 46 deletions(-)
> > 
> > I dont know if this is supposed to fix the other lists
> > but
> > ./ffmpeg -demuxers
> > still returns nonsense with this patch
> > 
> > File formats:
> >  D. = Demuxing supported
> >  .E = Muxing supported
> >  --
> >   E 3dostr          3DO STR
> >   E 4xm             4X Technologies
> > ...
> > a while ago this was returned:
> > 
> > File formats:
> >  D. = Demuxing supported
> >  .E = Muxing supported
> >  --
> >  D  3dostr          3DO STR
> >  D  4xm             4X Technologies
> 
> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> then. If the new API may actually get changed in the coming days once
> some consensus is reached then there's no point trying to get this
> working with things as is.

+1
this seems to fix the 2 issues

iam still looking into a 4th issue ive seen (not bisected yet, so may be from
something unrelated)


[...]
Nicolas George Feb. 8, 2018, 10:06 a.m. UTC | #6
Michael Niedermayer (2018-02-08):
> +1

I agree too.

And maybe, since we are reverting something, revert the whole series.

Regards,
Rostislav Pehlivanov Feb. 8, 2018, 10:25 a.m. UTC | #7
On 8 February 2018 at 10:06, Nicolas George <george@nsup.org> wrote:

> Michael Niedermayer (2018-02-08):
> > +1
>
> I agree too.
>
> And maybe, since we are reverting something, revert the whole series.
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>

-1, I object to reverting anything.
We should fix what we have right now. The API looks good too except some
people here feel like they haven't bikeshedded enough and want to cause
even more chaos.
One bad commit and you all go screaming revert with your pitchforks instead
of trying to fix it.
Rostislav Pehlivanov Feb. 8, 2018, 10:29 a.m. UTC | #8
On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:

> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:
> > On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> >> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
> >>> Yes, my bad. It looked like it worked initially (was more
> >>> worried about getting a fix out quickly), but it didnt. Try this one.
> >>>
> >>> ---
> >>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-
> -----------------------
> >>>  1 file changed, 58 insertions(+), 46 deletions(-)
> >>
> >> I dont know if this is supposed to fix the other lists
> >> but
> >> ./ffmpeg -demuxers
> >> still returns nonsense with this patch
> >>
> >> File formats:
> >>  D. = Demuxing supported
> >>  .E = Muxing supported
> >>  --
> >>   E 3dostr          3DO STR
> >>   E 4xm             4X Technologies
> >> ...
> >> a while ago this was returned:
> >>
> >> File formats:
> >>  D. = Demuxing supported
> >>  .E = Muxing supported
> >>  --
> >>  D  3dostr          3DO STR
> >>  D  4xm             4X Technologies
> >
> > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> > then. If the new API may actually get changed in the coming days once
> > some consensus is reached then there's no point trying to get this
> > working with things as is.
>
> +1.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

-1, there's no point in reverting this and then arguing for 3 weeks with
people who will never use the API in the first place, don't understand the
problem this patchset solved and just want to see their way be the only way
things are done.
We should fix this patch, fix another one if there's any and it'll be fine.
Nicolas George Feb. 8, 2018, 10:35 a.m. UTC | #9
Rostislav Pehlivanov (2018-02-08):
> We should fix what we have right now. The API looks good too except some
> people here feel like they haven't bikeshedded enough and want to cause
> even more chaos.

Do you realize that sentence accuses Michael, Muhammad and me of
pursuing a personal power trip instead of seeking the good of the
project? Do you realize how incredibly insulting you are?

Regards,
Rostislav Pehlivanov Feb. 8, 2018, 12:03 p.m. UTC | #10
On 8 February 2018 at 10:35, Nicolas George <george@nsup.org> wrote:

> Rostislav Pehlivanov (2018-02-08):
> > We should fix what we have right now. The API looks good too except some
> > people here feel like they haven't bikeshedded enough and want to cause
> > even more chaos.
>
> Do you realize that sentence accuses Michael, Muhammad and me of
> pursuing a personal power trip instead of seeking the good of the
> project? Do you realize how incredibly insulting you are?
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
No, I was referring to you and you alone.
You've been more insulting towards the people who do hard work and submit
patches by going out of your way to block them and saying "The burden of
proof is on you!". And by saying this you're basically not even wanting to
review anything - you'd rather be spoonfed some facts than look at the
code, figure out what it does, what it changes and seeing whether it's
doing what its meant to do or not.
If you want to be taken seriously and not be seen as someone as insulting
as you think I was here then you should provide constructive criticism, use
quotes, provide some information where you think there's an issue and
finally propose an alternative. So far you've only done "I don't like this
API and I can't be convinced otherwise!" and act surprised when your
rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all
I just said and michaelni provided objective testing, so don't even compare
yourself to them.
Instead, why don't you send a patch or even a WIP of what you think ought
to be done to the API?
James Almer Feb. 8, 2018, 12:35 p.m. UTC | #11
On 2/8/2018 7:29 AM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:
> 
>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:
>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
>>>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
>>>>> Yes, my bad. It looked like it worked initially (was more
>>>>> worried about getting a fix out quickly), but it didnt. Try this one.
>>>>>
>>>>> ---
>>>>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-
>> -----------------------
>>>>>  1 file changed, 58 insertions(+), 46 deletions(-)
>>>>
>>>> I dont know if this is supposed to fix the other lists
>>>> but
>>>> ./ffmpeg -demuxers
>>>> still returns nonsense with this patch
>>>>
>>>> File formats:
>>>>  D. = Demuxing supported
>>>>  .E = Muxing supported
>>>>  --
>>>>   E 3dostr          3DO STR
>>>>   E 4xm             4X Technologies
>>>> ...
>>>> a while ago this was returned:
>>>>
>>>> File formats:
>>>>  D. = Demuxing supported
>>>>  .E = Muxing supported
>>>>  --
>>>>  D  3dostr          3DO STR
>>>>  D  4xm             4X Technologies
>>>
>>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>>> then. If the new API may actually get changed in the coming days once
>>> some consensus is reached then there's no point trying to get this
>>> working with things as is.
>>
>> +1.
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> -1, there's no point in reverting this and then arguing for 3 weeks with
> people who will never use the API in the first place, don't understand the
> problem this patchset solved and just want to see their way be the only way
> things are done.
> We should fix this patch, fix another one if there's any and it'll be fine.

So you fix it now, then after discussing, we decide that we prefer to
keep the _next style of API instead of _iterate. What happens then? This
patch plus your fix will get reverted as they don't apply anymore.

So i insist, revert this patch, finalize (and fix the issues in) the
actual API, then start implementing it across the codebase.
wm4 Feb. 8, 2018, 12:52 p.m. UTC | #12
On Thu, 8 Feb 2018 10:29:11 +0000
Rostislav Pehlivanov <atomnuker@gmail.com> wrote:

> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:
> 
> > On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:  
> > > On 2/7/2018 9:32 PM, Michael Niedermayer wrote:  
> > >> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:  
> > >>> Yes, my bad. It looked like it worked initially (was more
> > >>> worried about getting a fix out quickly), but it didnt. Try this one.
> > >>>
> > >>> ---
> > >>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-  
> > -----------------------  
> > >>>  1 file changed, 58 insertions(+), 46 deletions(-)  
> > >>
> > >> I dont know if this is supposed to fix the other lists
> > >> but
> > >> ./ffmpeg -demuxers
> > >> still returns nonsense with this patch
> > >>
> > >> File formats:
> > >>  D. = Demuxing supported
> > >>  .E = Muxing supported
> > >>  --
> > >>   E 3dostr          3DO STR
> > >>   E 4xm             4X Technologies
> > >> ...
> > >> a while ago this was returned:
> > >>
> > >> File formats:
> > >>  D. = Demuxing supported
> > >>  .E = Muxing supported
> > >>  --
> > >>  D  3dostr          3DO STR
> > >>  D  4xm             4X Technologies  
> > >
> > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> > > then. If the new API may actually get changed in the coming days once
> > > some consensus is reached then there's no point trying to get this
> > > working with things as is.  
> >
> > +1.
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> -1, there's no point in reverting this and then arguing for 3 weeks with
> people who will never use the API in the first place, don't understand the
> problem this patchset solved and just want to see their way be the only way
> things are done.
> We should fix this patch, fix another one if there's any and it'll be fine.

+1 to this, but on the other hand this patch is just for code that
_uses_ the new API, not the API itself.

I seriously hope nobody is arguing for reverting the API as is. It
didn't please everyone, but it's good and sufficient enough, and we
were in a bikeshed stalemate.
wm4 Feb. 8, 2018, 12:55 p.m. UTC | #13
On Thu, 8 Feb 2018 12:03:22 +0000
Rostislav Pehlivanov <atomnuker@gmail.com> wrote:

> On 8 February 2018 at 10:35, Nicolas George <george@nsup.org> wrote:
> 
> > Rostislav Pehlivanov (2018-02-08):  
> > > We should fix what we have right now. The API looks good too except some
> > > people here feel like they haven't bikeshedded enough and want to cause
> > > even more chaos.  
> >
> > Do you realize that sentence accuses Michael, Muhammad and me of
> > pursuing a personal power trip instead of seeking the good of the
> > project? Do you realize how incredibly insulting you are?
> >
> > Regards,
> >
> > --
> >   Nicolas George
> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >  
> No, I was referring to you and you alone.
> You've been more insulting towards the people who do hard work and submit
> patches by going out of your way to block them and saying "The burden of
> proof is on you!". And by saying this you're basically not even wanting to
> review anything - you'd rather be spoonfed some facts than look at the
> code, figure out what it does, what it changes and seeing whether it's
> doing what its meant to do or not.
> If you want to be taken seriously and not be seen as someone as insulting
> as you think I was here then you should provide constructive criticism, use
> quotes, provide some information where you think there's an issue and
> finally propose an alternative. So far you've only done "I don't like this
> API and I can't be convinced otherwise!" and act surprised when your
> rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all
> I just said and michaelni provided objective testing, so don't even compare
> yourself to them.
> Instead, why don't you send a patch or even a WIP of what you think ought
> to be done to the API?

You can add that his attitude sometimes leads to worse results too
(instead of better ones, as he argues). Like the UDP EOF change, that
ended in changing the libavformat API away from POSIX-like semantics in
a way that caused tons of bugs (and some are still unfixed). Now I
don't want to insult Nicolas or make him look incompetent in any way,
but this is an attitude problem that needs to be fixed somehow. (I know
he'll feel insulted by these words anyway - nothing you can do I guess.)
James Almer Feb. 8, 2018, 1:19 p.m. UTC | #14
On 2/8/2018 9:52 AM, wm4 wrote:
> On Thu, 8 Feb 2018 10:29:11 +0000
> Rostislav Pehlivanov <atomnuker@gmail.com> wrote:
> 
>> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:
>>
>>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:  
>>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:  
>>>>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:  
>>>>>> Yes, my bad. It looked like it worked initially (was more
>>>>>> worried about getting a fix out quickly), but it didnt. Try this one.
>>>>>>
>>>>>> ---
>>>>>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-  
>>> -----------------------  
>>>>>>  1 file changed, 58 insertions(+), 46 deletions(-)  
>>>>>
>>>>> I dont know if this is supposed to fix the other lists
>>>>> but
>>>>> ./ffmpeg -demuxers
>>>>> still returns nonsense with this patch
>>>>>
>>>>> File formats:
>>>>>  D. = Demuxing supported
>>>>>  .E = Muxing supported
>>>>>  --
>>>>>   E 3dostr          3DO STR
>>>>>   E 4xm             4X Technologies
>>>>> ...
>>>>> a while ago this was returned:
>>>>>
>>>>> File formats:
>>>>>  D. = Demuxing supported
>>>>>  .E = Muxing supported
>>>>>  --
>>>>>  D  3dostr          3DO STR
>>>>>  D  4xm             4X Technologies  
>>>>
>>>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>>>> then. If the new API may actually get changed in the coming days once
>>>> some consensus is reached then there's no point trying to get this
>>>> working with things as is.  
>>>
>>> +1.
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>  
>>
>> -1, there's no point in reverting this and then arguing for 3 weeks with
>> people who will never use the API in the first place, don't understand the
>> problem this patchset solved and just want to see their way be the only way
>> things are done.
>> We should fix this patch, fix another one if there's any and it'll be fine.
> 
> +1 to this, but on the other hand this patch is just for code that
> _uses_ the new API, not the API itself.

Precisely. This is code implementing API that may or may not change, so
there's no point trying to fix it if it may eventually have to be
reverted anyway if we decide to use a different API.

So revert this patch now, finalize and fix the new functions, then re
apply it in a working way if needed afterwards.

> 
> I seriously hope nobody is arguing for reverting the API as is. It
> didn't please everyone, but it's good and sufficient enough, and we
> were in a bikeshed stalemate.

No, the idea is to work on top of what's already committed, but do it ASAP.
James Almer Feb. 8, 2018, 3:34 p.m. UTC | #15
On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 10:06, Nicolas George <george@nsup.org> wrote:
> 
>> Michael Niedermayer (2018-02-08):
>>> +1
>>
>> I agree too.
>>
>> And maybe, since we are reverting something, revert the whole series.
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
> 
> -1, I object to reverting anything.
> We should fix what we have right now. The API looks good too except some
> people here feel like they haven't bikeshedded enough and want to cause
> even more chaos.
> One bad commit and you all go screaming revert with your pitchforks instead
> of trying to fix it.

A set of seven patches was pushed before any of them got a full review
or even an ok, which unsurprisingly introduced a plethora of issues, and
all while there were discussions going about implementing the API in a
different way by more than one developer.
I do not, under any circumstance, support this strategy of pushing
unfinished things and then argue that since it's already committed it
can't be touched. I have no idea how you or anyone could support this
kind of thing.

The entire set should be reverted if only to make it clear that this is
not how development should work, yet everyone so far, including myself,
has suggested to only revert the one non-API commit that badly broke a
lot of things, then work on top of the already introduced API to
effectively finalize it, and then fix and reapply any implementation bits.
Rostislav Pehlivanov Feb. 8, 2018, 4:16 p.m. UTC | #16
On 8 February 2018 at 13:19, James Almer <jamrial@gmail.com> wrote:

> On 2/8/2018 9:52 AM, wm4 wrote:
> > On Thu, 8 Feb 2018 10:29:11 +0000
> > Rostislav Pehlivanov <atomnuker@gmail.com> wrote:
> >
> >> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:
> >>
> >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:
> >>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
> >>>>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
> >>>>>> Yes, my bad. It looked like it worked initially (was more
> >>>>>> worried about getting a fix out quickly), but it didnt. Try this
> one.
> >>>>>>
> >>>>>> ---
> >>>>>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-
> >>> -----------------------
> >>>>>>  1 file changed, 58 insertions(+), 46 deletions(-)
> >>>>>
> >>>>> I dont know if this is supposed to fix the other lists
> >>>>> but
> >>>>> ./ffmpeg -demuxers
> >>>>> still returns nonsense with this patch
> >>>>>
> >>>>> File formats:
> >>>>>  D. = Demuxing supported
> >>>>>  .E = Muxing supported
> >>>>>  --
> >>>>>   E 3dostr          3DO STR
> >>>>>   E 4xm             4X Technologies
> >>>>> ...
> >>>>> a while ago this was returned:
> >>>>>
> >>>>> File formats:
> >>>>>  D. = Demuxing supported
> >>>>>  .E = Muxing supported
> >>>>>  --
> >>>>>  D  3dostr          3DO STR
> >>>>>  D  4xm             4X Technologies
> >>>>
> >>>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
> >>>> then. If the new API may actually get changed in the coming days once
> >>>> some consensus is reached then there's no point trying to get this
> >>>> working with things as is.
> >>>
> >>> +1.
> >>> _______________________________________________
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>>
> >>
> >> -1, there's no point in reverting this and then arguing for 3 weeks with
> >> people who will never use the API in the first place, don't understand
> the
> >> problem this patchset solved and just want to see their way be the only
> way
> >> things are done.
> >> We should fix this patch, fix another one if there's any and it'll be
> fine.
> >
> > +1 to this, but on the other hand this patch is just for code that
> > _uses_ the new API, not the API itself.
>
> Precisely. This is code implementing API that may or may not change, so
> there's no point trying to fix it if it may eventually have to be
> reverted anyway if we decide to use a different API.
>
> So revert this patch now, finalize and fix the new functions, then re
> apply it in a working way if needed afterwards.
>

Seems reasonable. The author won't revert for some reason so could you go
ahead and do it?


>
> >
> > I seriously hope nobody is arguing for reverting the API as is. It
> > didn't please everyone, but it's good and sufficient enough, and we
> > were in a bikeshed stalemate.
>
> No, the idea is to work on top of what's already committed, but do it ASAP.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
James Almer Feb. 8, 2018, 4:33 p.m. UTC | #17
On 2/8/2018 1:16 PM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 13:19, James Almer <jamrial@gmail.com> wrote:
> 
>> On 2/8/2018 9:52 AM, wm4 wrote:
>>> On Thu, 8 Feb 2018 10:29:11 +0000
>>> Rostislav Pehlivanov <atomnuker@gmail.com> wrote:
>>>
>>>> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64@gmail.com> wrote:
>>>>
>>>>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial@gmail.com> wrote:
>>>>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote:
>>>>>>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, Josh de Kock wrote:
>>>>>>>> Yes, my bad. It looked like it worked initially (was more
>>>>>>>> worried about getting a fix out quickly), but it didnt. Try this
>> one.
>>>>>>>>
>>>>>>>> ---
>>>>>>>>  fftools/cmdutils.c | 104 +++++++++++++++++++++++++++++-
>>>>> -----------------------
>>>>>>>>  1 file changed, 58 insertions(+), 46 deletions(-)
>>>>>>>
>>>>>>> I dont know if this is supposed to fix the other lists
>>>>>>> but
>>>>>>> ./ffmpeg -demuxers
>>>>>>> still returns nonsense with this patch
>>>>>>>
>>>>>>> File formats:
>>>>>>>  D. = Demuxing supported
>>>>>>>  .E = Muxing supported
>>>>>>>  --
>>>>>>>   E 3dostr          3DO STR
>>>>>>>   E 4xm             4X Technologies
>>>>>>> ...
>>>>>>> a while ago this was returned:
>>>>>>>
>>>>>>> File formats:
>>>>>>>  D. = Demuxing supported
>>>>>>>  .E = Muxing supported
>>>>>>>  --
>>>>>>>  D  3dostr          3DO STR
>>>>>>>  D  4xm             4X Technologies
>>>>>>
>>>>>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted
>>>>>> then. If the new API may actually get changed in the coming days once
>>>>>> some consensus is reached then there's no point trying to get this
>>>>>> working with things as is.
>>>>>
>>>>> +1.
>>>>> _______________________________________________
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel@ffmpeg.org
>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>
>>>>
>>>> -1, there's no point in reverting this and then arguing for 3 weeks with
>>>> people who will never use the API in the first place, don't understand
>> the
>>>> problem this patchset solved and just want to see their way be the only
>> way
>>>> things are done.
>>>> We should fix this patch, fix another one if there's any and it'll be
>> fine.
>>>
>>> +1 to this, but on the other hand this patch is just for code that
>>> _uses_ the new API, not the API itself.
>>
>> Precisely. This is code implementing API that may or may not change, so
>> there's no point trying to fix it if it may eventually have to be
>> reverted anyway if we decide to use a different API.
>>
>> So revert this patch now, finalize and fix the new functions, then re
>> apply it in a working way if needed afterwards.
>>
> 
> Seems reasonable. The author won't revert for some reason so could you go
> ahead and do it?

Done. Thanks.

This most assuredly does not fix the issues introduced by the other
patches that Michael reported, so those do need to be fixed, regardless
of what's done with the API.

> 
> 
>>
>>>
>>> I seriously hope nobody is arguing for reverting the API as is. It
>>> didn't please everyone, but it's good and sufficient enough, and we
>>> were in a bikeshed stalemate.
>>
>> No, the idea is to work on top of what's already committed, but do it ASAP.
>> _______________________________________________
>> 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
>
wm4 Feb. 8, 2018, 5:21 p.m. UTC | #18
On Thu, 8 Feb 2018 12:34:07 -0300
James Almer <jamrial@gmail.com> wrote:

> On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> > On 8 February 2018 at 10:06, Nicolas George <george@nsup.org> wrote:
> >   
> >> Michael Niedermayer (2018-02-08):  
> >>> +1  
> >>
> >> I agree too.
> >>
> >> And maybe, since we are reverting something, revert the whole series.
> >>
> >> Regards,
> >>
> >> --
> >>   Nicolas George
> >>
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >>  
> > 
> > -1, I object to reverting anything.
> > We should fix what we have right now. The API looks good too except some
> > people here feel like they haven't bikeshedded enough and want to cause
> > even more chaos.
> > One bad commit and you all go screaming revert with your pitchforks instead
> > of trying to fix it.  
> 
> A set of seven patches was pushed before any of them got a full review
> or even an ok, which unsurprisingly introduced a plethora of issues, and
> all while there were discussions going about implementing the API in a
> different way by more than one developer.
> I do not, under any circumstance, support this strategy of pushing
> unfinished things and then argue that since it's already committed it
> can't be touched. I have no idea how you or anyone could support this
> kind of thing.
> 
> The entire set should be reverted if only to make it clear that this is
> not how development should work, yet everyone so far, including myself,
> has suggested to only revert the one non-API commit that badly broke a
> lot of things, then work on top of the already introduced API to
> effectively finalize it, and then fix and reapply any implementation bits.

The author spent weeks on fixing all the issues, updating the patch set
multiple times, and so on. In the end, he didn't get much helpful
reviews, but tons of bikeshedding that was unproductive as hell. Also
it seems he formally didn't violate any rules, because he fixed the
issues and waited long enough.

And now that some breakages occurred (which is not that surprising
since the patch changes so much), most mails on this topic are STILL
unhelpful bikeshedding.

Keeping patches in bikeshed hell while not giving good reviews (like
Michael just posting a specific command line and then saying "it broke"
while not saying anything actually helpful, or certain other devs who
came up with almost equivalent ideas how the components should be
iterated but which they have unusually strong opinions about), is a
good way to make developers leave and to make the mood of the project
worse.

Just saying.
Michael Niedermayer Feb. 8, 2018, 10:43 p.m. UTC | #19
On Thu, Feb 08, 2018 at 06:21:06PM +0100, wm4 wrote:
> On Thu, 8 Feb 2018 12:34:07 -0300
> James Almer <jamrial@gmail.com> wrote:
> 
> > On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote:
> > > On 8 February 2018 at 10:06, Nicolas George <george@nsup.org> wrote:
> > >   
> > >> Michael Niedermayer (2018-02-08):  
> > >>> +1  
> > >>
> > >> I agree too.
> > >>
> > >> And maybe, since we are reverting something, revert the whole series.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >>   Nicolas George
> > >>
> > >> _______________________________________________
> > >> ffmpeg-devel mailing list
> > >> ffmpeg-devel@ffmpeg.org
> > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >>  
> > > 
> > > -1, I object to reverting anything.
> > > We should fix what we have right now. The API looks good too except some
> > > people here feel like they haven't bikeshedded enough and want to cause
> > > even more chaos.
> > > One bad commit and you all go screaming revert with your pitchforks instead
> > > of trying to fix it.  
> > 
> > A set of seven patches was pushed before any of them got a full review
> > or even an ok, which unsurprisingly introduced a plethora of issues, and
> > all while there were discussions going about implementing the API in a
> > different way by more than one developer.
> > I do not, under any circumstance, support this strategy of pushing
> > unfinished things and then argue that since it's already committed it
> > can't be touched. I have no idea how you or anyone could support this
> > kind of thing.
> > 
> > The entire set should be reverted if only to make it clear that this is
> > not how development should work, yet everyone so far, including myself,
> > has suggested to only revert the one non-API commit that badly broke a
> > lot of things, then work on top of the already introduced API to
> > effectively finalize it, and then fix and reapply any implementation bits.
> 

> The author spent weeks on fixing all the issues, updating the patch set
> multiple times, and so on. In the end, he didn't get much helpful
> reviews, but tons of bikeshedding that was unproductive as hell. Also
> it seems he formally didn't violate any rules, because he fixed the
> issues and waited long enough.

Theres no need to polarize the discussion any further.
neither attacking anyone nor glorifying the author of a patchset
with a inprecisse statement where a correction would likely insult the author.
iam sure he is already stressed from having pushed a patchset that introduced
some issues.

We are one team, if WE have a bug in the code we should fix it or revert the
patch causing it. If a issue is trivial to fix then fixing is better. If it
is complex and one works under pressure its likely better to revert so as not
to introduce more mistakes and have a clean known to work basis ...

Thanks

[...]
diff mbox

Patch

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b06ccc..83088f0 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1421,16 +1421,43 @@  static char get_media_type_char(enum AVMediaType type)
     }
 }
 
-static const AVCodec *next_codec_for_id(enum AVCodecID id, const AVCodec *prev,
-                                        int encoder)
+
+static int compare_codec(const void *a, const void *b)
 {
-    void *i = 0;
-    while ((prev = av_codec_iterate(&i))) {
-        if (prev->id == id &&
-            (encoder ? av_codec_is_encoder(prev) : av_codec_is_decoder(prev)))
-            return prev;
+    const AVCodec * const *da = a;
+    const AVCodec * const *db = b;
+
+    return strcmp((*da)->name, (*db)->name);
+}
+
+static unsigned get_codecs_sorted(enum AVCodecID id, const AVCodec ***rcodecs, int encoder)
+{
+    const AVCodec *codec = NULL;
+    const AVCodec **codecs;
+    unsigned nb_codecs = 0, i = 0;
+    void *opaque = 0;
+
+    while ((codec = av_codec_iterate(&opaque))) {
+        if (codec->id == id &&
+            (encoder ? av_codec_is_encoder(codec) : av_codec_is_decoder(codec)))
+            nb_codecs++;
     }
-    return NULL;
+    if (!(codecs = av_calloc(nb_codecs, sizeof(*codecs)))) {
+        av_log(NULL, AV_LOG_ERROR, "Out of memory\n");
+        exit_program(1);
+    }
+
+    opaque = 0;
+    while ((codec = av_codec_iterate(&opaque))) {
+        if (codec->id == id &&
+            (encoder ? av_codec_is_encoder(codec) : av_codec_is_decoder(codec)))
+            codecs[i++] = codec;
+    }
+    av_assert0(i == nb_codecs);
+    qsort(codecs, nb_codecs, sizeof(*codecs), compare_codec);
+    *rcodecs = codecs;
+    return nb_codecs;
+
 }
 
 static int compare_codec_desc(const void *a, const void *b)
@@ -1442,7 +1469,7 @@  static int compare_codec_desc(const void *a, const void *b)
            strcmp((*da)->name, (*db)->name);
 }
 
-static unsigned get_codecs_sorted(const AVCodecDescriptor ***rcodecs)
+static unsigned get_codec_descs_sorted(const AVCodecDescriptor ***rcodecs)
 {
     const AVCodecDescriptor *desc = NULL;
     const AVCodecDescriptor **codecs;
@@ -1463,22 +1490,10 @@  static unsigned get_codecs_sorted(const AVCodecDescriptor ***rcodecs)
     return nb_codecs;
 }
 
-static void print_codecs_for_id(enum AVCodecID id, int encoder)
-{
-    const AVCodec *codec = NULL;
-
-    printf(" (%s: ", encoder ? "encoders" : "decoders");
-
-    while ((codec = next_codec_for_id(id, codec, encoder)))
-        printf("%s ", codec->name);
-
-    printf(")");
-}
-
 int show_codecs(void *optctx, const char *opt, const char *arg)
 {
     const AVCodecDescriptor **codecs;
-    unsigned i, nb_codecs = get_codecs_sorted(&codecs);
+    unsigned i, nb_codecs = get_codec_descs_sorted(&codecs);
 
     printf("Codecs:\n"
            " D..... = Decoding supported\n"
@@ -1492,7 +1507,6 @@  int show_codecs(void *optctx, const char *opt, const char *arg)
            " -------\n");
     for (i = 0; i < nb_codecs; i++) {
         const AVCodecDescriptor *desc = codecs[i];
-        const AVCodec *codec = NULL;
 
         if (strstr(desc->name, "_deprecated"))
             continue;
@@ -1508,22 +1522,18 @@  int show_codecs(void *optctx, const char *opt, const char *arg)
 
         printf(" %-20s %s", desc->name, desc->long_name ? desc->long_name : "");
 
-        /* print decoders/encoders when there's more than one or their
-         * names are different from codec name */
-        while ((codec = next_codec_for_id(desc->id, codec, 0))) {
-            if (strcmp(codec->name, desc->name)) {
-                print_codecs_for_id(desc->id, 0);
-                break;
-            }
-        }
-        codec = NULL;
-        while ((codec = next_codec_for_id(desc->id, codec, 1))) {
-            if (strcmp(codec->name, desc->name)) {
-                print_codecs_for_id(desc->id, 1);
-                break;
+        for (int encoder = 0; encoder < 2; encoder++) {
+            const AVCodec **codec_codecs;
+            const int nb_codec_codecs = get_codecs_sorted(desc->id, &codec_codecs, encoder);
+            if (nb_codec_codecs) {
+                printf(" (%s: ", encoder ? "encoders" : "decoders");
+                for (int j = 0; j < nb_codec_codecs; j++) {
+                    printf("%s ", codec_codecs[j]->name);
+                }
+                printf(")");
             }
+            av_free(codec_codecs);
         }
-
         printf("\n");
     }
     av_free(codecs);
@@ -1533,7 +1543,7 @@  int show_codecs(void *optctx, const char *opt, const char *arg)
 static void print_codecs(int encoder)
 {
     const AVCodecDescriptor **codecs;
-    unsigned i, nb_codecs = get_codecs_sorted(&codecs);
+    unsigned i, nb_codecs = get_codec_descs_sorted(&codecs);
 
     printf("%s:\n"
            " V..... = Video\n"
@@ -1549,8 +1559,11 @@  static void print_codecs(int encoder)
     for (i = 0; i < nb_codecs; i++) {
         const AVCodecDescriptor *desc = codecs[i];
         const AVCodec *codec = NULL;
+        const AVCodec **codec_codecs;
+        const int nb_codec_codecs = get_codecs_sorted(desc->id, &codec_codecs, encoder);
 
-        while ((codec = next_codec_for_id(desc->id, codec, encoder))) {
+        for (int j = 0; j < nb_codec_codecs; j++) {
+            codec = codec_codecs[j];
             printf(" %c", get_media_type_char(desc->type));
             printf((codec->capabilities & AV_CODEC_CAP_FRAME_THREADS) ? "F" : ".");
             printf((codec->capabilities & AV_CODEC_CAP_SLICE_THREADS) ? "S" : ".");
@@ -1564,6 +1577,7 @@  static void print_codecs(int encoder)
 
             printf("\n");
         }
+        av_free(codec_codecs);
     }
     av_free(codecs);
 }
@@ -1754,19 +1768,17 @@  static void show_help_codec(const char *name, int encoder)
     if (codec)
         print_codec(codec);
     else if ((desc = avcodec_descriptor_get_by_name(name))) {
-        int printed = 0;
-
-        while ((codec = next_codec_for_id(desc->id, codec, encoder))) {
-            printed = 1;
-            print_codec(codec);
-        }
+        const AVCodec **codec_codecs;
 
-        if (!printed) {
+        if (get_codecs_sorted(desc->id, &codec_codecs, encoder)) {
+            print_codec(codec_codecs[0]);
+        } else {
             av_log(NULL, AV_LOG_ERROR, "Codec '%s' is known to FFmpeg, "
                    "but no %s for it are available. FFmpeg might need to be "
                    "recompiled with additional external libraries.\n",
                    name, encoder ? "encoders" : "decoders");
         }
+        av_free(codec_codecs);
     } else {
         av_log(NULL, AV_LOG_ERROR, "Codec '%s' is not recognized by FFmpeg.\n",
                name);