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

[James Almer]

On 2/8/2018 1:16 PM, Rostislav Pehlivanov wrote:
> On 8 February 2018 at 13:19, James Almer <jamrial at gmail.com> wrote:
> 
>> 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.
>>
> 
> 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 at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>