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

[Jai Menon]

On Mon, Jun 15, 2009 at 4:16 PM, Kostya<kostya.shishkov at gmail.com> wrote:
> 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.

Umm...After rewriting tagtree decode from scratch, I decided to do one
last thing. I tried completely replacing thee old tagtree approach
with jasper's code, that is per-node lower bound. Then I copypasted
the decoding code ad-hoc from jasper. Still the exact same problem
when reading packet 11. Sounds weird but true....

-- 
Regards,

Jai