libopenjpeg since 1.4 encode produces gray garbage files, only reproducible with compression

[bud]

summary:
ffmpeg libopenjpeg encoder produces wrong image files when compression is on. seems to be connected to the amount of threads.

originally i wanted to compress a mov to dcp compatible j2c files. this does not work with latest builds on windows/linux.

i tried these builds
linux (​http://johnvansickle.com/ffmpeg/)

ffmpeg-git-20140703-64bit-static
ffmpeg-2.2.4-64bit-static

windows (zeranoe)

ffmpeg-20140703-git-1265247-win64-static
ffmpeg-20140703-git-1265247-win32-static (crashes)

i could minimize the offending command line to

./ffmpeg -i infile -an -compression_level 30 -threads 1 %06d.j2c

output can be found on the very end of this post.[1]
using the above the encoder (libopenjpeg) produces one proper encoded image and one 1kb sized gray image alternating in a row.
raising threads eg. to 10 gives you ca. 10 proper pictures and thereafter 10 gray 1kb ones. sometimes one or two images lurk into the other group but the pattern is pretty obvious however.

the problem does not surface when -compression_level is set to 0 (disabled).

thank you.. bud

[1]OUTPUT

ffmpeg version N-44018-g1265247- ​http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2014 the FFmpeg developers

built on Jul 3 2014 02:32:06 with gcc 4.8 (Debian 4.8.3-4)
configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --disable-ffserver --enable-libass --enable-gnutls --cc=gcc-4.8
libavutil 52. 90.101 / 52. 90.101
libavcodec 55. 68.100 / 55. 68.100
libavformat 55. 44.100 / 55. 44.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 9.100 / 4. 9.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

Guessed Channel Layout for Input Stream #0.2 : 5.1
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'infile':

Metadata:

major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2014-07-03 15:12:55
timecode : 00:04:08:12

Duration: 00:00:09.00, start: 0.000000, bitrate: 178667 kb/s

Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le, 1920x1080, 174053 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 24 tbn, 24 tbc (default)
Metadata:

creation_time : 2014-07-03 15:12:55
handler_name : Apple Alias-Datensteuerung
encoder : Apple ProRes 422 (HQ)

Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:

creation_time : 2014-07-03 15:12:55
handler_name : Apple Alias-Datensteuerung
timecode : 00:04:08:12

Stream #0:2(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 6 channels, s16, 4608 kb/s (default)
Metadata:

creation_time : 2014-07-03 15:12:55
handler_name : Apple Alias-Datensteuerung

[image2 @ 0x45fa520] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.
Output #0, image2, to '%06d.j2c':

Metadata:

major_brand : qt
minor_version : 537199360
compatible_brands: qt
timecode : 00:04:08:12
encoder : Lavf55.44.100
Stream #0:0(eng): Video: jpeg2000 (libopenjpeg), yuv422p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc (default)
Metadata:

creation_time : 2014-07-03 15:12:55
handler_name : Apple Alias-Datensteuerung
encoder : Lavc55.68.100 libopenjpeg

Stream mapping:

Stream #0:0 -> #0:0 (prores (native) -> jpeg2000 (libopenjpeg))

[Carl Eugen Hoyos]

Regression since 3cfd4df8

[bud]

could you please hint me on a workaround or a possibility on how to checkout a revision before that regression?

thanks.. bud

[Carl Eugen Hoyos]

Replying to bud:

could you please hint me on a workaround

You could revert the patch locally.

or a possibility on how to checkout a revision before that regression?

$ git checkout 3cfd4df8^

[bud]

checking out the previous version would leave me without working pix_fmt xyz support, right?

bud

[Michael Niedermayer]

Ive tried -compression_level 0, ive tried to checkout 3cfd4df8^, ive tried to revert it, none of these work, the image is always gray with variing color corruption.
forcing yuv422p10le produces a solid green image with versions both before and after 3cfd4df8
Please someone provide a reproduceable testcase that shows that this is a regression. Also which version of libopenjpeg is that ?

[bud]

Michael,

do you know a revision where XYZ & libopenjpeg both used to work?

libopenjpeg versions were

• OpenJPEG 1.5.1 on windows
• libopenjpeg: 1.5.2 on linux

both were static builds from the sources mentioned above.

thanks bud

[Michael Niedermayer]

Replying to bud:

Michael,

do you know a revision where XYZ & libopenjpeg both used to work?

i do not know any revission in which libopenjpeg worked quite independantly of xyz
iam currently trying to determine if it actually worked in the past and how to reproduce this if it is a regression.

Iam not interrested in finding a workaround (aka a old revission for you). Iam interrested to fix it for everyone.

[bud]

Michael,

obviously i want it fixed too, why else would i've submitted the bug report?!

with regards to your "interest". openjpeg works properly for me when i disable compression. just tried again (with an even older ffmpeg)

..\ffmpeg-20131118-git-260fc0d-win32-static\bin\ffmpeg.exe -i "infile.mkv" -compression_level 0 c:\temp\%06d.j2c

works properly. every picture readable and complete.

enabling compression (e.g. -compression_level 100) leads to 1 fine, 1 defect, ... (on my 2 core at home)

bud

[Carl Eugen Hoyos]

I tested current FFmpeg git head - e36916a - the version that introduced the regression - 3cfd4df - and the the version before 3cfd4df - e494f44 - with the following command line:

$ ffmpeg -f lavfi -i testsrc -threads 1 -vcodec libopenjpeg -t 3 -compression_level 30 out.mov

The first and second output file look broken on playback, the oldest version (before the regression was introduced) produce an output file that plays fine. This is also reproducible with the native j2k decoder.

$ ffmpeg -f lavfi -i testsrc -threads 1 -vcodec libopenjpeg -t 3 -compression_level 30 out-e36916a.mov
ffmpeg version N-64545-ge36916a Copyright (c) 2000-2014 the FFmpeg developers
  built on Jul  9 2014 20:10:13 with gcc 4.7 (SUSE Linux)
  configuration: --enable-libopenjpeg --disable-decoder=jpeg2000
  libavutil      52. 91.100 / 52. 91.100
  libavcodec     55. 68.102 / 55. 68.102
  libavformat    55. 45.100 / 55. 45.100
  libavdevice    55. 13.102 / 55. 13.102
  libavfilter     4. 10.100 /  4. 10.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.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
[mov @ 0x2f07580] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead.
Output #0, mov, to 'out-e36916a.mov':
  Metadata:
    encoder         : Lavf55.45.100
    Stream #0:0: Video: jpeg2000 (libopenjpeg) (mjp2 / 0x32706A6D), rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc55.68.102 libopenjpeg
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> jpeg2000 (libopenjpeg))
Press [q] to stop, [?] for help
frame=   75 fps= 41 q=0.0 Lsize=     681kB time=00:00:03.00 bitrate=1860.7kbits/s
video:680kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.147256%

