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

[Muhammad Faiz]

On Fri, Feb 9, 2018 at 6:12 PM, Nicolas George <george at nsup.org> wrote:
> Muhammad Faiz (2018-02-08):
>> I actually prefer _next() without introducing new API. Yeah, it is
>> slower because it must initialize next pointer
>
> I am not sure what you mean here. The problem with initing the next
> pointer was never speed.
>
> The problem with the next pointer is that it requires a run-time write
> in the codec structure, that requires it to be in the data section
> instead of the rodata section.

This is what I mean "speed" (Don't forget we also need to call
ff_thread_once on every _next() call).

>
> The static init of this pointer, as you proposed, fixes that specific
> issue.
>
> But that is still a linked list. Linked lists are very good when you
> need to insert and remove in the list frequently, but for something that
> is built once and then static, it has very limited usefulness.

I dislike that we introduce new API just because it is "slightly"
better than old API.
Also, migrating to new API isn't trivial enough (see cmdutils.c problem).

>
> If the drawback of memory management for solution C (returning the whole
> list at once) is considered too bad, then I think solution B is
> preferable: more versatile, easier to understand.

If we really need to introduce new API, I also choose B. (Unless we
have a plan to make
the array become linked list again in the future).

Actually, I don't care so much about this. I will follow what people agree.

>
> And by the way, until we decide between solutions A, B, C or anything
> else proposed, starting coding would be useless. Just as starting to
> pack your bags before deciding whether you go to the sea or mountain.

Except for fixing regression.

Thank's.