Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-06 Thread Michael Niedermayer 
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

2018-02-05 Thread Jerome Martinez 

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
---

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16

2018-02-04 Thread Michael Niedermayer 
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

2018-02-03 Thread Jerome Martinez 

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 (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

2018-02-03 Thread Reto Kromer 
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

2018-02-02 Thread Michael Niedermayer 
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

2018-02-01 Thread Jerome Martinez 
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 +