$ ffmpeg -f lavfi -i testsrc -threads 1 -vcodec libopenjpeg -t 3 -compression_level 30 out-e36916a.mov
bash: ./ffmpeg: No such file or directory
cehoyos@lisbeth:~/test/cehoyos/FFmpeg> git log
cehoyos@lisbeth:~/test/cehoyos/FFmpeg> ./ffmpeg -f lavfi -i testsrc -threads 1 -vcodec libopenjpeg -t 3 -compression_level 30 out-3cfd4df.mov
ffmpeg version N-56578-g3cfd4df Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul  9 2014 20:14:57 with gcc 4.7 (SUSE Linux)
  configuration: --enable-libopenjpeg --disable-decoder=jpeg2000
  libavutil      52. 46.100 / 52. 46.100
  libavcodec     55. 33.100 / 55. 33.100
  libavformat    55. 18.102 / 55. 18.102
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 87.100 /  3. 87.100
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
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 'out-3cfd4df.mov':
  Metadata:
    encoder         : Lavf55.18.102
    Stream #0:0: Video: jpeg2000 (libopenjpeg) (mjp2 / 0x32706A6D), rgb24, 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=   75 fps= 40 q=0.0 Lsize=     681kB time=00:00:03.00 bitrate=1860.7kbits/s

