Hi, On Fri, Mar 9, 2012 at 12:01 PM, Kostya Shishkov <[email protected]> wrote: > On Fri, Mar 09, 2012 at 11:10:55AM -0800, Ronald S. Bultje wrote: >> On Fri, Mar 9, 2012 at 11:08 AM, Kostya Shishkov >> <[email protected]> wrote: >> > On Fri, Mar 09, 2012 at 10:37:58AM -0800, Ronald S. Bultje wrote: >> >> On Fri, Mar 9, 2012 at 10:35 AM, Kostya Shishkov >> >> <[email protected]> wrote: >> >> > On Fri, Mar 09, 2012 at 10:31:59AM -0800, Ronald S. Bultje wrote: >> >> >> From: "Ronald S. Bultje" <[email protected]> >> >> >> >> >> >> MPC8 allows indices of mpc_CC up to -1, and mpc_SCF up to -6, thus pad >> >> >> the tables by that much on the left end. >> >> >> >> >> >> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind >> >> >> CC: [email protected] >> >> >> --- >> >> >> libavcodec/mpc.c | 6 +++--- >> >> >> libavcodec/mpc7.c | 4 ++-- >> >> >> libavcodec/mpcdata.h | 10 +++++++--- >> >> >> 3 files changed, 12 insertions(+), 8 deletions(-) >> >> > >> >> > I'd rather prefer clip/error on invalid values in MPC8 decoder. >> >> >> >> I have a hard time calling them invalid. In particular for mpc_CC[], >> >> the mpc8 decoder very specifically has code handling -1, it appears to >> >> be adding white noise or so. >> > >> > clip scalefactors then and pad mpc_CC[] then >> >> I still wonder why the bitstream very specifically allows for >> scalefactor indices up to -6. Why allow for that if -6 to -1 are >> unused or clipped? I'd rather want to know their meaning. > > Looks like it clips it - it uses SCF_Index_{L,R}[Band] & 0xFF and initialises > only first 128 entries in SCF table.
So the -1 to -6 values are uninitialized/zero then? That seems rather odd... Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
