Jpeg2000 decoder broken

[Nick]

Summary of the bug: Regression in the JPEG2000 decoder. I see the problem using either libopenjpeg or jpeg2000 as the decoder. It seems that FFmpeg erroneously recognizes the video as rgb48le when it is really yuv422p10le. I have a version of FFmpeg from 3/28/2013 that does not exhibit the problem.

How to reproduce: Try to decode JPEG2000 video with the following command:
ffmpeg -i "J2K Decoding Regression.mkv" -f rawvideo NUL -y

ffmpeg -i "J2K Decoding Regression.mkv" -f rawvideo NUL -y
ffmpeg version N-54082-g96b33dd Copyright (c) 2000-2013 the FFmpeg developers
  built on Jun 17 2013 02:05:16 with gcc 4.7.3 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
eex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-
amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --
enable-libxvid --enable-zlib
  libavutil      52. 37.101 / 52. 37.101
  libavcodec     55. 16.100 / 55. 16.100
  libavformat    55.  8.103 / 55.  8.103
  libavdevice    55.  2.100 / 55.  2.100
  libavfilter     3. 77.101 /  3. 77.101
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
[jpeg2000 @ 0287b6a0] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 0287b6a0] unsupported/ CDxy values 2 1 for component 2
Input #0, matroska,webm, from 'J2K Decoding Regression.mkv':
  Metadata:
    ENCODER         : Lavf55.8.103
  Duration: 00:00:00.17, start: 0.000000, bitrate: 156157 kb/s
    Stream #0:0: Video: jpeg2000 (JPEG 2000 codestream restriction 0) (mjp2 / 0x
32706A6D), rgb48le, 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1
k tbc (default)
Output #0, rawvideo, to 'NUL':
  Metadata:
    encoder         : Lavf55.8.103
    Stream #0:0: Video: rawvideo (RGB0 / 0x30424752), rgb48le, 1920x1080 [SAR 1:
1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 29.97 tbc (default)
Stream mapping:
  Stream #0:0 -> #0:0 (jpeg2000 -> rawvideo)
Press [q] to stop, [?] for help
[jpeg2000 @ 063d0060] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 063d0060] unsupported/ CDxy values 2 1 for component 2
[jpeg2000 @ 04005fe0] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 040063c0] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 04005fe0] [jpeg2000 @ 040067a0] [jpeg2000 @ 04006ba0] [jpeg2000 @ 04
0063c0] unsupported/ CDxy values 2 1 for component 1
unsupported/ CDxy values 2 1 for component 2
unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 04006ba0] unsupported/ CDxy values 2 1 for component 2
unsupported/ CDxy values 2 1 for component 2
[jpeg2000 @ 040067a0] unsupported/ CDxy values 2 1 for component 2
frame=    1 fps=0.0 q=0.0 size=   12150kB time=00:00:00.03 bitrate=2982971.2kbit
frame=    5 fps=0.0 q=0.0 Lsize=   60750kB time=00:00:00.16 bitrate=2983007.0kbi
ts/s
video:60750kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.000000%

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

[Nick]

Short (3 frame) JPEG2000 encode that decodes fine on old FFmpeg

[Carl Eugen Hoyos]

Workarounds are to configure with --disable-decoder=jpeg2000 or to specify libopenjpeg as decoder with -vcodec libopenjpeg (in this case, the scaler will always be inserted).

[Nick]

Replying to cehoyos:

Workarounds are to configure with --disable-decoder=jpeg2000 or to specify libopenjpeg as decoder with -vcodec libopenjpeg (in this case, the scaler will always be inserted).

Trying the -c:v libopenjpeg workaround, it does work, but the input still shows as rgb48le and the output is rgb48le.

I don't understand...I thought the content was stored as yuv422p10le (this is what FFmpeg reported when I encoded it). If FFmpeg was incorrectly identifying the encoded file as rgb48le, how is it that I get a valid rgb48le output file?

I'm wondering...in the older "working" FFmpeg from March, does libopenjpeg internally convert YUV to RGB48 for encoding, and conversly decode to RGB48 and internally convert it backto YUV? If so, it is probably more correct for FFmpeg to only allow RGB input/output to libopenjpeg...letting libopenjpeg internally do the conversions isn't optimal and is misleading.

[Carl Eugen Hoyos]

Replying to Aegwyn11:

Replying to cehoyos:

Workarounds are to configure with --disable-decoder=jpeg2000 or to specify libopenjpeg as decoder with -vcodec libopenjpeg (in this case, the scaler will always be inserted).

Trying the -c:v libopenjpeg workaround, it does work, but the input still shows as rgb48le and the output is rgb48le.

