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

[Stefano Sabatini]

On date Tuesday 2012-10-09 19:52:12 +0200, Michael Niedermayer encoded:
> 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 ...

Implemented the first suggestion (which has the nice property that no
API/ABI is even exposed). Problem is, the code is too slow, xface
takes several seconds to encode an image, which is not acceptable.
-- 
FFmpeg = Faithless and Fabulous Muttering Plastic Ermetic Genius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavu-integer-make-all-functions-static-inline.patch
Type: text/x-diff
Size: 9087 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121011/ba289f45/attachment.bin>