[FFmpeg-devel] [PATCH] aacenc: Fix issues with huge values of bit_rate.

[Michael Niedermayer]

On Sat, Apr 07, 2012 at 11:54:05AM +0200, Reimar Döffinger wrote:
> On Sat, Apr 07, 2012 at 12:34:24AM +0200, Michael Niedermayer wrote:
> > On Fri, Apr 06, 2012 at 03:58:19PM +0200, Reimar Döffinger wrote:
> > > Do not pointlessly call ff_alloc_packet2 multiple times,
> > > and fix an infinite loop by clamping the maximum
> > > number of bits to target in the algorithm that does
> > > not use lambda.
> > > 
> > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > ---
> > >  libavcodec/aaccoder.c       |    3 +++
> > >  libavcodec/aacenc.c         |    4 ++--
> > >  tests/ref/acodec/aac        |    4 ++++
> > >  tests/ref/acodec/dca        |    4 ++++
> > >  tests/ref/acodec/nellymoser |    4 ++++
> > >  tests/ref/acodec/ra144      |    4 ++++
> > >  6 files changed, 21 insertions(+), 2 deletions(-)
> > >  create mode 100644 tests/ref/acodec/aac
> > >  create mode 100644 tests/ref/acodec/dca
> > >  create mode 100644 tests/ref/acodec/nellymoser
> > >  create mode 100644 tests/ref/acodec/ra144
> > > 
> > > diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
> > > index 25187b7..b6fefd3 100644
> > > --- a/libavcodec/aaccoder.c
> > > +++ b/libavcodec/aaccoder.c
> > > @@ -721,6 +721,9 @@ static void search_for_quantizers_twoloop(AVCodecContext *avctx,
> > >      int allz = 0;
> > >      float minthr = INFINITY;
> > >  
> > > +    // for values above this the decoder might end up in an endless loop
> > > +    // due to always having more bits than what can be encoded.
> > > +    destbits = FFMIN(destbits, 5800);
> > >      //XXX: some heuristic to determine initial quantizers will reduce search time
> > >      //determine zero bands and upper limits
> > >      for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
> > 
> > not really pretty but should be ok if the value is sufficient
> 
> Sufficient in which way?
[...]

this below:

> As to whether it is low enough I am not as sure since the overhead
> is not trivial to calculate, so I basically just tested that 5815
> was enough for my samples to work and gave it a few bits headroom
> just to be sure.

maybe it could be checked in a more robust way then, that does not
depend on these fine details?


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

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20120407/dbd1219e/attachment.asc>