[FFmpeg-devel] JPEG2000 decoder

[Michael Niedermayer]

Hi

On Sun, May 15, 2011 at 01:01:36AM -0700, rukhsana afroz wrote:
> On Sun, May 15, 2011 at 12:18 AM, rukhsana afroz
> <rukhsana.afroz at gmail.com>wrote:
> 
> >
> > Hi Michael,
> >
> > I am re-writing the function "decode_packet". Now, I am actually at the
> > beginning of this function. I have confusion with the problems I have
> > described here. When I process the COD marker, I found the coding style of
> > this marker is 6. According to page 45 (Table A-13), if 2nd LSB of csty is
> > 1, the packet header should have SOP marker and if 3rd LSB of csty is 1, the
> > packet header should have EPH header. Since, these marker are not must, our
> > decoder did not implemnet this. I have implemneted these marker while
> > decoding packet header. But the problem i found with the file p1_01.j2k has
> > also COC marker. According to the spec when COC marker comes, the parameters
> > of COC marker will be replaced by COD marker parameters. I found in marker,
> > csty value is 0. It means packet should not have SOP or EPH headers.
> > However, I have checked jasper code, its csty value is 6 and it keeps COD
> > marker's csty without replacing COC marker's csty. Therefore, SOP and EPH
> > have been processed in their code. Please let me know, how you do think this
> > problem. Should my logic be:
> >
> > if COC_csty is ZERO
> >    s->codsty.csty = COD_csty;
> > end
> >
> > Or, the current decoder does just replace like the following:
> >
> > s->codsty.csty = COC_csty
> >
> >
> > I think, I will be able to better explain you stuffs in IRC chat.
> >
> >
> Hi Michael,
> 
> For the first packet, without checking csty value from COD or COC marker, I
> processed SOP marker (assuming there is a SOP marker). I found all of the
> packet headers value can be correctly retrieved (comparing with jasper)
> except the last one. The lines of code in the decode_packet function is
> below:
> 
>  if ((ret = get_bits(s, av_log2(newpasses) + cblk->lblock)) < 0)
>                     return ret;
> 
> ret value by our decoder is 49 whereas for the jasper this is 41 (sum of
> following numbers). In fact, our decoder gets this value assuming single
> codeword segment. But according to jasper code, this is also actually
> multiple codeword segment therefore the retrieved values from jasper are:
> 
> len = 12
> len = 7
> len = 6
> len = 1
> len = 2
> len = 12
> len = 1
> 
> Our decoder did not implemnet multiple codeword segment. Page number in the
> spec for this feature is 79. Please have a look at this, and please let me
> know if you have any suggestion.

We will have to implement multiple codeword segments.

Also sofar, good work!

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20110516/373194a1/attachment.asc>