[FFmpeg-devel] [FFmpeg-cvslog] lavc: add new API for iterating codecs and codec parsers
mfcc64 at gmail.com
Thu Feb 8 03:23:28 EET 2018
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
If speed is really a concern for users, then (B) probably is an option.
More information about the ffmpeg-devel