Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On Mon, Feb 05, 2018 at 10:05:50PM +0100, Jerome Martinez wrote: > On 04/02/2018 15:00, Michael Niedermayer wrote: > > > >>diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c > >>index b7eea0dd70..2763082540 100644 > >>--- a/libavcodec/ffv1enc_template.c > >>+++ b/libavcodec/ffv1enc_template.c > >>@@ -122,8 +122,8 @@ static av_always_inline int > >>RENAME(encode_line)(FFV1Context *s, int w, > >> return 0; > >> } > >>-static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[3], > >>-int w, int h, const int stride[3]) > >>+static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[4], > >>+int w, int h, const int stride[4]) > >> { > >> int x, y, p, i; > >> const int ring_size = s->context_model ? 3 : 2; > >>@@ -152,14 +152,18 @@ static int RENAME(encode_rgb_frame)(FFV1Context *s, > >>const uint8_t *src[3], > >> r = (v >> 16) & 0xFF; > >> a = v >> 24; > >> } else if (packed) { > >>-const uint16_t *p = ((const uint16_t*)(src[0] + x*6 + > >>stride[0]*y)); > >>+const uint16_t *p = ((const uint16_t*)(src[0] + x*(3 + > >>s->transparency)*2 + stride[0]*y)); > >> r = p[0]; > >> g = p[1]; > >> b = p[2]; > >>+if (s->transparency) > >transparency should possibly be moved into a local variable > > Done, actually both s->transparency and (3 + s->transparency)*2 > > > > > > >>+ a = p[3]; > >> } else if (sizeof(TYPE) == 4) { > >> g = *((const uint16_t *)(src[0] + x*2 + stride[0]*y)); > >> b = *((const uint16_t *)(src[1] + x*2 + stride[1]*y)); > >> r = *((const uint16_t *)(src[2] + x*2 + stride[2]*y)); > >>+if (s->transparency) > >>+a = *((const uint16_t *)(src[3] + x*2 + stride[2]*y)); > >^ > >this looks wrong > > Stupid typo not seen as strides are same here, fixed (I reviewed again the > patch, looks like it is the only one in the list of changes). > > Updated patch attached. > > > > > > >also what speed effect do thes changes to the inner loop have ? > > I see same performance, which I expect because when I do performance > profiling I see that the transformation part is taking less than 0.1% of the > CPU time and I guess that the CPU prediction stuff does its job here. I dont belive that the transformation takes less than 0.1% of the time please use START/STOP_TIMER for benchmarking code > > ffv1dec.c | 14 ++ > ffv1dec_template.c |9 +++-- > ffv1enc.c | 16 ++-- > ffv1enc_template.c | 14 ++ > 4 files changed, 41 insertions(+), 12 deletions(-) > e625fd3a9e40ad1baee2e6bfe1d5cfb35b772f79 > 0001-avcodec-ffv1-Support-for-RGBA64-and-GBRAP16.patch > From 0b9501984a8ce95d6e88a448683fd0d9d1473a08 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= > Date: Thu, 1 Feb 2018 13:11:53 +0100 > Subject: [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On 04/02/2018 15:00, Michael Niedermayer wrote: diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c index b7eea0dd70..2763082540 100644 --- a/libavcodec/ffv1enc_template.c +++ b/libavcodec/ffv1enc_template.c @@ -122,8 +122,8 @@ static av_always_inline int RENAME(encode_line)(FFV1Context *s, int w, return 0; } -static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[3], -int w, int h, const int stride[3]) +static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[4], +int w, int h, const int stride[4]) { int x, y, p, i; const int ring_size = s->context_model ? 3 : 2; @@ -152,14 +152,18 @@ static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[3], r = (v >> 16) & 0xFF; a = v >> 24; } else if (packed) { -const uint16_t *p = ((const uint16_t*)(src[0] + x*6 + stride[0]*y)); +const uint16_t *p = ((const uint16_t*)(src[0] + x*(3 + s->transparency)*2 + stride[0]*y)); r = p[0]; g = p[1]; b = p[2]; +if (s->transparency) transparency should possibly be moved into a local variable Done, actually both s->transparency and (3 + s->transparency)*2 + a = p[3]; } else if (sizeof(TYPE) == 4) { g = *((const uint16_t *)(src[0] + x*2 + stride[0]*y)); b = *((const uint16_t *)(src[1] + x*2 + stride[1]*y)); r = *((const uint16_t *)(src[2] + x*2 + stride[2]*y)); +if (s->transparency) +a = *((const uint16_t *)(src[3] + x*2 + stride[2]*y)); ^ this looks wrong Stupid typo not seen as strides are same here, fixed (I reviewed again the patch, looks like it is the only one in the list of changes). Updated patch attached. also what speed effect do thes changes to the inner loop have ? I see same performance, which I expect because when I do performance profiling I see that the transformation part is taking less than 0.1% of the CPU time and I guess that the CPU prediction stuff does its job here. From 0b9501984a8ce95d6e88a448683fd0d9d1473a08 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Thu, 1 Feb 2018 13:11:53 +0100 Subject: [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 --- libavcodec/ffv1dec.c | 14 ++ libavcodec/ffv1dec_template.c | 9 +++-- libavcodec/ffv1enc.c | 16 ++-- libavcodec/ffv1enc_template.c | 14 ++ 4 files changed, 41 insertions(+), 12 deletions(-) diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c index 5eadb6b158..923b79f3ab 100644 --- a/libavcodec/ffv1dec.c +++ b/libavcodec/ffv1dec.c @@ -336,14 +336,16 @@ static int decode_slice(AVCodecContext *c, void *arg) decode_plane(fs, p->data[0] + ps*x + y*p->linesize[0], width, height, p->linesize[0], 0, 2); decode_plane(fs, p->data[0] + ps*x + y*p->linesize[0] + 1, width, height, p->linesize[0], 1, 2); } else if (f->use32bit) { -uint8_t *planes[3] = { p->data[0] + ps * x + y * p->linesize[0], +uint8_t *planes[4] = { p->data[0] + ps * x + y * p->linesize[0], p->data[1] + ps * x + y * p->linesize[1], - p->data[2] + ps * x + y * p->linesize[2] }; + p->data[2] + ps * x + y * p->linesize[2], + p->data[3] + ps * x + y * p->linesize[3] }; decode_rgb_frame32(fs, planes, width, height, p->linesize); } else { -uint8_t *planes[3] = { p->data[0] + ps * x + y * p->linesize[0], +uint8_t *planes[4] = { p->data[0] + ps * x + y * p->linesize[0], p->data[1] + ps * x + y * p->linesize[1], - p->data[2] + ps * x + y * p->linesize[2] }; + p->data[2] + ps * x + y * p->linesize[2], + p->data[3] + ps * x + y * p->linesize[3] }; decode_rgb_frame(fs, planes, width, height, p->linesize); } if (fs->ac != AC_GOLOMB_RICE && f->version > 2) { @@ -694,6 +696,10 @@ static int read_header(FFV1Context *f) f->avctx->pix_fmt = AV_PIX_FMT_GBRP16; f->use32bit = 1; } +else if (f->avctx->bits_per_raw_sample == 16 && f->transparency) { +f->avctx->pix_fmt = AV_PIX_FMT_GBRAP16; +f->use32bit = 1; +} } else { av_log(f->avctx, AV_LOG_ERROR, "colorspace not supported\n"); return AVERROR(ENOSYS); diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c index 37df766773..a25b3384f1 100644 --- a/libavcodec/ffv1dec_template.c +++ b/libavcodec/ff
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: > Add support for 16-bit/component RGB with Alpha encoding and decoding in > FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. > > Resulting bitstream was tested about lossless encoding/decoding by the > compression from DPX to FFV1 then decompression from FFV1 to DPX, see > commands below (resulting framemd5 hashes are all same). > Resulting bitstream is decodable by another decoder (with same resulting > framemd5 hash). > Resulting bitstream passed through a conformance checker compared to current > FFV1 specification IETF draft. > > About the patch: > - some modified lines are not used (the ones not used when f->use32bit is > 1), but it makes the code more coherent (especially because decode_rgb_frame > signature is same for both 16-bit and 32-bit version) and prepares the > support of RGBA with 10/12/14 bits/component. > - GBRAP16 was chosen for decoding because GBRP16 is already used when no > alpha, and the code is more prepared for planar pix_fmt when bit depth is > >8. > - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" > is a copy of a line a bit above about the detection of transparency, I > preferred to reuse it as is even if "YA" 16-bit/component is not (yet) > supported. > > FFmpeg commands used for tests: > ./ffmpeg -i in.dpx -c:v ffv1 out.mkv > ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv > ./ffmpeg -i out.mkv out.dpx > > ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 > ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 > ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 > ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 > > Test file used (renamed to in.dpx): > https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx > > Jérôme > [...] > diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c > index b7eea0dd70..2763082540 100644 > --- a/libavcodec/ffv1enc_template.c > +++ b/libavcodec/ffv1enc_template.c > @@ -122,8 +122,8 @@ static av_always_inline int > RENAME(encode_line)(FFV1Context *s, int w, > return 0; > } > > -static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[3], > -int w, int h, const int stride[3]) > +static int RENAME(encode_rgb_frame)(FFV1Context *s, const uint8_t *src[4], > +int w, int h, const int stride[4]) > { > int x, y, p, i; > const int ring_size = s->context_model ? 3 : 2; > @@ -152,14 +152,18 @@ static int RENAME(encode_rgb_frame)(FFV1Context *s, > const uint8_t *src[3], > r = (v >> 16) & 0xFF; > a = v >> 24; > } else if (packed) { > -const uint16_t *p = ((const uint16_t*)(src[0] + x*6 + > stride[0]*y)); > +const uint16_t *p = ((const uint16_t*)(src[0] + x*(3 + > s->transparency)*2 + stride[0]*y)); > r = p[0]; > g = p[1]; > b = p[2]; > +if (s->transparency) transparency should possibly be moved into a local variable > + a = p[3]; > } else if (sizeof(TYPE) == 4) { > g = *((const uint16_t *)(src[0] + x*2 + stride[0]*y)); > b = *((const uint16_t *)(src[1] + x*2 + stride[1]*y)); > r = *((const uint16_t *)(src[2] + x*2 + stride[2]*y)); > +if (s->transparency) > +a = *((const uint16_t *)(src[3] + x*2 + stride[2]*y)); ^ this looks wrong also what speed effect do thes changes to the inner loop have ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On 03/02/2018 00:10, Michael Niedermayer wrote: On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: Add support for 16-bit/component RGB with Alpha encoding and decoding in FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. Resulting bitstream was tested about lossless encoding/decoding by the compression from DPX to FFV1 then decompression from FFV1 to DPX, see commands below (resulting framemd5 hashes are all same). Resulting bitstream is decodable by another decoder (with same resulting framemd5 hash). Resulting bitstream passed through a conformance checker compared to current FFV1 specification IETF draft. About the patch: - some modified lines are not used (the ones not used when f->use32bit is 1), but it makes the code more coherent (especially because decode_rgb_frame signature is same for both 16-bit and 32-bit version) and prepares the support of RGBA with 10/12/14 bits/component. - GBRAP16 was chosen for decoding because GBRP16 is already used when no alpha, and the code is more prepared for planar pix_fmt when bit depth is 8. - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" is a copy of a line a bit above about the detection of transparency, I preferred to reuse it as is even if "YA" 16-bit/component is not (yet) supported. FFmpeg commands used for tests: ./ffmpeg -i in.dpx -c:v ffv1 out.mkv ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv ./ffmpeg -i out.mkv out.dpx ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 Test file used (renamed to in.dpx): https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx I would prefer if the algorithm would be tuned to 16bit data before adding more formats to the encoder which require all decoders to support them. Dont you agree that this would be the better strategy ? ccing CELLAR. My remarks are the same as with RGB48 support (including that the compression performance of RGB48 so RGBA64 is already very good without touching on the algorithm, and IMO tuning should be for v4 for all bit depths), with addition that since the last debate on that on ffmpeg-devel there was no patch proposal so no consensus on CELLAR for limiting the specifications to what exists in FFmpeg implementation (so current consensus is that FFV1 specs are for all bit depths for all supported color spaces), and since the last debate FFV1 specs draft were sent to IETF tracker so it is close to the end. This patch is just adding the support of RGBA64 conforming to the current specs and without big changes (no complex stuff, just mapping to the right pix_fmt), and the current specs are the ones with very high chances to be the standard (up to now nobody suggested on CELLAR, the place for the spec, to limit the support to a set of bit depths / color spaces, and nobody suggested a tuning for some bit depths), with the main advantage that the specs are clear about all bit depths for all color spaces supported (it is good that it is generic). Will this patch be accepted after the IETF flags the current specs as stable if there is no changes on the wording about the support of all bit depths? on my side, I can not spend time on FFV1 v4 R&D (tuning and more) when I spend time with such blocking (for me) issue about v3 (i.e. agreement in specs draft on all bit depths for all supported color spaces but no agreement in practice on all bit depths for all supported color spaces). So for answering directly to the question, no I don't agree that changing v3 bitstream with specific tuning of the bitstream depending of the bit depth is a better strategy, actually this is the opposite (I think that the best strategy is to support as many bit depths as possible in implementations with current v3 specs and that all tuning should be in the version flagged as experimental, not the one flagged as stable even before working on IETF version, if we change a bitstream marked as stable we break the trust in the spec being stable, IMO any tuning of the bitstream should be done in v4, and any performance improvement without breaking the bitstream could be done after this patch without problem). Jérôme ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
Michael Niedermayer wrote: >I would prefer if the algorithm would be tuned to 16bit data >before adding more formats to the encoder which require all >decoders to support them. > >Dont you agree that this would be the better strategy ? To my understanding FFV1 v3 is actually stable. Or am I missing something? Some of us are indeed trying to work on v4, but this is another topic, I guess. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: > Add support for 16-bit/component RGB with Alpha encoding and decoding in > FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. > > Resulting bitstream was tested about lossless encoding/decoding by the > compression from DPX to FFV1 then decompression from FFV1 to DPX, see > commands below (resulting framemd5 hashes are all same). > Resulting bitstream is decodable by another decoder (with same resulting > framemd5 hash). > Resulting bitstream passed through a conformance checker compared to current > FFV1 specification IETF draft. > > About the patch: > - some modified lines are not used (the ones not used when f->use32bit is > 1), but it makes the code more coherent (especially because decode_rgb_frame > signature is same for both 16-bit and 32-bit version) and prepares the > support of RGBA with 10/12/14 bits/component. > - GBRAP16 was chosen for decoding because GBRP16 is already used when no > alpha, and the code is more prepared for planar pix_fmt when bit depth is > >8. > - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" > is a copy of a line a bit above about the detection of transparency, I > preferred to reuse it as is even if "YA" 16-bit/component is not (yet) > supported. > > FFmpeg commands used for tests: > ./ffmpeg -i in.dpx -c:v ffv1 out.mkv > ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv > ./ffmpeg -i out.mkv out.dpx > > ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 > ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 > ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 > ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 > > Test file used (renamed to in.dpx): > https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx I would prefer if the algorithm would be tuned to 16bit data before adding more formats to the encoder which require all decoders to support them. Dont you agree that this would be the better strategy ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
Add support for 16-bit/component RGB with Alpha encoding and decoding in FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. Resulting bitstream was tested about lossless encoding/decoding by the compression from DPX to FFV1 then decompression from FFV1 to DPX, see commands below (resulting framemd5 hashes are all same). Resulting bitstream is decodable by another decoder (with same resulting framemd5 hash). Resulting bitstream passed through a conformance checker compared to current FFV1 specification IETF draft. About the patch: - some modified lines are not used (the ones not used when f->use32bit is 1), but it makes the code more coherent (especially because decode_rgb_frame signature is same for both 16-bit and 32-bit version) and prepares the support of RGBA with 10/12/14 bits/component. - GBRAP16 was chosen for decoding because GBRP16 is already used when no alpha, and the code is more prepared for planar pix_fmt when bit depth is >8. - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" is a copy of a line a bit above about the detection of transparency, I preferred to reuse it as is even if "YA" 16-bit/component is not (yet) supported. FFmpeg commands used for tests: ./ffmpeg -i in.dpx -c:v ffv1 out.mkv ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv ./ffmpeg -i out.mkv out.dpx ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 Test file used (renamed to in.dpx): https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx Jérôme From 0e149afd7eadb1ec05cc79fff78337b2c543ad8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Thu, 1 Feb 2018 13:11:53 +0100 Subject: [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 --- libavcodec/ffv1dec.c | 14 ++ libavcodec/ffv1dec_template.c | 6 +- libavcodec/ffv1enc.c | 16 ++-- libavcodec/ffv1enc_template.c | 10 +++--- 4 files changed, 36 insertions(+), 10 deletions(-) diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c index 5eadb6b158..923b79f3ab 100644 --- a/libavcodec/ffv1dec.c +++ b/libavcodec/ffv1dec.c @@ -336,14 +336,16 @@ static int decode_slice(AVCodecContext *c, void *arg) decode_plane(fs, p->data[0] + ps*x + y*p->linesize[0], width, height, p->linesize[0], 0, 2); decode_plane(fs, p->data[0] + ps*x + y*p->linesize[0] + 1, width, height, p->linesize[0], 1, 2); } else if (f->use32bit) { -uint8_t *planes[3] = { p->data[0] + ps * x + y * p->linesize[0], +uint8_t *planes[4] = { p->data[0] + ps * x + y * p->linesize[0], p->data[1] + ps * x + y * p->linesize[1], - p->data[2] + ps * x + y * p->linesize[2] }; + p->data[2] + ps * x + y * p->linesize[2], + p->data[3] + ps * x + y * p->linesize[3] }; decode_rgb_frame32(fs, planes, width, height, p->linesize); } else { -uint8_t *planes[3] = { p->data[0] + ps * x + y * p->linesize[0], +uint8_t *planes[4] = { p->data[0] + ps * x + y * p->linesize[0], p->data[1] + ps * x + y * p->linesize[1], - p->data[2] + ps * x + y * p->linesize[2] }; + p->data[2] + ps * x + y * p->linesize[2], + p->data[3] + ps * x + y * p->linesize[3] }; decode_rgb_frame(fs, planes, width, height, p->linesize); } if (fs->ac != AC_GOLOMB_RICE && f->version > 2) { @@ -694,6 +696,10 @@ static int read_header(FFV1Context *f) f->avctx->pix_fmt = AV_PIX_FMT_GBRP16; f->use32bit = 1; } +else if (f->avctx->bits_per_raw_sample == 16 && f->transparency) { +f->avctx->pix_fmt = AV_PIX_FMT_GBRAP16; +f->use32bit = 1; +} } else { av_log(f->avctx, AV_LOG_ERROR, "colorspace not supported\n"); return AVERROR(ENOSYS); diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c index 37df766773..2904a44112 100644 --- a/libavcodec/ffv1dec_template.c +++ b/libavcodec/ffv1dec_template.c @@ -107,7 +107,7 @@ static av_always_inline int RENAME(decode_line)(FFV1Context *s, int w, return 0; } -static void RENAME(decode_rgb_frame)(FFV1Context *s, uint8_t *src[3], int w, int h, int stride[3]) +static void RENAME(decode_rgb_frame)(FFV1Context *s, uint8_t *src[4], int w, int h, int stride[4]) { int x, y, p; TYPE *sample[4][2]; @@ -158,10 +158,14 @@ static void RENAME(decode_rgb_frame)(FFV1Context *s, uint8_t *src[3], int w, int *((uint16_t*)(src[0] + x*2 + stride[0]*y)) = g; *((uint16_t*)(src[1] + x*2 + stride[1]*y)) = b;