[FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

[Muhammad Faiz]

On Sat, Feb 3, 2018 at 6:34 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> Am 02.02.2018 11:58 nachm. schrieb "Muhammad Faiz" <mfcc64 at gmail.com>:
>
> On Sat, Feb 3, 2018 at 1:55 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Fri, Feb 2, 2018 at 7:49 PM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>> On Fri, Feb 2, 2018 at 10:23 PM, Josh de Kock <josh at itanimul.li> wrote:
>>>>
>>>>> On 1 Feb 2018, at 18:51, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>>>>
>>>>>> On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock <josh at itanimul.li> wrote:
>>>>>> Also replace linked list with an array.
>>>>>> ---
>>>>>> configure              |   12 +-
>>>>>> doc/APIchanges         |    4 +
>>>>>> libavcodec/.gitignore  |    2 +
>>>>>> libavcodec/allcodecs.c | 1473 ++++++++++++++++++++++++++++--
> ------------------
>>>>>> libavcodec/avcodec.h   |   31 +
>>>>>> libavcodec/parser.c    |   84 ++-
>>>>>> libavcodec/utils.c     |  112 ----
>>>>>> libavcodec/version.h   |    3 +
>>>>>> 8 files changed, 971 insertions(+), 750 deletions(-)
>>>>>>
>>>>>
>>>>> I have a plan to sort codecs based on name and codec_id (which overlap
>>>>> with this patch). Is it OK if I overtake this?
>>>>> If it is not OK, I will wait until this patchset pushed.
>>>>>
>>>>
>>>> I am unsure why you would need to sort codecs.
>>>
>>> For performance reason.
>>
>> Performance of what?
>
> avcodec_find_decoder/encoder (by using bsearch).
>
>
> Considering you can have multiple of those for any given codec Id and order
> matters, that seems like a risky idea, or a rather complex one at least.
> Perhaps not the first (or second) place to start optimization.

I've thought about it.

Thank's.