[FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Thu, Feb 8, 2018 at 1:33 AM, Nicolas George <george at nsup.org> wrote:
> James Almer (2018-02-07):
>> Since reverting would be dirty, I'd prefer if we keep the discussion
>> about the desired API going and then apply the needed patches on top of
>> the current tree.
>> As long as we don't take weeks to do it (and do it before a release is
>> tagged), any kind of change to what is already committed is ok.
>
> Yes, that is exactly what I meant with "virtually revoked". Let us hope
> people will not start using the API before we stabilize it.
>
> But I would like that people be more careful with it. Twice in a few
> days have patches been pushed while there were outstanding objections
> about the API. If it had been done on purpose, I think it would have
> been ground for revoking git commit rights.
>
> Now, as for the possible APIs for iterating:
>
> (A) this one using an opaque pointer and a _next() call;
>
> (B) using an index;
>
> (C) returning the whole list at once in a newly allocated array.
>
> Are there any missing?
>
> I am rather in favour of (C), because it is the one that puts the least
> constraint on the internal implementation. And it is very convenient for
> the caller.

I actually prefer _next() without introducing new API. Yeah, it is
slower because it must initialize next pointer (people seem dislike
the patch that fixes it (i.e. with ff_next things)). But, as long as
the internal doesn't use it but uses list directly, it has no
problems.

If speed is really a concern for users, then (B) probably is an option.

Thank's.