On 03/02/2012 05:30 AM, Martin Storsjö wrote:

> On Wed, 29 Feb 2012, Justin Ruggles wrote:
> 
>> ---
>> libavcodec/wmaenc.c |   49 ++++++++++++++++++++++++++++++++++---------------
>> 1 files changed, 34 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavcodec/wmaenc.c b/libavcodec/wmaenc.c
>> index c762a72..8c9c4e2 100644
>> --- a/libavcodec/wmaenc.c
>> +++ b/libavcodec/wmaenc.c
>> @@ -20,6 +20,7 @@
>>  */
>>
>> #include "avcodec.h"
>> +#include "internal.h"
>> #include "wma.h"
>>
>> #undef NDEBUG
>> @@ -71,10 +72,16 @@ static int encode_init(AVCodecContext * avctx){
>>     for(i = 0; i < s->nb_block_sizes; i++)
>>         ff_mdct_init(&s->mdct_ctx[i], s->frame_len_bits - i + 1, 0, 1.0);
>>
>> -    avctx->block_align=
>>     s->block_align= avctx->bit_rate*(int64_t)s->frame_len / 
>> (avctx->sample_rate*8);
>> +    s->block_align = FFMIN(s->block_align, MAX_CODED_SUPERFRAME_SIZE);
>> +    avctx->block_align = s->block_align;
> 
> Is this change to make sure the output is within some certain bound? (I'm 
> not familiar enough with this code to know off-hand what this does on a 
> quick glance.)

I mistakenly thought MAX_CODED_SUPERFRAME_SIZE was a value required for
WMA, but looking at the comments it seems it was chosen arbitrarily. The
point was to allocate enough memory to avoid overwrites. But this looks
to be more complicated than I first thought since there is no bounds
checking done at all. I'm going through the code now to see if I can
figure out the maximum possible coded frame. I'll also looks to see if
we should limit the maximum target bit rate. If these aren't trivial, we
may need to add some explicit bounds checking.

[...]
>> @@ -387,7 +401,12 @@ static int encode_superframe(AVCodecContext *avctx,
>>         put_bits(&s->pb, 8, 'N');
>>
>>     flush_put_bits(&s->pb);
>> -    return put_bits_ptr(&s->pb) - s->pb.buf;
>> +
>> +    if (frame->pts != AV_NOPTS_VALUE)
>> +        avpkt->pts = frame->pts - ff_samples_to_time_base(avctx, 
>> avctx->delay);
>> +    avpkt->size = put_bits_count(&s->pb)/8;
> 
> Does this round in the right direction, compared to what put_bits_ptr - 
> s->pb.buf did before?


Yes. flush_put_bits() aligns the writer, so there is no rounding.

-Justin

_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to