0

I'm converting a sequence of exr images to a mov. The exrs have been published out of a 3d application(houdini).This has been working fine till a new version of a 3rd party render was installed (redshift 2.5.50). They state that their exr images are using openexr2.0. Does FFmpeg (3.4.1 win64) support exr2.0?

FFmpeg can't seem to read them and returns:

"flags 4 is not implemented"

"decoding for stream 0 failed"

"Could not find codec parameters for stream 0 (Video: exr, none): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options"

my cmd command working before the render update:

"D:\ffmpeg\ffmpeg.exe" -start_number 1 -i "D:\RedShiftFFmpeg\render\redshift\FFmpeg_redshift_%4d.exr" -y "D:\RedShiftFFmpeg\render\FFmpeg_mantra1.mov"
stormy
  • 13
  • 5

1 Answers1

0

We had the same error and tracked it down to the length of layer names in the packed exr causing the problem. If any of the layer names in the exr are longer then 28 characters, we get the same ffmpeg error on movie encode.

If you view the exr header look for an attribute named "file format version" to check the flags. The Version Field, of type int, is the four-byte group following the magic number, and it is treated as two separate bit fields. The first byte is The current OpenEXR version number, which in your case should be "2". The second, third and fourth bytes are treated as a set of boolean flags.

For example, a value of "2x000" in the file format version header attribute encodes through ffmpeg libx264 with no errors, but a value of "2x400" shows the same error code as stated above. Checking the OpenEXR documentation for Version Field we confirmed that this value corresponded to a flag indicating that the exr contains “long names” because the the maximum length of attribute names, attribute type names and channel names is 31 bytes"

bigpoppa_00
  • 1
  • 1