[FFmpeg-devel] [PATCH] Move H264 dsputil functions into their own struct
Pavel Pavlov
pavel
Tue Mar 16 03:00:38 CET 2010
> Pavel Pavlov <pavel at summit-tech.ca> writes:
> For h264 all but a few functions have NEON versions. Those that don't
> are used so rarely that it really doesn't matter.
>
> > They provide implementations for some performance critical functions
> > from mp4-part 2 and 4.
>
> What do you mean by that? MP4 is ISO 14496 part 14. Assuming you
> meant MPEG4, we already have NEON code for the most important
> functions in 14496-2. Part 4 is conformance testing so your statement
> makes little sense in relation to that.
>
> > Other than that they provide aac and mp3 decoding functions,
>
> Our AAC decoder is pretty fast. MP3 decoding is so fast that I'll
> only bother spending any time on it if someone pays me (or I can think
> of nothing else to do), even though making it 50% faster or more is
> easily possible.
>
> > signal processing function (FFT, FIR, IIR),
>
> We already have one of the fastest FFT implementations on the planet.
>
> > image coding (jpeg),
>
> We have that too.
>
> > image processing functions (color space conversion between different
> > formats)
>
> We are missing ARM optimisations in libswscale. I will not attempt to
> add any until someone has cleaned up the internal interfaces there a
> bit.
>
> As I said, the openmax API is unusable and the code unreadable. Why
> should we bother with it?
>
> --
> M?ns Rullg?rd
> mans at mansr.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
More information about the ffmpeg-devel
mailing list