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

[James Almer]

On 2/8/2018 7:29 AM, Rostislav Pehlivanov 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.

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.