[FFmpeg-devel] [RFC] integer.h overhaul

Michael Niedermayer michaelni at gmx.at
Tue Oct 9 19:52:12 CEST 2012

On Tue, Oct 09, 2012 at 07:15:37PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2012-10-09 18:45:12 +0200, Michael Niedermayer encoded:
> > On Tue, Oct 09, 2012 at 05:01:28PM +0200, Stefano Sabatini wrote:
> > > Hi,
> > > 
> > > I needed to extend big integer support to make it able to contain up
> > > to 2304 bits (144 16-bits words), so I re-worked the API to avoid to
> > > pass huge arrays by value.
> > 
> > why do you need to work with such large integers ?
> > please explain the algorithm you try to implement
> Check the xface patch, it encodes a 48x48 bitmap as a big integer (so
> it is 48x48 bits = 144 16-bits words, integer.c supports up to 8).
> Another possibility would be to implement custom routines in the xface
> code, but I thought sharing code with libavutil was a good thing.
> > why do you remove the pass by value ?
> > multiplying 2 such numbers will take probably around a million
> > cpu cyles, with the current implementation that was not designed for
> > this, copying such a number in pass by value will take maybe around
> > hundread cpu cyles.
> > so this isnt making it faster but it makes its interface quite
> > awkward to use IMHO
> Yes, indeed I was not so sure about it. I can change that and/or
> ripristinate the old interface (or leave it as it was), my only
> problem is to raise the maximum number of supported digits (that's why
> I published this as an RFC).

iam not sure whats the best thing to do, one would be simply to move
all to the header and use code like:

#define AV_INTEGER_SIZE 123
#include "libavutil/integer.h"

another would be to switch to references as you do but drop the upper
limit. so that the size of each number is decided when its allocated
but it seems overkill, we dont need these features currently ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121009/371d346b/attachment.asc>

More information about the ffmpeg-devel mailing list