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

[Carl Eugen Hoyos]

2018-12-06 10: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 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

What is wrong about them?

> B files looks like using no-packing mode.

The only difference between "B" and "L" files is the endianness.
Two files are lsb-padded, two are msb-padded ("a" and "b").

Carl Eugen