On Fri, Feb 2, 2018 at 10:23 PM, Josh de Kock <j...@itanimul.li> wrote:
>> On 1 Feb 2018, at 18:51, Muhammad Faiz <mfc...@gmail.com> wrote:
>>> On Thu, Feb 1, 2018 at 3:25 AM, Josh de Kock <j...@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).
ffmpeg-devel mailing list