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