[FFmpeg-devel] JPEG2000 decoder
rukhsana afroz
rukhsana.afroz at gmail.com
Sun May 8 22:36:05 CEST 2011
Hi Michael,
Sorry for the late reply.
On Fri, May 6, 2011 at 9:43 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
>
> 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.
>
>
>
The problem I found in the function decode_packet. I have checked init_tile
function. It looks apparently ok. In fact, s->buf starts differing inside
decode_packet function. For the first packet, at the beginning of
decode_packet function, pointer in our decoder and jasper is the same. I
also gave printf before the process of J2K_EPH marker. I found, at this
place, pointer starts differing even for the first packet. And therefore,
for the rest of the packets, pointer are different as well. I found our
decoder did not process J2K_SOP (start of pkt) marker which jasper has
processed. SOP marker is 6 bytes. I believe, I need to check the
decode_packet function in order to fix this bug. I also found, our decoder
did not process many packet related markers (PPM, PPT, PLT, PLM etc.) which
jasper has processed. The following are two patches as the evidence of my
argument.
our decode:
@@ -495,6 +498,8 @@ static int decode_packet(J2kDecoderContext *s,
J2kCodingStyle *codsty, J2kResLev
{
int bandno, cblkny, cblknx, cblkno, ret;
+ av_log(s->avctx, AV_LOG_INFO, "start decode_packet %d\n", s->buf -
s->buf_start);
+
if (!(ret = get_bits(s, 1))){
j2k_flush(s);
return 0;
@@ -539,6 +544,8 @@ static int decode_packet(J2kDecoderContext *s,
J2kCodingStyle *codsty, J2kResLev
}
j2k_flush(s);
+ av_log(s->avctx, AV_LOG_INFO, "before end of packet header %d\n",
s->buf - s->buf_start);
+
if (codsty->csty & J2K_CSTY_EPH) {
if (AV_RB16(s->buf) == J2K_EPH) {
s->buf += 2;
our decoder's output: I found the decoder even does not go to J2K_EPH marker
for some packets.
start decode_packet 146
before end of packet header 149
start decode_packet 181
before end of packet header 182
start decode_packet 182
before end of packet header 186
start decode_packet 218
before end of packet header 219
start decode_packet 219
before end of packet header 222
start decode_packet 260
before end of packet header 261
start decode_packet 261
start decode_packet 262
start decode_packet 263
start decode_packet 264
before end of packet header 267
start decode_packet 273
start decode_packet 274
before end of packet header 277
start decode_packet 281
start decode_packet 282
start decode_packet 283
start decode_packet 284
before end of packet header 287
start decode_packet 303
start decode_packet 304
start decode_packet 305
start decode_packet 306
before end of packet header 309
jasper patch:
--- ../../orig_jasper/jasper-1.900.1/src/libjasper/jpc/jpc_t2dec.c
2007-01-19 13:43:07.000000000 -0800
+++ libjasper/jpc/jpc_t2dec.c 2011-05-08 13:02:35.748666000 -0700
@@ -191,6 +191,9 @@
/* Avoid compiler warning about possible use of uninitialized
variable. */
+
+ fprintf(stdout, "start decode_packet %d\n",
jas_stream_getrwcount(in));
+
bodylen = 0;
discard = (lyrno >= dec->maxlyrs);
@@ -345,6 +348,8 @@
(unsigned long) bodylen);
}
+ fprintf(stdout, "before end of pkt header %d\n",
jas_stream_getrwcount(in));
+
if (cp->csty & JPC_COD_EPH) {
if (jpc_dec_lookahead(pkthdrstream) == JPC_MS_EPH) {
if (!(ms = jpc_getms(pkthdrstream, dec->cstate))) {
jasper output:
start decode_packet 146
before end of pkt header 158
start decode_packet 201
before end of pkt header 219
start decode_packet 284
before end of pkt header 294
start decode_packet 351
before end of pkt header 364
start decode_packet 397
before end of pkt header 404
start decode_packet 406
before end of pkt header 413
start decode_packet 415
before end of pkt header 422
start decode_packet 424
before end of pkt header 431
start decode_packet 433
before end of pkt header 442
start decode_packet 461
before end of pkt header 476
start decode_packet 538
before end of pkt header 555
start decode_packet 683
before end of pkt header 700
start decode_packet 898
before end of pkt header 910
start decode_packet 955
before end of pkt header 983
start decode_packet 1155
before end of pkt header 1198
start decode_packet 1956
before end of pkt header 2047
start decode_packet 4723
before end of pkt header 4730
start decode_packet 4732
before end of pkt header 4739
start decode_packet 4741
before end of pkt header 4748
start decode_packet 4750
before end of pkt header 4757
>
>
> > 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk3EJTgACgkQYR7HhwQLD6u9LQCfeIiDsE3gMGRH5wxXs1iBskMm
> 03kAnRGAgd5yx7oz7KsxuGkLegu1dDhC
> =nMGm
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
--
Rukhsana Ruby
Phd Student
Department of Electrical & Computer Engineering
The University of British Columbia
============================
More information about the ffmpeg-devel
mailing list