[FFmpeg-devel] [PATCH 1/4] lavf: add write_uncoded_frame() API.

Michael Niedermayer michaelni at gmx.at
Sat Jan 4 16:19:13 CET 2014

On Sat, Jan 04, 2014 at 04:07:12PM +0100, Nicolas George wrote:
> Le quintidi 15 nivôse, an CCXXII, Michael Niedermayer a écrit :
> > a consistency check that triggers out of array writes doesnt seem
> > that great
> > 
> > size = 'F' // AVFrame
> > could be used but still this feels hackish
> > 
> > or a function could be added to libavutil to return the actual size
> > of the AVFrame struct
> In my mind, if an AVPacket contains a pointer to an AVFrame, it should not
> be copied, and in fact its size should not be used at all. If it happens,
> that is a bug in the library that needs fixing immediately.
> Setting size to an absurdly large value will cause a crash immediately if
> someone tries to copy it. That is easy to debug.
> Setting size to the correct size, or almost the correct size, will cause the
> data structure to be copied, but without incrementing the buffers' reference
> count. That is very hard to debug.
> Setting size to a very small value will cause the structure to be partially
> copied. If we are lucky, the rest will be left uninitialized and valgrind
> will catch it; if we are not, the rest will be blanked. Moderately hard to
> debug.
> So I still think that an absurdly large value is a good choice.
> Or did I miss something?

what about negative values ?
these, at least currently should fail at av_malloc() before copying


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/20140104/d97c6301/attachment.asc>

More information about the ffmpeg-devel mailing list