[FFmpeg-soc] [RFC] Possible jpeg2k decoder rewrite

[Michael Niedermayer]

On Tue, Jun 09, 2009 at 03:25:52PM +0000, Jai Menon wrote:
> On Sat, May 2, 2009 at 8:23 PM, Michael Niedermayer<michaelni at gmx.at> wrote:
> > On Sun, May 03, 2009 at 12:56:02AM +0530, Jai Menon wrote:
> >> On 4/26/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Sun, Apr 26, 2009 at 05:47:11PM +0530, Jai Menon wrote:
> >> >  > On 4/26/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >  > > On Sun, Apr 26, 2009 at 04:17:48PM +0530, Jai Menon wrote:
> >>
> >> [...]
> >>
> >>
> >> > The last time around a project writing a j2k decoder (and encoder)
> >> >  failed.
> >> >  What makes you belive yours would succeed if you throw the existing
> >> >  work away?
> >>
> >> I have no clue if it will succeed or not. As for the existing work,
> >> the current code seems to be written for parsing/decoding a single
> >> type of file. And the author didnt bother documenting anything. Yes, I
> >> know code is supposed to be the documentation etc..
> >
> > So let me ask differently
> > what would you do differently if you would rewrite it?
> > And why would that be better?
> >
> >
> >>
> >> [...]
> >>
> >> >  > - component subsampling is not supported. this is required by a bunch
> >> >  > of profile 0 test files. right now only 1x1 supported.
> >> >
> >> >
> >> > this must be fixed, but i dont see how thats a argument in favor of a
> >> >  rewrite, and that applies to the other points here too
> >>
> >> I tried fixing this, but the decode_packet code seems broken, it
> >> doesn't read the entire bitstream in the tile part. Do you know if
> >> there are any known issues with it? I was having some difficulty
> >> correlating that part to the spec.
> >
> > Theres at least one bug in the bitstream decoding part, i dont know more
> > details though, i just see some corruption in some areas in some files.
> > The issue seemed random and not triggered by a specific feature in the
> > file last time i checked more carefull.
> 
> I think I have narrowed the problem down to the tagtree decoding code,
> but don't know what to fix and where to fix.

in the most generic sense you should have some difference between some
reference implementation and our decoder
whereever that is there is prior code that can be tested for being
different or not.

if you tell us what variable with what value in what line of our code differs
from what in what line of some reference we might be able to help ...


> 
> > Debuging this will likely be fastest by taking some reference decoder
> > and adding printfs to it and add the same printfs to soc j2k and then
> > diff them to see where they start to differ.
> 
> Most packets are decoded correctly, but in some files, the inclusion
> bit read (by decoding the precinct tagtree) is not correct which
> causes decoding to go haywire. Sadly, thats all I have found till now
> ....

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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20090610/8e8436aa/attachment.pgp>