[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