As explained, if you use -vcodec libopenjpeg the video scaler is inserted to convert from yuv422p10 to rgb48. See the console output for the correct colourspace (and the console output with -loglevel verbose to see the scaler inserted).

[Nicolas Bertrand]

The sample looks like a 3D video in motion jpeg2000 is that correct? or maybe interlaced video?

And native jpeg2000 decoder shall be corrected as it does not decode correctly the images and returns :

./ffplay -vcodec jpeg2000 "/home/nicolas/Téléchargements/J2K Decoding Regression.mkv"
ffplay version N-53811-gc8faa47 Copyright (c) 2003-2013 the FFmpeg developers
  built on Jun 17 2013 18:16:53 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --prefix=/home/nicolas/dev/local --enable-pic --enable-libopenjpeg
  libavutil      52. 34.100 / 52. 34.100
  libavcodec     55. 15.100 / 55. 15.100
  libavformat    55.  8.102 / 55.  8.102
  libavdevice    55.  2.100 / 55.  2.100
  libavfilter     3. 74.101 /  3. 74.101
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
[jpeg2000 @ 0x7f6630003020] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 0x7f6630003020] unsupported/ CDxy values 2 1 for component 2
Input #0, matroska,webm, from '/home/nicolas/Téléchargements/J2K Decoding Regression.mkv':
  Metadata:
    ENCODER         : Lavf55.8.103
  Duration: 00:00:00.10, start: 0.000000, bitrate: 155549 kb/s
    Stream #0:0: Video: jpeg2000 (JPEG 2000 codestream restriction 0) (mjp2 / 0x32706A6D), rgb48le, 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
[jpeg2000 @ 0x7f6630009c20] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 0x7f6630009c20] unsupported/ CDxy values 2 1 for component 2
[jpeg2000 @ 0x7f663000a0a0] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 0x7f663000a0a0] unsupported/ CDxy values 2 1 for component 2
[jpeg2000 @ 0x7f663000b000] unsupported/ CDxy values 2 1 for component 1
[jpeg2000 @ 0x7f663000b000] unsupported/ CDxy values 2 1 for component 2
  10.56 M-V:  0.074 fd=   1 aq=    0KB vq=    0KB sq=    0B f=0/0   

The issue can maybe also related to motion jpeg2000 container.

[Carl Eugen Hoyos]

Replying to Buxiness:

The sample looks like a 3D video in motion jpeg2000 is that correct?

This seems unlikely to me.

or maybe interlaced video?

The frames are definitely interlaced, yes.

And native jpeg2000 decoder shall be corrected as it does not decode correctly the images

Yes, this is what this ticket is about ("Jpeg2000 decoder broken", from a user's perspective this is a regression).

[Nick]

Replying to cehoyos:

As explained, if you use -vcodec libopenjpeg the video scaler is inserted to convert from yuv422p10 to rgb48. See the console output for the correct colourspace (and the console output with -loglevel verbose to see the scaler inserted).

I think I see. If I'm looking at this right, ffmpeg initially thinks the input is rgb48le, sets up the output to match, then upon initiating decode, libopenjpeg realizes the input is really yuv422p10le, but then ffmpeg inserts the scaler to get back to rgb48le.

If I specify that I want -pix_fmt yuv422p10le on the output, it appears that the scaler is still invoked, but just converts from yuv422p10le to yuv422p10le, not really doing anything. So is a better workaround to both specify -c:v libopenjpeg on the input side and to specify the correct -pix_fmt on the output side?

[Carl Eugen Hoyos]

Replying to Aegwyn11:

If I specify that I want -pix_fmt yuv422p10le on the output, it appears that the scaler is still invoked, but just converts from yuv422p10le to yuv422p10le,

not really doing anything.

Did you test this? I am not 100% sure.

So is a better workaround to both specify -c:v libopenjpeg on the input side and to specify the correct -pix_fmt on the output side?

Imo, simply use --disable-decoder=jpeg2000

[Nick]

Replying to cehoyos:

Replying to Aegwyn11:

If I specify that I want -pix_fmt yuv422p10le on the output, it appears that the scaler is still invoked, but just converts from yuv422p10le to yuv422p10le,

not really doing anything.

Did you test this? I am not 100% sure.

It looks to me like its bit exact, so this seems to be a viable workaround.

So is a better workaround to both specify -c:v libopenjpeg on the input side and to specify the correct -pix_fmt on the output side?

Imo, simply use --disable-decoder=jpeg2000

I'm not very good with compiling (almost never do it), so it would take a bunch of time for me just to remember how to go about it. Not worth the effort...the above workaround seems to work fine until its properly fixed.

[Carl Eugen Hoyos]

Patch sent that improves the detection:
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/165686

[Carl Eugen Hoyos]

The colour-space detection was fixed in b39a6bb, subsampling is not yet supported in the native decoder.