[FFmpeg-devel] JPEG2000 decoder

[Michael Niedermayer]

On Thu, May 05, 2011 at 02:18:02PM -0700, rukhsana afroz wrote:
> On Mon, May 2, 2011 at 3:13 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> 
> >
> > 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
> >
> > Hi Michael,
> 
> s->buf points to the decoded raw codestream extracted from the file.
> Therefore, it does not differ between our decoder and jasper. The bug, I

The buffer no of course not but where it points does, look:
using  the following:
--- ref-src/src//libjasper/jpc/jpc_t2dec.c  2007-01-19 22:43:07.000000000 +0100
+++ src//libjasper/jpc/jpc_t2dec.c  2011-05-06 18:23:44.234826999 +0200
@@ -455,6 +455,7 @@
          jpc_pi_prcno(pi), jpc_pi_lyrno(pi))) {
            return -1;
        }
+       fprintf(stderr, "after decode_packet %d\n",  jas_stream_getrwcount(in));
 ++dec->numpkts;
    }


--- a/libavcodec/j2kdec.c
+++ b/libavcodec/j2kdec.c
@@ -583,6 +583,7 @@ static int decode_packets(J2kDecoderContext *s, J2kTile *tile)
                         if (decode_packet(s, codsty, rlevel, precno, layno, qntsty->expn +
                                           (reslevelno ? 3*(reslevelno-1)+1 : 0), qntsty->nguardbits))
                             return -1;
+            av_log(s->avctx, AV_LOG_ERROR, "after decode_packet %d\n", s->buf - s->buf_start);
                     }
                 }
             }

for testfiles_jp2/file1.jp2 both produce:
after decode_packet 1704
after decode_packet 2016
after decode_packet 2351
after decode_packet 3187
after decode_packet 3937
after decode_packet 4759
after decode_packet 7837
after decode_packet 10571
after decode_packet 13450
after decode_packet 25287
after decode_packet 36233
after decode_packet 47325
after decode_packet 93349
after decode_packet 138118
after decode_packet 182075
after decode_packet 337323
after decode_packet 496033
after decode_packet 650676

But for codestreams_profile1/p1_01.j2k
after decode_packet 181
after decode_packet 182
after decode_packet 218
after decode_packet 219
after decode_packet 260
after decode_packet 261
after decode_packet 262
after decode_packet 263
after decode_packet 264
after decode_packet 273
after decode_packet 274
after decode_packet 281
after decode_packet 282
after decode_packet 283
after decode_packet 284
after decode_packet 303
after decode_packet 304
after decode_packet 305
after decode_packet 306
after decode_packet 325
vs.
after decode_packet 201
after decode_packet 284
after decode_packet 351
after decode_packet 397
after decode_packet 406
after decode_packet 415
after decode_packet 424
after decode_packet 433
after decode_packet 461
after decode_packet 538
after decode_packet 683
after decode_packet 898
after decode_packet 955
after decode_packet 1155
after decode_packet 1956
after decode_packet 4723
after decode_packet 4732
after decode_packet 4741
after decode_packet 4750
after decode_packet 4759

theres a error in or before the first decode_packet() call

a possible next step is to add more av_log/printf to bisect the area
where the first difference happens.
by repeating such bisection you will find the point where a variable
starts to differ quickly.
This may then point to another variable that needs similar bisection
or already the bug in our code.




> think is in the extracted parameters from this codestream. Extracted
> parameters define the codeblock and the data in the codeblock. I think, the
> bug is either is in "ff_j2k_init_component" called from init_tile or in
> "decode_packet" function. Actually all parameters are extracted in the
> function "ff_j2k_init_component". Therefore, I think i need to see whether
> the extracted parameters are right comparing with jasper. If you check the
> j2kdec code, you will find there is a function:
> 
> void dump(J2kDecoderContext *s, FILE *fd)
> 
> It prints all extracted parameters. I am writing similar function in jasper
> in order to compare.

Thats possible too.

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20110506/3b0afb09/attachment.asc>