> So what problem do you see? > Yes, we prefer using the native codecs over external dependencies.
ffmpeg -v debug -vcodec libopenjpeg -i ~/Projects/ClairMeta/tests/resources/DCP/ECL-SET/ECL07-SINGLE-CPL_TST-3D-48_S_EN-XX_UK-U_71-ATMOS_2K_ECL_20180301_ECL_SMPTE-3D_OV/ECL07SingleCPL_TST-3D-48_S_EN-XX_UK-U_71-ATMOS_2K_ECL_20180301_ECL_SMPTE-3D_OV_01.mxf ... Stream #0:0, 1, 1/48: Video: jpeg2000, 1 reference frame, rgb48le(12 bpc, progressive), 2048x858, 0/1, SAR 1:1 DAR 1024:429, 48 tbr, 48 tbn, 48 tbc ... rgb48le is not correct as this file is xyz12 We can use the native decoder yes, not sure what the state is right now though, because I heard that some work was ongoing on that decoder, but back then (approx. 1 year ago) it was not really an option due to its poor performance, even for offline jobs. > You can force the pix_fmt, Carl Eugen How can I do that ? I'll continue to work on trying to fix mxfdec.c anyway, thanks. Le mar. 1 sept. 2020 à 18:18, Carl Eugen Hoyos <ceffm...@gmail.com> a écrit : > Am Di., 1. Sept. 2020 um 12:14 Uhr schrieb Rémi Achard < > remiach...@gmail.com>: > > > > > Do you have a sample that does not work with the native decoder? > > > > According to my tests, the native decoder detect pixel format just fine > > So what problem do you see? > Yes, we prefer using the native codecs over external dependencies. > > You can force the pix_fmt, Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
