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, B files looks like using no-packing mode. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel