exr: support dwa decompression

[ami_stuff]

C:\>ffmpegx -i C:\ff\rgba_dwaa.exr
ffmpeg version N-80803-g8a3221c Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.5.0 (GCC) 20100414 (Fedora MinGW 4.5.0-1.fc14)
  configuration: --prefix=/var/www/users/research/ffmpeg/snapshots/build --arch=
x86 --target-os=mingw32 --cross-prefix=i686-pc-mingw32- --cc='ccache i686-pc-min
gw32-gcc' --enable-pthreads --enable-memalign-hack --enable-runtime-cpudetect --
enable-cross-compile --enable-static --disable-shared --extra-libs='-lws2_32 -lw
inmm -lpthread' --extra-cflags='--static -I/var/www/users/research/ffmpeg/snapsh
ots/build/include' --extra-ldflags='-static -L/var/www/users/research/ffmpeg/sna
pshots/build/lib' --enable-bzlib --enable-zlib --enable-gpl --enable-version3 --
enable-nonfree --enable-libx264 --enable-libspeex --enable-libtheora --enable-li
bvorbis --enable-libfaac --enable-libxvid --enable-libopencore-amrnb --enable-li
bopencore-amrwb --enable-libmp3lame --enable-libfreetype --enable-libvpx --disab
le-decoder=libvpx
  libavutil      55. 27.100 / 55. 27.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 40.101 / 57. 40.101
  libavdevice    57.  0.102 / 57.  0.102
  libavfilter     6. 46.102 /  6. 46.102
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
[exr @ 0x28dd8a0] Missing compression attribute.
[exr_pipe @ 0x28d3d20] decoding for stream 0 failed
[exr_pipe @ 0x28d3d20] Could not find codec parameters for stream 0 (Video: exr,
 none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, exr_pipe, from 'C:\ff\rgba_dwaa.exr':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: exr, none, 25 tbr, 25 tbn, 25 tbc
At least one output file must be specified

[Joshua Minor]

Pixar is interested in this as well.

Looking at the code in exr.c it appears that ffmpeg does not use libopenexr, but rather has a reimplementation of an EXR decoder. Is this negotiable, or is that by design?

In either case, we would like to understand how much work it would be to add support for the dwaa compression scheme to ffmpeg's exr reader. Is this a simple change, or a substantial amount of work? We could possibly help out with this, although we don't have anyone familiar with the ffmpeg code base at the moment.

[Elon Musk]

Contact ffmpeg developers for sponsoring this code addition. See contact page.

[levivant]

Replying to jminor:

Pixar is interested in this as well.

Hi jminor, any news? Did you manage to implement it? I'm facing the same issue and before considering finding the right enginering to implement it without the official exr library I'm curious if you did something?

[levivant]

I was looking around, and found out that Tiny Exr is not supporting DWAA because there might be a patent issue. Dreamworks patented this method and included it to the OpenExr library. The patent file is pretty clear: ​https://github.com/ImageMagick/exr/blob/master/openexr/PATENTS

This grant does not include use of DreamWorks Lossy Compression outside of the OpenEXR standard.

How can we read that? As ffmpeg is not using the openExr Library (too bad, why? because it's C++?) we might be outside of the grant if we implement this method here? Linking the library might be the solution, but you might have good reasons not to?
Still, they are saying that the grant cant be used outside of the standard, not outside of the library. Is rewriting the exr dwaa decoder in ffmpeg still.. the "standard"?

[Carl Eugen Hoyos]

Fixed by Paul in cc85ca1cb347570a95d8615b7d4c7b542042b7f0