On Tue, Aug 12, 2014 at 11:56:21AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2014-08-12 10:19 GMT+02:00 Michael Niedermayer <michae...@gmx.at>:
> > the "serious undersizing" check already depends on the assumtation
> > that FF_MIN_BUFFER_SIZE is larger than a slice,
> 
> Yes, and here lies the issue: if we haven't been able to guess it
> correctly previously, how likely are we to guess it correctly here?
> Take 2*max(previous_slice_size) ?

I think if we allocate based on a upper bound and that turns out
not enough, its better to fail and tell the user to report a bug
than to try to reallocate.
The condition that we run out of space when we intended to allocate
enough is not supposed to happen, if it does happen theres something
wrong and that should be fixed. This assumes we intend to
allocate a amount that is always large enough of course.

for the per slice check we could take 2 or 3 times the upper bound
of a slice and allocate more by that. And then check that we still
have that amount before we start each slice. This should give us
a 2-3 times saftey factor for underestimating slice sizes. While only
slightly increasing the overall buffer size

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

Attachment: signature.asc
Description: Digital signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to