[FFmpeg-devel] [PATCH] exr: add CODEC_CAP_DR1

[Reimar Döffinger]

On 8 Jul 2012, at 04:15, Paul B Mahol <onemda at gmail.com> wrote:
> On 7/8/12, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Sat, Jul 07, 2012 at 09:00:36PM +0000, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>>> ---
>>> libavcodec/exr.c |    1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
>>> index a95423f..5ff2c6f 100644
>>> --- a/libavcodec/exr.c
>>> +++ b/libavcodec/exr.c
>>> @@ -491,5 +491,6 @@ AVCodec ff_exr_decoder = {
>>>     .init               = decode_init,
>>>     .close              = decode_end,
>>>     .decode             = decode_frame,
>>> +    .capabilities       = CODEC_CAP_DR1,
>>>     .long_name          = NULL_IF_CONFIG_SMALL("OpenEXR image"),
>>> };
>> 
>> probably ok
>> but i would suggest to test all the dr1 additions with mplayer as
>> mplayer historically had the tendency to be more DR1 bug sensitive
> 
> Mplayer have own list of codecs where dr1 is not enabled
> because mplayer implementation of dr1 have many limitations
> (worst one being: dr1 is disabled with multithreading).

I think it doesn't actually break, it just disables it again because it can't handle it in a way that has any advantage.
Well, and then there is the resolution change issue, but that is broken as hell on FFmpeg side anyway (even without multithreading FFmpeg just discards delayed frames when a resolution change happens).

> So enabling DR1 for yop or dirac (which is perfectly fine) will break
> decoding with mplayer and I did not sent patches for them even
> i could because there is nothing wrong on our side.

Really sure there is no issue on FFmpeg side? These kinds of bugs usually are not at all obvious.
Even though I didn't re-enable it again, DR1 is working fine with H.264 in MPlayer (even if it is used for only one on 5 frames or so).