Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-06 10:33 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos wrote:
>> 2018-12-05 22:56 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos wrote:
2018-12-05 22:42 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos wrote:
>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos wrote:
2018-12-05 18:19 GMT+01:00, Paul B Mahol :
> On 12/5/18, Carl Eugen Hoyos wrote:
>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol :
>>> On 12/5/18, Carl Eugen Hoyos wrote:
2018-12-05 14:27 GMT+01:00, Paul B Mahol :
> Fixes #4409.
>
> Signed-off-by: Paul B Mahol
> ---
> 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
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 22:56 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 22:42 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 18:58 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 17:33 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : Fixes #4409. Signed-off-by: Paul B Mahol --- 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
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-05 22:56 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 22:42 GMT+01:00, Paul B Mahol : >>> On 12/5/18, Carl Eugen Hoyos wrote: 2018-12-05 18:58 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 18:19 GMT+01:00, Paul B Mahol : >>> On 12/5/18, Carl Eugen Hoyos wrote: 2018-12-05 17:33 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >>> Fixes #4409. >>> >>> Signed-off-by: Paul B Mahol >>> --- >>> 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
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 22:42 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 18:58 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 18:19 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >> Fixes #4409. >> >> Signed-off-by: Paul B Mahol >> --- >> 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
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-05 22:42 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 18:58 GMT+01:00, Paul B Mahol : >>> On 12/5/18, Carl Eugen Hoyos wrote: 2018-12-05 18:19 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 17:33 GMT+01:00, Paul B Mahol : >>> On 12/5/18, Carl Eugen Hoyos wrote: 2018-12-05 14:27 GMT+01:00, Paul B Mahol : > Fixes #4409. > > Signed-off-by: Paul B Mahol > --- > 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
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 18:58 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 18:19 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 17:33 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : Fixes #4409. Signed-off-by: Paul B Mahol --- 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? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-05 18:58 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 18:19 GMT+01:00, Paul B Mahol : >>> On 12/5/18, Carl Eugen Hoyos wrote: 2018-12-05 17:33 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >>> Fixes #4409. >>> >>> Signed-off-by: Paul B Mahol >>> --- >>> 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. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 18:19 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 17:33 GMT+01:00, Paul B Mahol : On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >> Fixes #4409. >> >> Signed-off-by: Paul B Mahol >> --- >> 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? > > 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 conflict and do not follow specification is not productive. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 17:33 GMT+01:00, Paul B Mahol : >> On 12/5/18, Carl Eugen Hoyos wrote: >>> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : Fixes #4409. Signed-off-by: Paul B Mahol --- 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-05 17:33 GMT+01:00, Paul B Mahol : > On 12/5/18, Carl Eugen Hoyos wrote: >> 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >>> Fixes #4409. >>> >>> Signed-off-by: Paul B Mahol >>> --- >>> 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? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
On 12/5/18, Carl Eugen Hoyos wrote: > 2018-12-05 14:27 GMT+01:00, Paul B Mahol : >> Fixes #4409. >> >> Signed-off-by: Paul B Mahol >> --- >> 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
2018-12-05 14:27 GMT+01:00, Paul B Mahol : > Fixes #4409. > > Signed-off-by: Paul B Mahol > --- > 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 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/dpx: do not reset n_datum to 0 at end of row for packing 2
Fixes #4409. Signed-off-by: Paul B Mahol --- 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]; } -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
