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

Michael Niedermayer michaelni
Wed Mar 26 03:25:36 CET 2008


On Wed, Mar 26, 2008 at 01:38:04AM +0000, M?ns Rullg?rd wrote:
> 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?

Not easily, the problem is av_mallocz() gurantees 16byte alignment.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080326/2eb04246/attachment.pgp>



More information about the ffmpeg-cvslog mailing list