[FFmpeg-devel] [PATCH] checkasm: add alacdsp tests

Henrik Gramner henrik at gramner.com
Sun Oct 4 22:28:12 CEST 2015


On Sun, Oct 4, 2015 at 8:45 PM, James Almer <jamrial at gmail.com> wrote:
> +#define randomize_buffers()                                \
> +    do {                                                   \
> +        int i;                                             \
> +        for (i = 0; i < BUF_SIZE * MAX_CHANNELS; i += 4) { \
> +            uint32_t r = rnd() & 0x7FFFFF;                 \
> +            AV_WN32A(ref_buf + i, r);                      \
> +            AV_WN32A(new_buf + i, r);                      \
> +        }                                                  \
> +    } while (0)

No negative values possible even though the type is int32_t?

> +static void check_decorrelate_stereo(void)
[...]
> +    LOCAL_ALIGNED_16(uint8_t, ref_buf, [BUF_SIZE*MAX_CHANNELS]);
> +    LOCAL_ALIGNED_16(uint8_t, new_buf, [BUF_SIZE*MAX_CHANNELS]);
> +    uint8_t *ref[] = { &ref_buf[BUF_SIZE*0], &ref_buf[BUF_SIZE*1] };
> +    uint8_t *new[] = { &new_buf[BUF_SIZE*0], &new_buf[BUF_SIZE*1] };

Wouldn't int32_t instead of uint8_t simplify things a lot? Then there
wouldn't be any need to typecast things later on and the AV_WN32A
stuff could be dropped from randomize_buffers().

> +        call_ref((int32_t **)ref, BUF_SIZE / sizeof(int32_t), shift, weight);
> +        call_new((int32_t **)new, BUF_SIZE / sizeof(int32_t), shift, weight);

Can len be a value that isn't mod16? If so then that parameter could
be randomized within certain constraints to test that behavior as
well.

All above points apply to append_extra_bits as well.


More information about the ffmpeg-devel mailing list