[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: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?