[FFmpeg-devel] [PATCH] Add and use av_fast_padded_malloc.

Michael Niedermayer michaelni at gmx.at
Tue Jan 17 20:36:20 CET 2012


On Tue, Jan 17, 2012 at 07:16:47PM +0100, Reimar Döffinger wrote:
> On Tue, Jan 17, 2012 at 06:17:44PM +0100, Michael Niedermayer wrote:
> > On Tue, Jan 17, 2012 at 08:08:48AM +0100, Reimar Döffinger wrote:
> > > On Tue, Jan 17, 2012 at 04:26:43AM +0100, Michael Niedermayer wrote:
> > > > On Tue, Jan 17, 2012 at 12:18:17AM +0100, Reimar Döffinger wrote:
> > > > > The same as av_fast_malloc but uses av_mallocz and keeps extra
> > > > > always-0 padding.
> > > > > This does not mean the memory will be 0-initialized after each call,
> > > > > but actually only after each growth of the buffer.
> > > > > However this makes sure that
> > > > > a) all data anywhere in the buffer is always initialized
> > > > > b) the padding is always 0
> > > > > c) the user does not have to bother with adding the padding themselves
> > > > > Fixes another valgrind warning about use of uninitialized data,
> > > > > this time with fate-vsynth1-jpegls.
> > > > > 
> > > > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > > 
> > > > LGTM
> > > 
> > > I wonder if it would be better to make the size of the padding an
> > > argument.
> > > Because I also needed below patch.
> > > Though not having to specify the padding size in almost all cases
> > > might be worth having to memset manually in a rare few.
> > > Note that I think the "si" code that tries to detect if a memset
> > > is necessary is completely broken and I have some doubts trying
> > > to avoid it will give any relevant speedup (how often will the
> > > size be exactly the same?)
> > 
> > it should be exactly the same unless the buffer size is increased
> > which should be only O(log n) times
> 
> As you pointed out not long ago, if the padding has to be 0 the buffer
> size is irrelevant, the actual size has to be the same (and unless you
> clear a lot more in some cases or do some clever tracking you have to
> run the memset both when the size increases or decreases).

Our h264 decoder uses the standard bitreader so its ok if the zeros
are farther away it cant get stuck before

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120117/a2377e58/attachment.asc>


More information about the ffmpeg-devel mailing list