[FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Michael Niedermayer michaelni at gmx.at
Tue Aug 12 10:19:05 CEST 2014

On Tue, Aug 12, 2014 at 07:56:36AM +0200, Christophe Gisquet wrote:
> Hi,
> 2014-08-12 2:34 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> >> +                if (pkt_size <= buf - orig_buf) {
> >
> > this isnt sufficient, there could be 1 byte space left, then the
> > reallocate wouldnt run and encode_slice() would run into the extra
> > padding and fail
> Yeah, you're right. I have no idea how big a slice can be, as that
> seems the extra size check here. How about FF_MIN_BUFFER_SIZE ?
> Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?

the "serious undersizing" check already depends on the assumtation
that FF_MIN_BUFFER_SIZE is larger than a slice,

> > I think either enough space should be allocated to begin with (like
> > your patch 4) then the reallocation shouldnt be needed
> Yes, the intent of that code is to try and catch bugs like the one
> fixed by patch 4. Even if it catches it, we want to fix the original
> bug.

> > or the buffer could be allocated to an average size and reallocated
> > when the encoder gets close to its end
> > in which case reallocation also would not need a warning
> > as it would be a normal operation
> I have mixed feeling over not warning (and asking a sample). Sure we
> may catch most issues with reallocating, but we can't get a guarantee

what i meant was that in case we knowingly allocate a smaller buffer
than the max then reallocation would not be a "abnormal" condition
and thus would not need a warning.
smaller mallocs might be faster, so if for example a 50% sized
buffer is enough for 99.9% of cases needing realloc only in 0.1%
it might be faster to allocate less than the maximum
but i made no benchmarks so it might be negligible ...

> that the encode can complete (hence patch 1) in case of a serious
> undersizing. Case in point: I had used a growth that was the maximum
> between the quarter of the allocated size and twice the needed size,
> and it crashed without patch 2.
> -- 
> Christophe
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140812/29b95a14/attachment.asc>

More information about the ffmpeg-devel mailing list