On 03/18/2012 08:43 AM, Kostya Shishkov wrote:
On Sat, Mar 17, 2012 at 10:16:01PM +0100, Vitor Sessak wrote:
On 03/17/2012 08:54 AM, Kostya Shishkov wrote:
$subj
ralfdata.h is attached separately because it's less interesting and it's more
than 600k in plain form (yet it's still smaller that libavcodec/twinvq_data.h).
A couple more comments:
+}
+
+static int decode_block(AVCodecContext *avctx, GetBitContext *gb, int block_no)
+{
block_no looks unused.
indeed
+ block_pointer = src + table_bytes + 2;
+ bytes_left = src_size - table_bytes - 2;
+ ctx->sample_offset = 0;
+ for (i = 0; i< ctx->num_blocks; i++) {
+ if (bytes_left< ctx->block_size[i]) {
+ av_log(avctx, AV_LOG_ERROR, "I'm pedaling backwards\n");
+ break;
+ }
+ init_get_bits(&gb, block_pointer, ctx->block_size[i] * 8);
+ if (decode_block(avctx,&gb, i)< 0) {
+ av_log(avctx, AV_LOG_ERROR, "Sir, I got carsick in your office\n");
+ break;
+ }
+ block_pointer += ctx->block_size[i];
+ bytes_left -= ctx->block_size[i];
+ }
+
+ if (avctx->channels == 2) {
+ for (i = 0; i< ctx->sample_offset; i++) {
+ *samples++ = ctx->channel_data[0][i];
+ *samples++ = ctx->channel_data[1][i];
+ }
+ } else {
+ for (i = 0; i< ctx->sample_offset; i++)
+ *samples++ = ctx->channel_data[0][i];
+ }
Is there a reason why not to do the int16 -> int32 right after
decoding the block? Wouldn't it allow to make the channel_data
buffer smaller?
It even would simplify things a bit, thanks for the suggestion.
Cool. Wouldn't now "block_data" be a more suitable name than
"channel_data"? Besides that, no further comments from me.
-Vitor
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
