[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:56 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 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.
>>
>
> I have dpx specification,

> and my patch above show correct output for that file.

I am not so sure: Look at the right border with and without my change.

> So I do not know what we are discussing about.
>
> Find actual program that correctly displays sample from above
> ticket and that we can talk again.

It displays correctly with my change, I am not sure if the file
conforms to the dpx specification.

Carl Eugen