[FFmpeg-soc] [RFC] Possible jpeg2k decoder rewrite

[Kostya]

On Mon, Jun 15, 2009 at 03:22:51PM +0530, Jai Menon wrote:
> On Mon, Jun 15, 2009 at 11:02 AM, Kostya<kostya.shishkov at gmail.com> wrote:
> > On Mon, Jun 15, 2009 at 09:54:09AM +0530, Jai Menon wrote:
> >> On Sun, Jun 14, 2009 at 11:51 PM, Kostya<kostya.shishkov at gmail.com> wrote:
> >> > On Sun, Jun 14, 2009 at 04:51:36PM +0000, Jai Menon wrote:
> >> >> On Wed, Jun 10, 2009 at 11:45 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
> >> >> > On Tue, Jun 09, 2009 at 03:25:52PM +0000, Jai Menon wrote:
> >> >> >> On Sat, May 2, 2009 at 8:23 PM, Michael Niedermayer<michaelni at gmx.at> wrote:
> >> >> >> > On Sun, May 03, 2009 at 12:56:02AM +0530, Jai Menon wrote:
> >> >> >> >> On 4/26/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> >> >> > On Sun, Apr 26, 2009 at 05:47:11PM +0530, Jai Menon wrote:
> >> >> >> >> >  > On 4/26/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> >> >> >  > > On Sun, Apr 26, 2009 at 04:17:48PM +0530, Jai Menon wrote:
> >> >>
> >> >> [...]
> >> >>
> >> >> >> I think I have narrowed the problem down to the tagtree decoding code,
> >> >> >> but don't know what to fix and where to fix.
> >> >> >
> >> >> > in the most generic sense you should have some difference between some
> >> >> > reference implementation and our decoder
> >> >> > whereever that is there is prior code that can be tested for being
> >> >> > different or not.
> >> >> >
> >> >> > if you tell us what variable with what value in what line of our code differs
> >> >> > from what in what line of some reference we might be able to help ...
> >> >>
> >> >> I tried rewriting that part from scratch based on the spec, and still
> >> >> get the same problems. So maybe my assumption was wrong.
> >> >>
> >> >> The file i'm using is file
> >> >> http://samples.mplayerhq.hu/jpeg2000/j2kp4files_v1_2.zip/testfiles_jp2/file3.jp2
> >> >
> >> > Ahem, that's ZIP archive and some files inside it are compressed.
> >>
> >> You mean the dir testfiles_jp2 isn't there inside that archive?
> >
> > Ah, found it.
> > Can you also debug block state (lblock, lengthinc, newpasses) before and
> > after those tree decoding calls?
> 
> Okay, here goes here is the diff -up output for attached logs :
> 
>  length increment 786
>  Size of packet 10 is 10259
>  Packet no 11
> -Inclusion bit set
> -New passes 16
> -block increment 3
> -length increment 656
> -Inclusion bit set
> -New passes 16
> -block increment 3
> -length increment 686
> -Inclusion bit set
> 
> So inclusion bit read(from the tagtree) is incorrect for packet 11.
> Complete output attached if you want to perform any other regex-fu.
 
Hmm, I've tried comparing SoC and Jasper implementations of tree decode,
looks like you have to look at node assignments (j2kdec.c):

while (curval < threshold){
    int ret;
    if ((ret = get_bits(s, 1)) > 0){
        stack[sp]->vis++;
        break;
    } else if (!ret)
        curval++;
    else
        return ret;
}

Just compare that to Jasper counterpart - I suspect assignments and
condition are both slightly wrong here.


> -- 
> Regards,
> 
> Jai