[FFmpeg-devel] [PATCH] Move H264 dsputil functions into their own struct

[Måns Rullgård]

Pavel Pavlov <pavel at summit-tech.ca> writes:

>> >> Mans Rullgard <mans at mansr.com> writes:
>> >>
>> >> > This moves the H264-specific functions from DSPContext to the new
>> >> > H264DSPContext.  The code is made conditional on CONFIG_H264DSP
>> >> > which is set by the codecs requiring it.
>> >> >
>> >> > The qpel and chroma MC functions are not moved as these are used
>> by
>> >> > non-h264 code.
>> >> > ---
>> >> >  configure                          |   11 +-
>> >> >  libavcodec/Makefile                |   22 ++-
>> >> >  libavcodec/arm/dsputil_init_neon.c |   92 ----------
>> >> >  libavcodec/arm/h264dsp_init_arm.c  |  126 ++++++++++++++
>> >> >  libavcodec/dsputil.c               |  288 -----------------------
>> ---
>> >> ------
>> >> >  libavcodec/dsputil.h               |   33 ----
>> >> >  libavcodec/h264.c                  |   31 ++--
>> >> >  libavcodec/h264.h                  |    2 +
>> >> >  libavcodec/h264_loopfilter.c       |   20 +-
>> >> >  libavcodec/h264dsp.c               |  320
>> >> ++++++++++++++++++++++++++++++++++++
>> >> >  libavcodec/h264dsp.h               |   80 +++++++++
>> >> >  libavcodec/ppc/h264_altivec.c      |   27 ++-
>> >> >  libavcodec/x86/dsputil_mmx.c       |  144 +++++++++--------
>> >> >  13 files changed, 669 insertions(+), 527 deletions(-)
>> >> >  create mode 100644 libavcodec/arm/h264dsp_init_arm.c
>> >> >  create mode 100644 libavcodec/h264dsp.c
>> >> >  create mode 100644 libavcodec/h264dsp.h
>> >>
>> >> ping
>> >>
>> >
>> > There are multiple functions optimized for arm. There is OpemMax api
>> > partially implemented and available from arm.com, it has asm
>> > optimized for neon and arm11. Can it be used with ffmpeg?
>> 
>> I doubt it's better than the code we already have.  Openmax is quite
>> a pain to deal with too.
>> 
>> It's also quite unrelated to this patch.
>
> Yes, it's not really related to this patch, I just asked here
> because you are one of the authors of arm asm code.
> Ffmpeg has only a few functions optimized for arm; code from arm
> implements a lot of functions and I was just thinking if some of
> that could benefit ffmpeg (by using their lib or by studying the
> code ;).

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