[FFmpeg-trac] #9769(avcodec:open): JPEG 2000 decoder: decoder should ignore any data that appears after End of Codestream marker 0xFFD9

[FFmpeg]

#9769: JPEG 2000 decoder: decoder should ignore any data that appears after End of
Codestream marker 0xFFD9
-------------------------------------+-------------------------------------
             Reporter:  Pierre-      |                    Owner:  (none)
  Anthony Lemieux                    |
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  j2k          |               Blocked By:
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Balling):

 > The lossless J2K is smaller, and in fact smaller than JXL.

 '''That is too be expected''', you introduce some insane spatial and
 temporal artifacts when you do lossy encoding of JPEG2000 (see wikipedia
 https://en.wikipedia.org/wiki/JPEG_2000#/media/File:Jpeg2000_2
 -level_wavelet_transform-lichtenstein.png). Lossless encoding of those
 artifacts is a very hard thing. Now if you have lets says SVG vector
 source (be it OTF of that zero on the black background) (that is not yet
 rasterised) that is even less data. I will attach new jxl of your lossless
 j2k that is again even smaller.

 Lossy j2k1.8_0_5.j2c does not have such a problem with SOF, so it is kinda
 obvious this is a bug with Kakadu.

 >for whatever reason, j2k1.j2c contains bad bytes beyond the first FFD9
 (end of codestream marker).

 Oh. Okay, but that is still a bug in Kakadu.

 > ISO/IEC 15444-4 | Rec. ITU-T T.803 (J2K conformance testing) specifies
 tolerances for decoding of lossy codestreams.

 Same happens in normal JPEG library. There is a difference in decoding
 with old stable and new libraries. We in ffmpeg use the old stable
 algorithm, this off-by-one should be fixed by comparing to original.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9769#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker