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

[Paul B Mahol]

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?

>
> 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 conflict and do
not follow specification is not productive.