On Fri, Mar 09, 2012 at 01:38:55PM -0800, Ronald S. Bultje wrote:
> 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...

You can look at libmpcdec yourself. I don't remember much detail about
Moosepack either, so you are as good as me.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to