On Fri, Mar 09, 2012 at 11:10:55AM -0800, Ronald S. Bultje wrote:
> Hi,
>
> 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.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
