[FFmpeg-devel] JPEG2000 decoder

[Michael Niedermayer]

On Mon, May 02, 2011 at 06:42:36AM -0700, rukhsana afroz wrote:
> On Sun, May 1, 2011 at 4:42 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> 
> > Thanks for the patches.
> >
> > The problem i see with testfiles_jp2/file1.jp2
> > is that the buf array in jasper contains signed values
> > while our decoder uses unsigend uint8_t
> >
> > thus the values -2,-1,0,1,2 are 0xFE,0xFF,0,1,2 on our side, both
> > have the same binary representation though namely
> > 11111110, 11111111, 00000000, 00000001, 00000010
> >
> > but their type that the compiler uses to interpret them differs.
> >
> > Now C extends things to int when passing the arguments to printf()
> > this does not change their values, they are still
> > -2,-1,0,1,2 and 0xFE,0xFF,0,1,2
> > but their representation now changes due to sign extension used for
> > signed values, thus they become
> > for jasper: 11111111111111111111111111111110,
> > 11111111111111111111111111111111, 00000000000000000000000000000000, ...
> > for us    : 00000000000000000000000011111110,
> > 00000000000000000000000011111111, 00000000000000000000000000000000, ...
> >
> > and in the last step "%x" is for unsigned values and prints them as
> > 0xFFFFFFFE, 0xFFFFFFFF,0x0, 0x1
> > and
> > 0xFE, 0xFF,0x0, 0x1
> >
> > Which looks different
> >
> > also stdout & stderr from jasper can get intermixed in somewhat
> > random ways
> >
> >
> > The following in our decoder produces identical outpiut for the values
> > if the other lines are ignored
> > for(x = 0; x < cblk->length; x++)
> >    av_log(s->avctx, AV_LOG_INFO, "0X%02x ", (int8_t)cblk->data[x]);
> >
> >
> >
> Thank you Michael for testing the code. Yes, you are right, for file1.jp2,
> the code block data is identical to jasper. But if you test p1_01.j2k file,
> you will find, code block data are completely between our decoder and jasper
> decoder.

for p1_01.j2k i get
unsupported marker 0xA17D at pos 0x145
unsupported marker 0xEFC8 at pos 0xbfa
Missing EOC

before any other output, and i would not trust data after errors

the first error happens after a 0xFF93
so i would suspect theres some difference in init_tile() or
decode_packets() or a function called by them or something surrounding
that code
I suggest you first check if the s->buf points to the same data
after these in our decoder and jasper and i suspect it wont.
From there its finding out where and why it starts to differ


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110503/d0b9b409/attachment.asc>