[FFmpeg-devel] [PATCH]Mark experimental j2k decoder as experimental if libopenjpeg is available
dave at dericed.com
Thu Jun 19 16:02:05 CEST 2014
On Jun 18, 2014, at 7:32 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Jun 18, 2014 at 07:02:59PM -0400, Dave Rice wrote:
>> Hi all,
>> On May 7, 2014, at 6:41 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>>> Nicolas George <george <at> nsup.org> writes:
>>>>> I thought this would anger both users and downstream
>>>>> (who paid for the removal of EXPERIMENTAL iirc) and I
>>>>> intended to keep the profile low for this controversy.
>>>> Well, this ticket obviously shows that the removal of
>>>> EXPERIMENTAL was premature.
>>> Sorry, I assumed this was well known for all developers.
>>> (See also the large number of tickets opened
>>> immediately after the removal.)
> the patch breaks fate
> also did you try to contact Nicolas Bertrand about these issues ?
> He is listed in MAINTAINERs for jpeg2000
Michael had suggested I contact you regarding this thread. Also I posted a related ticket at http://trac.ffmpeg.org/ticket/3619 and Carl had submitted a patch here https://ffmpeg.org/pipermail/ffmpeg-devel/2014-May/157367.html to flag jpeg2000 as experimental is libopenjpeg is present.
In summary, the native jpeg2000 codec decodes jpeg2000 improperly at many pixel formats. In the digital preservation community many archives are using jpeg2000 at yuv422p10le which the native jpeg2000 decoder decodes as a colorful mess. The workaround has seemed to be to either configure with -disable-decoder=jpeg2000 or to ensure that -vcodec libopenjpeg is always called when handling jpeg2000 as an input or output.
I have been proposing to either:
- have ffmpeg prioritize the use of libopenjpeg when it's available (so user does not need to froce it)
- mark the jpeg2000 decoder as experimental as it seems to be at least with many pixel formats I've tried
More information about the ffmpeg-devel