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

The files you posted does not conform, B files looks like using no-packing mode.