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

Submitted by Carl Eugen Hoyos on Dec. 5, 2018, 5:40 p.m.

Details

Message ID CAB0OVGrU5qF+V3TfjuB-2XSAXRKNjWU3bRi+3zsGq=ZDVjKcRA@mail.gmail.com
State Superseded
Headers show

Commit Message

Carl Eugen Hoyos Dec. 5, 2018, 5:40 p.m.
2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> Fixes #4409.
>>>>>
>>>>> Signed-off-by: Paul B Mahol <onemda@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.

The sample in question looks better with attached poc, breaks
four component sample, also attaching other samples that
show the difference.

Carl Eugen

Comments

Paul B Mahol Dec. 5, 2018, 5:58 p.m.
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> Fixes #4409.
>>>>>>
>>>>>> Signed-off-by: Paul B Mahol <onemda@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?

>
> 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 conflict and do
not follow specification is not productive.
Carl Eugen Hoyos Dec. 5, 2018, 9:38 p.m.
2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> Fixes #4409.
>>>>>>>
>>>>>>> Signed-off-by: Paul B Mahol <onemda@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.

Carl Eugen
Paul B Mahol Dec. 5, 2018, 9:42 p.m.
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> Fixes #4409.
>>>>>>>>
>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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?
Carl Eugen Hoyos Dec. 5, 2018, 9:49 p.m.
2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> Fixes #4409.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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.

Carl Eugen
Paul B Mahol Dec. 5, 2018, 9:56 p.m.
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> Fixes #4409.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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.
Carl Eugen Hoyos Dec. 5, 2018, 10:25 p.m.
2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> Fixes #4409.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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
Paul B Mahol Dec. 6, 2018, 9:33 a.m.
On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>> Fixes #4409.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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.
Carl Eugen Hoyos Dec. 6, 2018, 6:34 p.m.
2018-12-06 10:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2018-12-05 22:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>> Fixes #4409.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Paul B Mahol <onemda@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

Patch hide | download patch | download mbox

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 538a1b9..b9e02e5 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -50,6 +50,8 @@  static unsigned int read32(const uint8_t **ptr, int is_big)
     return temp;
 }
 
+static int counter = 0;
+
 static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
                                   int * n_datum, int is_big, int shift)
 {
@@ -60,9 +62,11 @@  static uint16_t read10in32(const uint8_t **ptr, uint32_t * lbuf,
         *n_datum = 2;
     }
 
-    *lbuf = *lbuf << 10 | *lbuf >> shift & 0x3FFFFF;
-
-    return *lbuf & 0x3FF;
+    if (*n_datum < 2)
+        *lbuf = *lbuf >> 10;
+if (counter++<30)
+printf("%x \n", *lbuf >> shift & 0x3FF);
+    return *lbuf >> shift & 0x3FF;
 }
 
 static uint16_t read12in32(const uint8_t **ptr, uint32_t * lbuf,
@@ -168,6 +172,7 @@  static int decode_frame(AVCodecContext *avctx,
     bits_per_color = buf[0];
     buf++;
     packing = read16(&buf, endian);
+printf("packing: %d, endian: %d, descriptor: %d, bpc: %d \n", packing, endian, descriptor, bits_per_color);
     encoding = read16(&buf, endian);
 
     if (encoding) {
@@ -310,6 +315,7 @@  static int decode_frame(AVCodecContext *avctx,
     case 51121:
         avctx->pix_fmt = AV_PIX_FMT_GBRAP12;
         break;
+    case 6100:
     case 6101:
         avctx->pix_fmt = AV_PIX_FMT_GRAY10;
         break;
@@ -363,20 +369,20 @@  static int decode_frame(AVCodecContext *avctx,
                                 (uint16_t*)ptr[1],
                                 (uint16_t*)ptr[2],
                                 (uint16_t*)ptr[3]};
-            int shift = packing == 1 ? 22 : 20;
+            int shift = packing == 1 ? 2 : 0;
             for (y = 0; y < avctx->width; y++) {
-                if (elements >= 3)
-                    *dst[2]++ = read10in32(&buf, &rgbBuffer,
-                                           &n_datum, endian, shift);
-                *dst[0]++ = read10in32(&buf, &rgbBuffer,
-                                       &n_datum, endian, shift);
-                if (elements >= 2)
-                    *dst[1]++ = read10in32(&buf, &rgbBuffer,
-                                           &n_datum, endian, shift);
                 if (elements == 4)
                     *dst[3]++ =
                     read10in32(&buf, &rgbBuffer,
                                &n_datum, endian, shift);
+                if (elements >= 2)
+                    *dst[1]++ = read10in32(&buf, &rgbBuffer,
+                                           &n_datum, endian, shift);
+                *dst[/*elements == 4 ? 2 :*/ 0]++ = read10in32(&buf, &rgbBuffer,
+                                       &n_datum, endian, shift);
+                if (elements >= 3)
+                    *dst[/*elements == 4 ? 0 :*/ 2]++ = read10in32(&buf, &rgbBuffer,
+                                           &n_datum, endian, shift);
             }
             n_datum = 0;
             for (i = 0; i < elements; i++)