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

Paul B Mahol onemda at gmail.com
Wed Dec 5 23:56:38 EET 2018


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


More information about the ffmpeg-devel mailing list