Opened 14 months ago

Last modified 11 months ago

#10121 open enhancement

jpeg2000 decoder fails on conformance codestream p0_10.j2k

Reported by: Pierre-Anthony Lemieux Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: j2k
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
The jpeg2000 decoder fails to accurately decode the p0_10.j2k image from the ISO/ITU conformance codestream set:

  • the error message bpno became invalid is emitted
  • there are significant errors in the lower left quadrant when compared to the reference image c1p0_10-{1,2,3}.pgx

A description of the codestream is available at p0_10syntax.txt

How to reproduce:

ffmpeg -flags +bitexact -i p0_10.j2k p0_10.png
ffmpeg version eef763c7057a7f5f4b7dae7855d07b2a6da8b537

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (8)

comment:1 by Carl Eugen Hoyos, 14 months ago

Keywords: j2k added; jpeg2000 removed
Priority: normalwish
Type: defectenhancement
Version: unspecifiedgit-master

comment:2 by Balling, 14 months ago

Appears to be different with #5360. That one is a bug in -c:v jpeg2000 native encoder and still decodes bitperfectly.

Also, that is HTJ2K codestreams, no? That patch is not yet apllied: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20221215190033.19251-1-etemesicaleb@gmail.com/

Last edited 14 months ago by Balling (previous) (diff)

comment:3 by Pierre-Anthony Lemieux, 14 months ago

It is not an HTJ2K codestream. Description at https://gitlab.com/wg1/htj2k-codestreams/-/blob/master/descriptions_profile0/p0_10syntax.txt

That one is a bug in -c:v jpeg2000 native encoder and still decodes bitperfectly.

I encountered the bug using the native decoder on the master branch. What do you mean by bitperfectly?

comment:4 by Balling, 14 months ago

What do you mean by bitperfectly?

The bug there is in the lossless native encoder. Now compare to openjpeg encode where decoder does not warn on. It is still lossless though.

Last edited 14 months ago by Balling (previous) (diff)

comment:5 by Pierre-Anthony Lemieux, 14 months ago

The bug there is in the lossless native encoder.

Two different encoders are not expected to produce the same codestreams.

The native encoder might therefore be good, but create a codestream that results in a different code path in the native decoder, which triggers the bpno warning.

comment:6 by Balling, 14 months ago

Status: newopen

The native encoder might therefore be good, but create a codestream that results in a different code path

It is also creates bigger file. Quite bigger.

BTW, openjpeg triggers this line on the sample https://github.com/uclouvain/openjpeg/blob/0bda7188b7b545232a341f1d978b1e4feda46fc2/src/bin/common/color.c#L432

which also blocks -c:v libopenjpeg

Kakadu works the same as openjpeg still, lower left quadrant is indeed different.

Last edited 14 months ago by Balling (previous) (diff)

comment:7 by Balling, 11 months ago

the error message bpno became invalid is emitted

Is there any chance this file was created using ffmpeg and thus it is a bug in fixed #5360?

Last edited 11 months ago by Balling (previous) (diff)

in reply to:  7 comment:8 by Pierre-Anthony Lemieux, 11 months ago

Replying to Balling:

the error message bpno became invalid is emitted

Is there any chance this file was created using ffmpeg and thus it is a bug in fixed #5360?

Very unlikely. The file is from the ITU/ISO conformance codestream set and was likely created circa 2002.

Note: See TracTickets for help on using tickets.