[FFmpeg-cvslog] r12593 - trunk/libavcodec/ac3dec.c

[Justin Ruggles]

M?ns Rullg?rd wrote:
> Justin Ruggles <justinruggles at bellsouth.net> writes:
> 
>> Uoti Urpala wrote:
>>> On Tue, 2008-03-25 at 19:38 -0400, Justin Ruggles wrote:
>>>> jbr wrote:
>>>>> @@ -191,6 +194,7 @@ typedef struct {
>>>>>      GetBitContext gbc;                      ///< bitstream reader
>>>>>      AVRandomState dith_state;               ///< for dither generation
>>>>>      AVCodecContext *avctx;                  ///< parent context
>>>>> +    uint8_t input_buffer[AC3_MAX_FRAME_SIZE];   ///< temp buffer to prevent overread
>>>>>  } AC3DecodeContext;
>>>> Right after I applied this, it occurred to me that it might be better to
>>>> allocate this with av_malloc() at decoder init depending on
>>>> error_resiliance.  Does that sound like a good idea?
>>> I haven't looked at the specific code in this case, but generally moving
>>> a commonly used buffer out of a context struct could hurt performance.
>>> The compiler must either generate extra indirection through the struct
>>> or reserve another register to keep the location of the buffer. OTOH if
>>> time is mostly spent elsewhere, or if accesses to be buffer are not
>>> interleaved with code which would also need to access the struct, then
>>> it might not matter.
>> Thanks Uoti. This is definitely a commonly used buffer, so maybe it is
>> not a big enough trade-off just to reduce memory footprint when running
>> with zero error_resilience.  I will test the speed, but if what you say
>> is true, it will probably be slower.
> 
> On most systems, the extra allocation won't matter (much), since
> physical pages are allocated only when written to.

Indeed, this change had pretty much zero affect on performance on my system.

So does the attached look ok?

-Justin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ac3_malloc_buffer.diff
Type: text/x-diff
Size: 1376 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080325/68955144/attachment.diff>