Hi Michael, On Mon, May 30, 2011 at 6:36 AM, Michael Niedermayer <[email protected]>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 <[email protected] > >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 < > > > [email protected]>wrote: > > > > > > > > > Hi Michael, > > > > > > > > > > On Fri, May 20, 2011 at 10:49 PM, rukhsana afroz < > > > [email protected] > > > > > > wrote: > > > > > > > > > >> Hi Michael, > > > > >> > > > > >> > > > > >> On Thu, May 19, 2011 at 3:38 PM, rukhsana afroz < > > > [email protected] > > > > >> > wrote: > > > > >> > > > > >>> > > > > >>> > > > > >>> On Thu, May 19, 2011 at 3:32 PM, rukhsana afroz < > > > > >>> [email protected]> wrote: > > > > >>> > > > > >>>> Hi Michael, > > > > >>>> > > > > >>>> > > > > >>>> On Sun, May 15, 2011 at 5:00 PM, Michael Niedermayer < > > > [email protected]>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 ============================
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
