On Mon, Jun 15, 2009 at 4:16 PM, Kostya<[email protected]> wrote: > On Mon, Jun 15, 2009 at 03:22:51PM +0530, Jai Menon wrote: >> On Mon, Jun 15, 2009 at 11:02 AM, Kostya<[email protected]> wrote: >> > On Mon, Jun 15, 2009 at 09:54:09AM +0530, Jai Menon wrote: >> >> On Sun, Jun 14, 2009 at 11:51 PM, Kostya<[email protected]> 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<[email protected]> 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<[email protected]> wrote: >> >> >> >> > On Sun, May 03, 2009 at 12:56:02AM +0530, Jai Menon wrote: >> >> >> >> >> On 4/26/09, Michael Niedermayer <[email protected]> wrote: >> >> >> >> >> > On Sun, Apr 26, 2009 at 05:47:11PM +0530, Jai Menon wrote: >> >> >> >> >> > > On 4/26/09, Michael Niedermayer <[email protected]> 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 _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
