[FFmpeg-user] xyz12le Jpeg2000 MXF files in DCP now detected as rgb48le

[Carl Eugen Hoyos]

2018-11-20 14:12 GMT+01:00, Kieran O'Leary <kieran.oleary at irishfilm.ie>:

> I remember that older versions of ffmpeg would detect a pix_fmt of
> xyz12le when a jpeg2000/MXF file from a DCP was passed as input.
> Now I see a value of: rgb48le(12 bpc, progressive)
>
> Was this intentional, and if so, why did the behaviour change?

Of course, it is our utmost desire to add as many regressions as
possible from one version to the next (we nowadays succeed more
than before).

> I tried looking at the commit history for jpeg2000dec.c but
> couldn't find the answer..

(This file is unrelated to your issue, mentioning it made it much
more difficult for me to see the issue you have.)

> You can find some sample DCPs here:

> https://www.charbon-studio.com/resources

This doesn't look like a link to the file you tested.
(Yes, works fine here.)

> $ ffmpeg -i video1.mxf
>
> ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers

Looks old and unsupported.

[after looking at the issue again, it may have been easier for you
to look at old and new console output:]

> --enable-libopenjpeg --disable-decoder=jpeg2000

I don't remember if this ever allowed xyz support, I thought
not, looking at the source code it may have worked, or you
may be able to force it, it is also possible that this is a
libopenjpeg regression, or that we misunderstood / abused
the api, I don't know / don't remember.
(Or you had to enable both decoders to get the correct
format with libopenjpeg, who knows...)

In any case, libopenjpeg is needed for some files, crashes
for others, is unneeded for the file from above link that I
tested and since DCP was the original reason for extending
our native decoder I wonder if libopenjpeg only makes
sense for non-DCP jpeg2000 files.

Carl Eugen