[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 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.

Carl Eugen