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

Muhammad Faiz mfcc64 at gmail.com
Fri Feb 2 20:49:35 EET 2018


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.

>                                        The point of my patches is to bring the rest of ffmpeg up to the bsf iteration api (which abstracts internals away from the user). I planned on doing lavfi as well, but how the build system worked with filter names made it awkward. Hence me submitting these patches without a lavfi counterpart (I stills haven’t worked out the best way to do it yet). The way you’ve done your static initialisation of lavfi seems like a backwards way to do it, and would make overalls consistency difficult (something quite desirable, which my patches work towards).

Imho, av*iterate things are less elegant than av*next. But, the change
actually is not based on elegance, but based on performance (av*next
requires initialization of next pointer).

Thank's.


More information about the ffmpeg-devel mailing list