[FFmpeg-cvslog] r12593 - trunk/libavcodec/ac3dec.c
Måns Rullgård
mans
Wed Mar 26 02:38:04 CET 2008
Michael Niedermayer <michaelni at gmx.at> writes:
> On Wed, Mar 26, 2008 at 12:31:44AM +0000, 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 ive not considered this, but as the context is allocated via common
> code it is sadly allocated by av_mallocz() which zeros it and thus forces
> asisgnment to physical pages.
Could av_mallocz() be made to use calloc() somehow?
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-cvslog
mailing list