[FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2

[Carl Eugen Hoyos]

2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>>>> Fixes #4409.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>>>>>>>>> ---
>>>>>>>>>  libavcodec/dpx.c | 3 ++-
>>>>>>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
>>>>>>>>> index 538a1b9943..04b55ffadf 100644
>>>>>>>>> --- a/libavcodec/dpx.c
>>>>>>>>> +++ b/libavcodec/dpx.c
>>>>>>>>> @@ -378,7 +378,8 @@ static int decode_frame(AVCodecContext *avctx,
>>>>>>>>>                      read10in32(&buf, &rgbBuffer,
>>>>>>>>>                                 &n_datum, endian, shift);
>>>>>>>>>              }
>>>>>>>>> -            n_datum = 0;
>>>>>>>>> +            if (packing != 2)
>>>>>>>>> +                n_datum = 0;
>>>>>>>>>              for (i = 0; i < elements; i++)
>>>>>>>>>                  ptr[i] += p->linesize[i];
>>>>>>>>>          }
>>>>>>>>
>>>>>>>> This breaks decoding the output of the following command:
>>>>>>>> $ gm convert converted_image_gets_skewed.dpx -define
>>>>>>>> dpx:packing-method=b out.dpx
>>>>>>>
>>>>>>> I do not trust that app, its full of bugs.
>>>>>>
>>>>>> What is the reference for dpx in your opinion?
>>>>>
>>>>> ImageTragick certainly not.
>>>>
>>>> That's not ImageMagick above.
>>>
>>> Then what is it?
>>
>> GraphicsMagick which claims to be the dpx reference (afaiu).
>>
>>>> The sample in question looks better with attached poc, breaks
>>>> four component sample, also attaching other samples that
>>>> show the difference.
>>>
>>> Attacking crappy patches and non-compliant files that
>>
>> Do you know of a 10bit gray dpx sample that does not look
>> better with my "crappy" patch?
>>
>>> conflict and do not follow specification is not productive.
>>
>> GraphicsMagick claims differently.
>
> How sample from ticket #4409 looks with that tool?

It fails differently than with your patch.

Carl Eugen