[FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[James Almer]

On 2/8/2018 9:52 AM, wm4 wrote:
> On Thu, 8 Feb 2018 10:29:11 +0000
> Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
> 
>> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>
>>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial at 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 at 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.