[MPlayer-dev-eng] [PATCH] ffvhuff: encoded frame too large

Reimar Doeffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Thu Jun 28 13:29:00 CEST 2007


Hello,
On Mon, Jun 25, 2007 at 03:46:19PM -0600, Loren Merritt wrote:
> On Mon, 25 Jun 2007, infernix wrote:
> > Loren Merritt wrote:
> >> On Fri, 13 Apr 2007, infernix wrote:
> >>> I'm encoding to a large resolution ffvhuff file (source is 1920x1040) and 
> >>> am occasionally getting this message from mencoder:
> >>> [ffvhuff @ 0x8847980]encoded frame too large
> >>> Does anyone know what happens to a frame when this error occurs? Does it 
> >>> get discarded? Is it because I'm encoding to avi?
> >
> >> MEncoder allocates a constant buffer size of 2MB to hold a compressed 
> >> frame. 1080p is 3MB uncompressed, and huffyuv (or any lossless codec) can't 
> >> always compress a 3MB frame into less than 2MB.
> >> Solution: increase the buffer size, and/or make it dynamic.
> >
> > Is there any reason why this defaults to 2MB in svn? I keep patching it to 
> > 4MB for every build, and I can't imagine it would hurt to change it to that 
> > by default - but IANAC.
> 
> No, but there's also no reason to expect 4MB, or any other constant size, 
> is enough. And no one has implemented a variable size buffer yet. The 
> simplest incarnation of that might be to add something to lavc's api 
> allowing each encoder to guess in advance how big its frames can get.

No idea if that info is available at the right place beforehand, but why
not just e.g. twice the decoded frames size? That should be enough for
anything that deserves the name "encoder" and is not too ridiculously
large.
Audio probably is more of a problem though.

Greetings,
Reimar Doeffinger



More information about the MPlayer-dev-eng mailing list