If configured with libopenjpeg then use it as default jpeg2000 decoder

[dave rice]

Summary of the bug:
The jpeg2000 decoder in ffmpeg is experimental and decodes many pixel formats improperly, but is the default jpeg2000 decoder. I propose that if ffmpeg is configured with libopenjpeg support than libopenjpeg is used as the default decoder.

How to reproduce:

Make a jpeg2000 test file

ffmpeg -f lavfi -i testsrc -t 1 -c:v libopenjpeg -pix_fmt yuv422p10le -y testj2k.mov
ffmpeg version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers
  built on May  6 2014 22:39:50 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-ffplay --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      52. 66.100 / 52. 66.100
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 33.100 / 55. 33.100
  libavdevice    55. 10.100 / 55. 10.100
  libavfilter     4.  2.100 /  4.  2.100
  libavresample   1.  2.  0 /  1.  2.  0
  libswscale      2.  5.102 /  2.  5.102
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, mov, to 'testj2k.mov':
  Metadata:
    encoder         : Lavf55.33.100
    Stream #0:0: Video: jpeg2000 (libopenjpeg) (mjp2 / 0x32706A6D), yuv422p10le, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> libopenjpeg)
Press [q] to stop, [?] for help
frame=   25 fps=0.0 q=0.0 Lsize=     430kB time=00:00:01.00 bitrate=3524.7kbits/s    
video:429kB audio:0kB subtitle:0 data:0 global headers:0kB muxing overhead 0.187830%

Then play it back using the defaults. The image will be distorted.

ffplay testj2k.mov 
ffplay version 2.2.1 Copyright (c) 2003-2014 the FFmpeg developers
  built on May  6 2014 22:39:50 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-ffplay --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      52. 66.100 / 52. 66.100
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 33.100 / 55. 33.100
  libavdevice    55. 10.100 / 55. 10.100
  libavfilter     4.  2.100 /  4.  2.100
  libavresample   1.  2.  0 /  1.  2.  0
  libswscale      2.  5.102 /  2.  5.102
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'testj2k.mov':   0B f=0/0   
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf55.33.100
  Duration: 00:00:01.00, start: 0.000000, bitrate: 3524 kb/s
    Stream #0:0(eng): Video: jpeg2000 (JPEG 2000 codestream restriction 0) (mjp2 / 0x32706A6D), yuv422p10le, 320x240, 3518 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)
    Metadata:
      handler_name    : DataHandler
   0.99 M-V: -0.039 fd=   2 aq=    0KB vq=    0KB sq=    0B f=0/0

To decode the file properly the user could force use of the libopenjpeg. I propose that if libopenjpeg is configured then it be the decoding default.

ffplay -vcodec libopenjpeg testj2k.mov 
ffplay version 2.2.1 Copyright (c) 2003-2014 the FFmpeg developers
  built on May  6 2014 22:39:50 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-ffplay --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      52. 66.100 / 52. 66.100
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 33.100 / 55. 33.100
  libavdevice    55. 10.100 / 55. 10.100
  libavfilter     4.  2.100 /  4.  2.100
  libavresample   1.  2.  0 /  1.  2.  0
  libswscale      2.  5.102 /  2.  5.102
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'testj2k.mov':   0B f=0/0   
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf55.33.100
  Duration: 00:00:01.00, start: 0.000000, bitrate: 3524 kb/s
    Stream #0:0(eng): Video: jpeg2000 (JPEG 2000 codestream restriction 0) (mjp2 / 0x32706A6D), yuv422p10le, 320x240, 3518 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)
    Metadata:
      handler_name    : DataHandler
   0.48 M-V: -0.040 fd=   2 aq=    0KB vq=   86KB sq=    0B f=0/0

Note, although my examples use ffplay to show the difference between jpeg2000 playback between the two decoders, the issue affects ffmpeg as well.

[Carl Eugen Hoyos]

How is this 2.2.1-related?

Note, although my examples use ffplay to show the difference between jpeg2000 playback between the two decoders, the issue affects ffmpeg as well.

Then why do you provide console output for ffplay? Contrary to ffmpeg, it depends on an external library that is known to contain bugs. See also ​http://ffmpeg.org/bugreports.html

I will send a patch in a moment.

[Carl Eugen Hoyos]

It appears that this ticket (that is imo an important regression, not an enhancement) will remain open:
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/177508

[Cigaes]

You say it is a regression: do you know a version of the FFmpeg j2k decoder that produces valid output?

[Carl Eugen Hoyos]

Replying to Cigaes:

You say it is a regression: do you know a version of the FFmpeg j2k decoder that produces valid output?

Afaict, this ticket is not related to the shortcomings of our decoder:
Before e2e9bee2 (or a slightly later commit), if you ran configure with --enable-libopenjpeg, libopenjpeg was used as default decoder for jpeg2000. After that commit, the experimental internal jpeg2000 decoder was used no matter if you specified --enable-libopenjpeg or not.

[Michael Niedermayer]

This ticket should contain links to the tickets describing issues in the native decoder or a link to the search / view ticket page with appropriate parameters.
So that anyone interrested in working on the native decoder knows what needs work

[Carl Eugen Hoyos]

​https://trac.ffmpeg.org/query?status=!closed&keywords=~j2k

[dave rice]

Yes the ticket is mostly about how ffmpeg selects which jpeg2000 decoder to use, rather than the j2k decoder itself. IMO when ffmpeg is configured with libopenjpeg it would be a better default to use libopenjpeg for decoding (and encoding too). Within the archiving community jpeg2000 is (for better or worse) a popular codec for preservation but using those files in ffmpeg require the user to specify that they want the decoder that works whereas the broken decoder is the default. Defaulting to the j2k decoder which only works on a few pixel formats makes it very easy for a user to cause mistakes. I've been recommending archivists use --disable-decoder=jpeg2000 and --enable-libopenjpeg to make ffmpeg and jpeg2000 more foolproof, but would like to see ffmpeg's defaults change when openjpeg is available.

[Carl Eugen Hoyos]

Replying to dericed:

IMO when ffmpeg is configured with libopenjpeg it would be a better default to use libopenjpeg for decoding

(and encoding too).

Please elaborate!

Defaulting to the j2k decoder which only works on a few pixel formats makes it very easy for a user to cause mistakes.

From an archivists pov, I don't think there is a sample for which the internal decoder "works" at all.

[CJ]

The default jpeg2000 decoder cannot handle 10-bit content correctly at all. Yet 10- and 12-bit are the norms in the J2K usage for the most part and 16-bit is becoming useful. Therefore, I'd like to not fuss with "-codec:v libopenjpeg" every time I want to run a J2K file on my builds. I will also check out dericed's "disable-decoder" switch on my next compile to see if it solves my scripting problem.

[Michael Niedermayer]

028c59c17b14751e049a05abbdac52f885ad96a2 and 074159ed70acd379d94378b72a9202283e651ba0 make the native decoder decode the example correctly

[Michael Niedermayer]

carl still prefers libopenjpeg so reopening

[Carl Eugen Hoyos]

This seems not useful anymore.