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

[Michael Niedermayer]

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.

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.

A rewrite woudld not safe you from such debuging either, your new code
would as well have its bugs that will require such comparissions to the
reference decoder.

an alternative to above might be to truncate the bitstream and then check
per binary search where a difference first appears.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/20090502/87b26645/attachment.pgp>