On Sun, Oct 4, 2015 at 8:45 PM, James Almer <jamr...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