$ ffmpeg -f lavfi -i testsrc -threads 1 -vcodec libopenjpeg -t 3 -compression_level 30 out-e494f44.mov
ffmpeg version N-56577-ge494f44 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul  9 2014 20:15:42 with gcc 4.7 (SUSE Linux)
  configuration: --enable-libopenjpeg --disable-decoder=jpeg2000
  libavutil      52. 46.100 / 52. 46.100
  libavcodec     55. 33.100 / 55. 33.100
  libavformat    55. 18.102 / 55. 18.102
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 87.100 /  3. 87.100
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
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 'out-e494f44.mov':
  Metadata:
    encoder         : Lavf55.18.102
    Stream #0:0: Video: jpeg2000 (libopenjpeg) (mjp2 / 0x32706A6D), rgb24, 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=   75 fps= 39 q=0.0 Lsize=     282kB time=00:00:03.00 bitrate= 769.2kbits/s
video:281kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.356970%

I tested with openjpeg-1.5.0, since 1.5.1 is known to be buggy, I suggest not to use it for regression tests.

[Carl Eugen Hoyos]

Replying to cehoyos:

I tested with openjpeg-1.5.0, since 1.5.1 is known to be buggy, I suggest not to use it for regression tests.

The issue is also reproducible with openjpeg-1.5.1 (works fine with e494f44 and openjpeg-1.5.1).

[Michael Niedermayer]

ffmpeg git + libopenjpeg 1.3+dfsg-4+squeeze2build0.12.04.1
seem to work fine with the rgb24 testcase. So it seems this is a regression in ffmpeg for 1.5.0 but also a regression in libopenjpeg for ffmpeg git.

[bud]

right,

ffmpeg git + libopenjpeg 1.3+dfsg-4.8

seems to work. not perfectly though! the first num_threads pictures are freakishly small, compressed much more then the following pictures.

here the ls -1s of './ffmpeg -i in.mov -an -compression_level 100 -threads 10 folder/%06d.j2c'

  40K 000001.j2c
  40K 000002.j2c
  40K 000003.j2c
  40K 000004.j2c
  40K 000005.j2c
  40K 000006.j2c
  40K 000007.j2c
  40K 000008.j2c
  40K 000009.j2c
  40K 000010.j2c
 996K 000011.j2c
 992K 000012.j2c
 972K 000013.j2c
 968K 000014.j2c
 980K 000015.j2c
 964K 000016.j2c
 948K 000017.j2c
 944K 000018.j2c
 964K 000019.j2c
 952K 000020.j2c
 956K 000021.j2c
 968K 000022.j2c
 988K 000023.j2c
1004K 000024.j2c
1004K 000025.j2c
1008K 000026.j2c
1008K 000027.j2c
1008K 000028.j2c
1016K 000029.j2c
 1,1M 000030.j2c
 1,1M 000031.j2c
 1,1M 000032.j2c
 1,1M 000033.j2c
 1,1M 000034.j2c
 1,1M 000035.j2c
 1,1M 000036.j2c
 1,1M 000037.j2c
 1,1M 000038.j2c
 1,1M 000039.j2c
 1,1M 000040.j2c
 1,1M 000041.j2c
 1,1M 000042.j2c
....

bud

[Carl Eugen Hoyos]

It seems to me that the problem is also reproducible with newer versions of libopenjpeg.

[bud]

Michael,

can you reproduce the issue with the first num_thread frames as outlined above on your system with git & openjpeg 1.3?

bud

[Carl Eugen Hoyos]

Also reproducible with openjpeg 1.4 and openjpeg 2.1

[cbsrobot]

Patch posted to ffmpeg-devel, please comment: ​http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167840.html

[cbsrobot]

should be fixed in 1f13348f7d1049fe9be2897d8cd88024db233bda