On Mon, May 16, 2016 at 01:33:37PM -0300, Claudio Freire wrote: > On Mon, May 16, 2016 at 12:26 PM, Kieran Kunhya <kier...@obe.tv> wrote: > >> Testcase is fate-aac-pred-encode > >> > >> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > >> --- > >> libavcodec/aacenc_is.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/libavcodec/aacenc_is.c b/libavcodec/aacenc_is.c > >> index 473897b..e5cfa14 100644 > >> --- a/libavcodec/aacenc_is.c > >> +++ b/libavcodec/aacenc_is.c > >> @@ -64,6 +64,9 @@ struct AACISError ff_aac_is_encoding_err(AACEncContext > >> *s, ChannelElement *cpe, > >> abs_pow34_v(I34, IS, sce0->ics.swb_sizes[g]); > >> maxval = find_max_val(1, sce0->ics.swb_sizes[g], I34); > >> is_band_type = find_min_book(maxval, is_sf_idx); > >> + > >> + av_assert0(minthr != 0.0); > >> + > >> dist1 += quantize_band_cost(s, &L[start + (w+w2)*128], L34, > >> sce0->ics.swb_sizes[g], > >> sce0->sf_idx[w*16+g], > >> -- > >> 1.7.9.5 > >> > >> > >> > > Does this assert on actual input data?
yes, with the patch fate fails: Test aac-pred-encode failed. Look at tests/data/fate/aac-pred-encode.err for details. make: *** [fate-aac-pred-encode] Error 134 > > A threshold of 0 would in theory cause a zeroed band (zeroes[i] == 1), > and those should be skipped. > > I think the proper fix would be figuring out why those aren't being > skipped, if that is the case. i never meant this patch to be a proper fix, more a bug report ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
