[FFmpeg-devel] [PATCH] Add a codebook generator
Vitor
vitor1001
Sat Jun 2 17:54:43 CEST 2007
Hi
Michael Niedermayer wrote:
[...]
>> + int *points;
>> + AVRandomState *rand_state;
>> +} elbg_data;
>> +
>> +static inline int distance_limited(int *a, int *b, int dim, int limit)
>> +{
>> + int i, dist=0;
>> + for (i=0; i<dim; i++) {
>> + dist += (a[i] - b[i])*(a[i] - b[i]);
>> + if (dist > limit)
>> + return INT_MAX;
>> + }
>> +
>> + return dist;
>> +}
>>
>
> if a and b where 16bit/short then it would be trivial to calculate the
> above with mmx
> its possible with int too but it would need 2x as many reads and would
> need to convert from 32 to 16bit ...
>
>
>
Actually, I can't do any ASM. Anyway, if it where to optimize something
in assembler, wouldn't it be better to separate the whole loop (the
following) of the closest codebook search in a single function?
for (k=0; k < elbg->numCB; k++) {
dist = distance_limited(elbg->points + i*elbg->dim,
elbg->codebook + k*elbg->dim, dim, dist_cb[i]);
if (dist < dist_cb[i]) {
dist_cb[i] = dist;
elbg->nearest_cb[i] = k;
}
[...]
>> +
>> +static inline void vect_division(int *res, int *vect, int div, int dim)
>> +{
>> + int i;
>> + if (div > 1)
>> + for (i=0; i<dim; i++)
>> + res[i] = vect[i]/div;
>>
>
> this should be rounded to nearest like:
>
> if vect[i] is guranteed to be positive
> (vect[i] + div/2)/div;
> else
> ROUNDED_DIV(vect[i], div)
>
I used ROUNDED_DIV, because I don't think just this is worth making the
whole code specific to positive integers.
[...]
>> +
>> +void ff_init_elbg(int *points, int dim, int numpoints, int *codebook,
>> + int numCB, int max_steps, int *closest_cb,
>> + AVRandomState *rand_state)
>> +{
>> + int *temp_points;
>> + int i, k;
>> +
>> + if (numpoints > 24*numCB) {
>> + /* ELBG is very costly for a big number of points. So if we have a lot
>> + of them, get a good initial codebook to save on iterations */
>> + temp_points = av_malloc(dim*(numpoints/8)*sizeof(int));
>> + for (i=0; i<numpoints/8; i++) {
>> + k = (i*97) % numpoints;
>>
>
> 97 is not guranteed to be relative prim to numpoints
> if for example numpoints is x*97 this will not behave well ...
> simply choosing a larger prime should fix that
> for example 433494437LL would be an option (picked from
> http://en.wikipedia.org/wiki/List_of_prime_numbers)
>
I was a bit uneasy with the possibility of overflowing (is there any
chances of getting a repeated point if numpoints is not a power of two
and i*BIGPRIM overflows)?
And I agree with the rest.
-Vitor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elbg5.diff
Type: text/x-patch
Size: 15891 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070602/769634b0/attachment.bin>
More information about the ffmpeg-devel
mailing list