[FFmpeg-devel] [PATCH] ALS decoder

Thilo Borgmann thilo.borgmann
Thu Sep 3 01:58:11 CEST 2009


>> +        // TODO: use this to actually do channel sorting
> 
> I think outputting channels in the correct order is quite important
> i dont mind if thats done after the decoder is in svn, but i would mind
> if that is not done within a year ...

I will be around to do some more work on the decoder after the GSoC
version is applied. So this will be done in the "near" future.



> 
> [...]
>> +/** Decodes blocks dependently.
>> + */
>> +static int decode_blocks(ALSDecContext *ctx, unsigned int ra_frame,
>> +                         unsigned int c, const unsigned int *div_blocks,
>> +                         unsigned int *js_blocks)
>> +{
>> +    ALSSpecificConfig *sconf = &ctx->sconf;
>> +    unsigned int offset = 0;
>> +    int32_t *raw_samples_R;
>> +    int32_t *raw_samples_L;
>> +    unsigned int b;
>> +
>> +    // decode all blocks
>> +    for (b = 0; b < ctx->num_blocks; b++) {
>> +        unsigned int s;
>> +        raw_samples_L = ctx->raw_samples[c    ] + offset;
>> +        raw_samples_R = ctx->raw_samples[c + 1] + offset;
>> +        if (read_block_data(ctx, ra_frame, raw_samples_L, div_blocks[b],
>> +                            &js_blocks[0], raw_samples_R) ||
>> +            read_block_data(ctx, ra_frame, raw_samples_R, div_blocks[b],
>> +                            &js_blocks[1], raw_samples_L)) {
>> +            // damaged block, write zero for the rest of the frame
>> +            zero_remaining(b, ctx->num_blocks, div_blocks, raw_samples_L);
>> +            zero_remaining(b, ctx->num_blocks, div_blocks, raw_samples_R);
>> +            return -1;
>> +        }
> 
> This code looks strange, the first call would use raw_samples_R
> that does not seem initialized at that point
> 
> have all the js cases been tested?

You're right but only negative indices are read from raw_samples_R in
that case thus no uninitialized data is accessed unintentionally.

Yes, all js_blocks values were tested.



> 
>> +    unsigned int c, sample, ra_frame, bytes_read, shift;
>> +
>> +    init_get_bits(&ctx->gb, buffer, buffer_size * 8);
>> +    ra_frame = sconf->ra_distance && !(ctx->frame_id % sconf->ra_distance);
> 
> has the ra_distance==0 case been tested?
> 

Yes.



> 
>> +        av_log(ctx->avctx, AV_LOG_WARNING,
>> +               "Reading frame data failed. Skipping RA unit.\n");
>> +
>> +    // increment the frame counter
>> +    ctx->frame_id++;
>> +
>> +    // transform decoded frame into output format
>> +    #define INTERLEAVE_OUTPUT(bps)                                 \
>> +    {                                                              \
>> +        int##bps##_t *dest = (int##bps##_t*) data;                 \
>> +        shift = bps - ctx->avctx->bits_per_raw_sample;             \
>> +        for (sample = 0; sample < ctx->cur_frame_length; sample++) \
>> +            for (c = 0; c < avctx->channels; c++)                  \
>> +                *dest++ = ctx->raw_samples[c][sample] << shift;    \
>> +    }
>> +
>> +    if (ctx->avctx->bits_per_raw_sample <= 16) {
>> +        INTERLEAVE_OUTPUT(16)
>> +    } else {
>> +        INTERLEAVE_OUTPUT(32)
>> +    }
>> +
>> +    *data_size = ctx->cur_frame_length * avctx->channels
>> +                 * (av_get_bits_per_sample_format(avctx->sample_fmt) >> 3);
> 
> data_size is not checked before writing into the buffer
> 
> 
> ...
> 
>> +    // check for size of decoded data
>> +    data_size = sconf->frame_length * avctx->channels *
>> +                (av_get_bits_per_sample_format(avctx->sample_fmt) >> 3);
>> +
>> +    if (data_size > INT_MAX) {
>> +        av_log(avctx, AV_LOG_ERROR, "Decoded data exceeds buffer size.\n");
>> +        decode_end(avctx);
>> +        return -1;
>> +    }
> 
> whatever this check should do it doesnt work, it wont ever be true as the
> multiplications are using int not int64

I did this to check data_size before writing into the buffer - you
already complained about this. Ok it is wrong as-is but is this a valid
test for the case mentioned above if done correctly (MUL64()) or not?


-Thilo



More information about the ffmpeg-devel mailing list