2018-11-20 14:12 GMT+01:00, Kieran O'Leary <[email protected]>:
> 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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
