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