On 28/07/2012 1:53 PM, Kostya Shishkov wrote:
>>> In theory you could collect (symbol, i+1, prefix) values and use them to
>>> initialise our VLC structure instead of making LUT yourself (exactly like
>>> binary does ;)
>>
>> If you think it's worth the time, I could try, but those functions look
>> not-so-friendly.
>
> Probably not, but it's worth commenting what you're doing here and later.
> Or you can reply to someone asking what's being done here "oh, isn't it
> obvious?".
I'll add a comment. I'm unsure whether I'll use the built in VLC funcs...
It seems rather pointless here (extra code, no benefit).
>>> ahem, someone forgot to _skip_ bits here
>>
>> Uh... I think I did, indeed.
>
> That's because first value is used to update pred and loop runs
> for(i = 1; i < width; i++).
>
> But it can be simplified to
>
> pred = *top_left;
> for (i = 0; i < ctx->avctx->width; i++) {
> pred += code_table[2 * show_bits(gb, 14)];
> skip = code_table[2 * show_bits(gb, 14) + 1];
> skip_bits(gb, skip);
> dst[0] = pred;
> dst += 3;
> }
> *top_left = dst[-3 * avctx->width];
>
> or something
OK.
>>>> + ctx->swapped_buf = av_malloc(avctx->width * avctx->height * 3);
>>>
>>> Are you sure it's always enough? Max code length is 14 bits and some space
>>> is
>>> needed for code descriptions. It's better to be pessimistic here than crash
>>> on
>>> too big input frame later.
>>
>> You think it's possible to be larger than the raw frame? o.o
>
> Just think of some evil person faking large frame. And boom goes your decoder.
> That's why we usually just realloc it depending on input frame size.
I see. Fun. :/
>>> You can just move them to context instead of allocating dynamically.
>>
>> I figured allocating 3 arrays of 32768 on the stack probably wasn't a
>> good idea...
>
> Stack? I said CLLCContext, which is allocated by lavc.
My brain died and I forgot priv_data is always alloc'd.
- Derek
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
