[FFmpeg-devel] [PATCH 1/2] api-flac-test: Fix stupid mistake

[wm4]

On Wed, 22 Apr 2015 18:09:14 +0300
Ludmila Glinskih <lglinskih at gmail.com> wrote:

> Was comparing 0 bytes in memcmp
> ---
>  libavcodec/api-flac-test.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
> index 5ca8e8f..1540da9 100644
> --- a/libavcodec/api-flac-test.c
> +++ b/libavcodec/api-flac-test.c
> @@ -117,7 +117,6 @@ static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx,
>      AVFrame *in_frame, *out_frame;
>      uint8_t *raw_in = NULL, *raw_out = NULL;
>      int in_offset = 0, out_offset = 0;
> -    int frame_data_size = 0;
>      int result = 0;
>      int got_output = 0;
>      int i = 0;
> @@ -218,7 +217,7 @@ static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx,
>          av_free_packet(&enc_pkt);
>      }
>  
> -    if (memcmp(raw_in, raw_out, frame_data_size * NUMBER_OF_FRAMES) != 0)
> +    if (memcmp(raw_in, raw_out, out_frame->linesize[0] * NUMBER_OF_FRAMES) != 0)
>      {
>          av_log(NULL, AV_LOG_ERROR, "Output differs\n");
>          return 1;

Something that I just noticed, though it's not necessarily related to
this particular patch: you should use nb_samples to copy the data
in/out. linesize can be larger than the actual data due to padding.

The padding is needed because SIMD instructions may write more data
than actually needed, which would write past the memory allocation. So
the memory allocation is simply made large enough to avoid problems.

The API user doesn't need to care about these issues, because
av_frame_get_buffer() already takes care of it. (The test still could
check that nb_samples and the AVFrame format is consistent with
linesize. Maybe.)

Also, in this case, there's probably no observable issue with your
code, because the frame sizes are already aligned, so that linesize
equals the used size by coincidence.

The doxygen for linesize says:

     * @note The linesize may be larger than the size of usable data -- there
     * may be extra padding present for performance reasons.