[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