2018-12-06 10:33 GMT+01:00, Paul B Mahol <one...@gmail.com>: > On 12/5/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> 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. > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel