[Ffmpeg-devel] [PATCH] Apple Video Encoder (rpza)

[Todd Kirby]

On 6/5/05, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
> 
> On Saturday 04 June 2005 09:55, Todd Kirby wrote:
> > Attached is a patch to add support for Apple Video encoding (rpza).
> > The quality settings are defined at compile time right now since I
> > wasn't really sure how to map ffmpeg's numerous video options to the
> > capabilities of rpza. It supports all rpza encoding opcodes but the
> > 4-color block encoding doesn't try to do multiblock runs yet.
> >
> 
> > +#define MIN(a,b) ((a) < (b) ? (a) : (b))
> > +#define MAX(a,b) ((a) > (b) ? (a) : (b))
> 
> theres FFMIN/FFMAX
> 
> 
> > +static uint16_t round_rgb24_to_rgb555(uint8_t * rgb24, int bias)
> > +/*
> > + * Round a 24 bit rgb value to a 15 bit rgb value. The bias parameter
> > + * specifies the rounding direction.
> > + */
> > +{
> > +    uint16_t rgb555 = 0;
> > +    uint32_t r, g, b;
> 
> comments must be in a doxygen compatible format
> (u)intXY_t should only be used if an exact length variable is needed
> 
> 
> > +    double sumx = 0, sumy = 0, sumx2 = 0, sumy2 = 0, sumxy = 0,
> 
> floating point variables should be avoided in codecs as they make regression
> tests impossible and are very slow on architectures with no FPU
> 
> 
> 
> > +    printf("\n\nRPZA DEBUG STATS\n");
> 
> printf->av_log()
> 
> 
> > r = (uint32_t)rgb24[0] + (uint32_t)(random() % 8);
> 
> random() cannot be used in libs, as it changes the state of the random number
> generator and isnt binary identical between platforms
> 
> 
Ok, most of this stuff is easy but, what is the alternative to random?
Is this a new requirement? I see lots of uses of random in the
libraries.

-Todd