[FFmpeg-devel] [PATCH] Move mathops.h to libavutil.

Michael Niedermayer michaelni
Fri Nov 28 00:36:21 CET 2008


On Thu, Nov 27, 2008 at 11:10:10PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Thu, Nov 27, 2008 at 01:18:05PM -0000, M?ns Rullg?rd wrote:
> >> 
> >> Mans Rullgard wrote:
> >> > ---
> >> >  libavcodec/lsp.c                               |    2 +-
> >> >  libavcodec/mpegaudiodec.c                      |    2 +-
> >> >  {libavcodec/armv4l => libavutil/arm}/mathops.h |    6 +++---
> >> >  {libavcodec => libavutil}/bfin/mathops.h       |    6 +++---
> >> >  {libavcodec => libavutil}/mathops.h            |   12 ++++++------
> >> >  {libavcodec => libavutil}/ppc/mathops.h        |    6 +++---
> >> >  {libavcodec/i386 => libavutil/x86}/mathops.h   |    6 +++---
> >> >  7 files changed, 20 insertions(+), 20 deletions(-)
> >> >  rename {libavcodec/armv4l => libavutil/arm}/mathops.h (96%)
> >> >  rename {libavcodec => libavutil}/bfin/mathops.h (95%)
> >> >  rename {libavcodec => libavutil}/mathops.h (91%)
> >> >  rename {libavcodec => libavutil}/ppc/mathops.h (92%)
> >> >  rename {libavcodec/i386 => libavutil/x86}/mathops.h (93%)
> >> 
> >> ping
> >
> > why should mathops be moved to libavutil?
> 
> libavutil already has a number of similar macros/functions, scattered
> throughout common.h and internal.h:
> 
> FASTDIV()
> FFABS()
> FFSIGN()
> FFMAX()
> COPY3_IF_LT()
> MASK_ABS()
> av_log2()
> av_log2_16bit()
> ff_sqrt()
> mid_pred()
> av_clip()
> av_clip_uint8()
> av_clip_int16()
> av_clipf()
> 
> Most, if not all, of these are only used in lavc.

i know that at least mplayer uses several of them


> 
> IMO, it would make sense to have all elementary maths operations
> defined the same place.

it would make sense.
But considering the theoretic extreem, there are many math operations that
some might consider elementary that probably dont belong in libav* like
for example primality testing or factorization of large numbers.


> 
> What criteria do you use deciding where to place a function of this
> type?

IMO Libavutils goal is to stay small and only contain things that are
really usefull for a wide range of applications or tasks.
some of the functions like clip or ffmax allow code to be written in a
more compact and readable way.

COPY3_IF_LT should IMHO be removed from libavutil, its too specific and
obscure.
FASTDIV is a nice and fast way to perform divission when the operands are
within a limited range. A compiler couldnt just replace a a/b by it ...
...

for MULL/... it really is a question of people wanting it in libavutil.
If people do want to use it iam not at all against putting it in libavutil
But if noone wants it, it feels like bloat even if its just a header ...

Besides it really is gccs job to compile an elementary multiplication 
(possibly with a shift) to a reasonable sequence of instrctions. And i
hope these things have been reported to the gcc devels. It would be
silly if we where maintaining these workarounds while the gcc developers
where unaware of the issue.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081128/97c0b0cd/attachment.pgp>



More information about the ffmpeg-devel mailing list