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. 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
