2018-12-05 22:56 GMT+01:00, Paul B Mahol <one...@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> 2018-12-05 22:42 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>> On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>> On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>> On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>>>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>>>> Fixes #4409. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Paul B Mahol <one...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
