On Sat, Feb 3, 2018 at 6:34 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > Am 02.02.2018 11:58 nachm. schrieb "Muhammad Faiz" <mfc...@gmail.com>: > > On Sat, Feb 3, 2018 at 1:55 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> On Fri, Feb 2, 2018 at 7:49 PM, Muhammad Faiz <mfc...@gmail.com> wrote: >>> 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. >> >> 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel