diff mbox series

[FFmpeg-devel,8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit VAAPI decode support

Message ID 1579071741-13731-1-git-send-email-linjie.fu@intel.com
State Accepted
Headers show
Series [FFmpeg-devel,1/9] lavu/pix_fmt: add new pixel format y210
Related show

Checks

Context Check Description
andriy/ffmpeg-patchwork pending
andriy/ffmpeg-patchwork success Applied patch
andriy/ffmpeg-patchwork success Configure finished
andriy/ffmpeg-patchwork success Make finished
andriy/ffmpeg-patchwork success Make fate finished

Commit Message

Fu, Linjie Jan. 15, 2020, 7:02 a.m. UTC
Add decode support for 4:2:2 8-bt and 10-bit HEVC Range Extension clips.

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
---
 libavcodec/hevcdec.c | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Mark Thompson Feb. 24, 2020, 12:24 a.m. UTC | #1
On 15/01/2020 07:02, Linjie Fu wrote:
> Add decode support for 4:2:2 8-bt and 10-bit HEVC Range Extension clips.
> 
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> ---
>  libavcodec/hevcdec.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 19b0cd8..f60bcf6 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -427,6 +427,12 @@ static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
>          *fmt++ = AV_PIX_FMT_CUDA;
>  #endif
>          break;
> +    case AV_PIX_FMT_YUV422P:
> +    case AV_PIX_FMT_YUV422P10LE:
> +#if CONFIG_HEVC_VAAPI_HWACCEL
> +       *fmt++ = AV_PIX_FMT_VAAPI;
> +#endif
> +        break;
>      case AV_PIX_FMT_YUV420P12:
>      case AV_PIX_FMT_YUV444P10:
>      case AV_PIX_FMT_YUV444P12:
> 

We seem to have agreement that the Y210 / wider YUYV is fine (bit-packed Y410 was the case people had problems with) and everything else looks good, so set tested and applied.

Thanks,

- Mark
Carl Eugen Hoyos Feb. 24, 2020, 12:37 a.m. UTC | #2
Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson <sw@jkqxz.net>:

> We seem to have agreement that the Y210 / wider YUYV is fine

Why do you think so?
I was under the impression that we have agreement that this
has to be discussed further.

Carl Eugen
Mark Thompson Feb. 24, 2020, 1:09 a.m. UTC | #3
On 24/02/2020 00:37, Carl Eugen Hoyos wrote:
> Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
> 
>> We seem to have agreement that the Y210 / wider YUYV is fine
> 
> Why do you think so?
> I was under the impression that we have agreement that this
> has to be discussed further.

All of the dispute was about the bit-packed formats (Y410 = V210, and similar in RGB), and the other cases (Y210 = 10-bit YUYV, 0YUV = packed 8-bit YUV with padding) only got caught up in that discussion because they were originally submitted in the same patch.  I also clarified on IRC with Kieran that his mail replying to this patch (<https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-January/256040.html>) was referring to that case.

Thanks,

- Mark
Fu, Linjie Feb. 24, 2020, 1:19 a.m. UTC | #4
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Mark Thompson
> Sent: Monday, February 24, 2020 08:25
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 8/9] lavc/hevcdec: add 4:2:2 8-bit/10-bit
> VAAPI decode support
> 
> On 15/01/2020 07:02, Linjie Fu wrote:
> > Add decode support for 4:2:2 8-bt and 10-bit HEVC Range Extension clips.
> >
> > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > ---
> >  libavcodec/hevcdec.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 19b0cd8..f60bcf6 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -427,6 +427,12 @@ static enum AVPixelFormat
> get_format(HEVCContext *s, const HEVCSPS *sps)
> >          *fmt++ = AV_PIX_FMT_CUDA;
> >  #endif
> >          break;
> > +    case AV_PIX_FMT_YUV422P:
> > +    case AV_PIX_FMT_YUV422P10LE:
> > +#if CONFIG_HEVC_VAAPI_HWACCEL
> > +       *fmt++ = AV_PIX_FMT_VAAPI;
> > +#endif
> > +        break;
> >      case AV_PIX_FMT_YUV420P12:
> >      case AV_PIX_FMT_YUV444P10:
> >      case AV_PIX_FMT_YUV444P12:
> >
> 
> We seem to have agreement that the Y210 / wider YUYV is fine (bit-packed
> Y410 was the case people had problems with) and everything else looks good,
> so set tested and applied.
> 
> Thanks,
> 
> - Mark

Thanks a lot for the review and suggestions.

Regards,
Linjie
Carl Eugen Hoyos Feb. 24, 2020, 10:58 a.m. UTC | #5
Am Mo., 24. Feb. 2020 um 02:09 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
>
> On 24/02/2020 00:37, Carl Eugen Hoyos wrote:
> > Am Mo., 24. Feb. 2020 um 01:25 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
> >
> >> We seem to have agreement that the Y210 / wider YUYV is fine
> >
> > Why do you think so?
> > I was under the impression that we have agreement that this
> > has to be discussed further.
>
> All of the dispute was about the bit-packed formats

That's not how I remembered it and I would like to remind you that
while uncontroversial patches in general need no approval at all
controversial patches can only be approved on the mailing list, not on irc.

(Funny that the link you provided completely contradicts your argument)

Note that I don't really care, I simply remember people arguing in the past
that we have too many pix_fmts and that we recently agreed we want to
discuss with Intel why we have to treat them differently than the other
hardware manufacturers.
This agreement was made after we were asked to meet because it was
claimed we need new mechanisms to discuss technical questions.

Carl Eugen
diff mbox series

Patch

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 19b0cd8..f60bcf6 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -427,6 +427,12 @@  static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps)
         *fmt++ = AV_PIX_FMT_CUDA;
 #endif
         break;
+    case AV_PIX_FMT_YUV422P:
+    case AV_PIX_FMT_YUV422P10LE:
+#if CONFIG_HEVC_VAAPI_HWACCEL
+       *fmt++ = AV_PIX_FMT_VAAPI;
+#endif
+        break;
     case AV_PIX_FMT_YUV420P12:
     case AV_PIX_FMT_YUV444P10:
     case AV_PIX_FMT_YUV444P12: