[FFmpeg-devel] JPEG2000 decoder

[rukhsana afroz]

Hi Michael,

On Mon, May 30, 2011 at 6:36 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Sun, May 29, 2011 at 05:49:05AM -0700, rukhsana afroz wrote:
> > Hi Michael,
> >
> > On Fri, May 27, 2011 at 7:10 AM, Michael Niedermayer <michaelni at gmx.at
> >wrote:
> >
> > > On Fri, May 27, 2011 at 04:28:29AM -0700, rukhsana afroz wrote:
> > > > Hi Michael,
> > > >
> > > > On Tue, May 24, 2011 at 1:10 AM, rukhsana afroz <
> > > rukhsana.afroz at gmail.com>wrote:
> > > >
> > > > > Hi Michael,
> > > > >
> > > > > On Fri, May 20, 2011 at 10:49 PM, rukhsana afroz <
> > > rukhsana.afroz at gmail.com
> > > > > > wrote:
> > > > >
> > > > >> Hi Michael,
> > > > >>
> > > > >>
> > > > >> On Thu, May 19, 2011 at 3:38 PM, rukhsana afroz <
> > > rukhsana.afroz at gmail.com
> > > > >> > wrote:
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>> On Thu, May 19, 2011 at 3:32 PM, rukhsana afroz <
> > > > >>> rukhsana.afroz at gmail.com> wrote:
> > > > >>>
> > > > >>>> Hi Michael,
> > > > >>>>
> > > > >>>>
> > > > >>>> On Sun, May 15, 2011 at 5:00 PM, Michael Niedermayer <
> > > michaelni at gmx.at>wrote:
> > > > >>>>
> > > > >>>>>
> > > > >>>>> We will have to implement multiple codeword segments.
> > > > >>>>>
> > > > >>>>> Also sofar, good work!
> > > > >>>>>
> > > > >>>>>
> > > > >>>> Sorry for the late reply. If I implement codeblock segment, its
> > > going to
> > > > >>>> affect from packet decoding process to the subsequent deoding
> > > process till
> > > > >>>> the last. Therefore, I have to be properly planned in order to
> > > accomplish
> > > > >>>> these changes. Here, I have put patch for incorporating multiple
> > > codeblock
> > > > >>>> segment. I had to create two more structures and modify J2KCblk
> > > sturucture
> > > > >>>> as well. This patch is just for the modification/creation on the
> > > structures.
> > > > >>>> I am also writing some miscellaneous function and I will post
> those
> > > in my
> > > > >>>> subsequent emails.
> > > > >>>>
> > > > >>>
> > > > >> I have modified the decode_packet function incorporating multiple
> > > codeword
> > > > >> segment. Here, I have attached the patch for the required changes.
> I
> > > have
> > > > >> taken the help from jasper code while writing this code, because
> only
> > > the
> > > > >> document is not sufficient to incorporate these changes. I have
> not
> > > tested
> > > > >> this code yet. Once, I test it, I also let you know. If you have
> any
> > > > >> suggestion on this patch, please let me know.
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > While doing arithmetic coding operation in decode_cblk function one
> > > > > term/variable is "bpno". Coding operation (decode_sigpass,
> > > decode_refpass,
> > > > > decode_clpass) uses this variable to determine the data of each
> > > codeblock in
> > > > > different contexts. This variable has been set in our decoder:
> > > > >
> > > > >
> > > > > bpno = cblk->nonzerobits - 1
> > > > >
> > > > > And, jasper has set this variable as follows:
> > > > >
> > > > > bpno = band->roishift + band->numbps - 1 - (cblk->numimsbs +
> > > (seg->passno +
> > > > > i - cblk->firstpassno + 2) / 3);
> > > > >
> > > > > band->roishift is the value got from processing the RGN marker and
> > > > > band->numbps is also the value got from some other marker. Our
> decoder
> > > has
> > > > > not processed this marker.  cblk->numimsbs is similar to our
> decoder's
> > > > > cblk->nonzerobits. Other part of this variable is segment specific
> and
> > > that
> > > > > makes sense. I need you suggestion on how to set this variable. I
> will
> > > > > explain more tomorrow on IRC chat.
> > > > >
> > > > >
> > > > >
> > > > Here, I have attached two patches which cove all changes due to
> multiple
> > > > codeblock segment. I have tested decode_packet function, but not
> > > decode_cblk
> > > > yet.
> > >
> > > thx, some comments below
> > >
> > > [...]
> > > > -/* Tier-1 coding pass types. */
> > > > -#define      J2K_SIGPASS     0       /* significance */
> > > > -#define      J2K_REFPASS     1       /* refinement */
> > > > -#define      J2K_CLNPASS     2       /* cleanup */
> > >
> > > that contains tabs, tabs cannot be commited to our git
> > > i suggest you configure your editor not to insert tabs or trailing
> > > whitespace (many editors can be configured that way)
> > >
> > > also the patch is reversed (like diff a b instead of diff b a )
> > >
> > > the second patch doesnt apply:
> > >  patching file libavcodec/j2kdec.c
> > > Hunk #1 succeeded at 463 (offset -5 lines).
> > > Hunk #2 succeeded at 570 (offset -21 lines).
> > > Hunk #3 FAILED at 604.
> > > Hunk #4 succeeded at 608 (offset -27 lines).
> > > Hunk #5 succeeded at 758 (offset -27 lines).
> > > Hunk #6 succeeded at 764 (offset -35 lines).
> > >
> > > [...]
> > >
> > >
> > > if you use git you can turn commits into patches trivially with
> > > git format-patch -2
> > > (that would turn the last 2 commits into patches together with author&
> > >  commit message)
> > >
> > > Sorry for the late reply. Problem is, right now i am debugging the code
> and
> > thats why there are lots of log messages in the code, therefore the
> previous
> > patches' lots of hunk failed in the code you have. I have my latest code
> in:
> >
> > https://github.com/rukhsana/j2k/tree/r10
>
> thx
>
>
> >
> > You can check it out from here. Once, we are sure that the code is
> perfect,
> > I will make the patch on the original code, then you can commit to
> ffmpeg.
> > Right now I have found a problem in the decode_packet function. At the
> > beginning of decode_packet function, there are following lines:
> >
> > if (!(ret = get_bits(s, 1))){
> >         //j2k_flush(s);
> >         return 0;
> >     } else if (ret < 0)
> >         return ret;
> >
> > This bit checks whether the packet header exists or not. I have given log
> > messages before and after of these lines. I get the pointer (s->buf) does
> > not move after these lines. This problems even exist for the other files
> > which can be correctly decoded, For the file p1_01.j2k, I get the
> following
> > log messages before and after of these lines.
> >
> > before flush pointer: 152
> > after flush pointer: 152
> >
> > But from the jasper code, if you check, pointer moves to 153. Therefore,
> > some of the packet header information apparently look correct, but
> actually
> > it stucks to a problem if i consecutively decode the following packets. I
> am
> > checking the get_bits function. Could you please have a look at this
> > function?
>
> maybe jaspers and ours advance the pointer at a slightly different
> spot in the implementation
>
>
As per the discussion on IRC chat, I checked where s->bit_index gets
modified. I see, in our decoder that s->bit_index has been manually set to 8
at the beginning of decoding packet. whereas, in jasper, I did not see this.
Also, jasper always reads the entire byte to check present bit even for
other files, like file1.jp2 etc. Whereas, our decoder does not do so. I need
your suggestion on this as i do not find any clue in the doc for this. I am
waiting for you on the IRC chat.

Thanks

-- 
Rukhsana Ruby
Phd Student
Department of Electrical & Computer Engineering
The University of British Columbia
============================