| Message ID | 20220806032754.71419-3-philipl@overt.org |
|---|---|
| State | New |
| Headers | show |
| Series | lavc/vaapi: More 4:4:4 changes | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On Fri, 2022-08-05 at 20:27 -0700, Philip Langdale wrote: > Sufficiently recent Intel hardware is able to do encoding of 8bit 4:4:4 > content in HEVC and VP9. The main requirement here is that the frames > must be provided in the AYUV format. > > Enabling support is done by adding the appropriate encoding profiles > and noting that AYUV is officially a four channel format with alpha so > we must state that we expect all four channels. > > Also, there are currently very limited ways to get data into the right > format. While our VUYA format exists, the swscale code that can convert > to VUYA is pending, but I've tested it and it works as expected. > > Signed-off-by: Philip Langdale <philipl@overt.org> > --- > libavcodec/vaapi_encode.c | 1 + > libavcodec/vaapi_encode_h265.c | 2 ++ > libavcodec/vaapi_encode_vp9.c | 2 ++ > 3 files changed, 5 insertions(+) > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c > index 284ce29888..f13daa5cff 100644 > --- a/libavcodec/vaapi_encode.c > +++ b/libavcodec/vaapi_encode.c > @@ -1308,6 +1308,7 @@ static const VAAPIEncodeRTFormat > vaapi_encode_rt_formats[] = { > { "YUV422_10", VA_RT_FORMAT_YUV422_10, 10, 3, 1, 0 }, > #endif > { "YUV444", VA_RT_FORMAT_YUV444, 8, 3, 0, 0 }, > + { "AYUV", VA_RT_FORMAT_YUV444, 8, 4, 0, 0 }, > { "YUV411", VA_RT_FORMAT_YUV411, 8, 3, 2, 0 }, > #if VA_CHECK_VERSION(0, 38, 1) > { "YUV420_10", VA_RT_FORMAT_YUV420_10BPP, 10, 3, 1, 1 }, > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c > index d5375add22..1de323af78 100644 > --- a/libavcodec/vaapi_encode_h265.c > +++ b/libavcodec/vaapi_encode_h265.c > @@ -1278,6 +1278,8 @@ static const VAAPIEncodeProfile > vaapi_encode_h265_profiles[] = { > #if VA_CHECK_VERSION(1, 2, 0) > { FF_PROFILE_HEVC_REXT, 8, 3, 1, 0, VAProfileHEVCMain422_10 }, > { FF_PROFILE_HEVC_REXT, 10, 3, 1, 0, VAProfileHEVCMain422_10 }, > + // Four channels because this uses the AYUV format which has Alpha > + { FF_PROFILE_HEVC_REXT, 8, 4, 0, 0, VAProfileHEVCMain444 }, > #endif > { FF_PROFILE_UNKNOWN } > }; > diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c > index 892ad770c6..9b455e10c9 100644 > --- a/libavcodec/vaapi_encode_vp9.c > +++ b/libavcodec/vaapi_encode_vp9.c > @@ -228,6 +228,8 @@ static av_cold int > vaapi_encode_vp9_configure(AVCodecContext *avctx) > > static const VAAPIEncodeProfile vaapi_encode_vp9_profiles[] = { > { FF_PROFILE_VP9_0, 8, 3, 1, 1, VAProfileVP9Profile0 }, > + // Four channels because this uses the AYUV format which has Alpha > + { FF_PROFILE_VP9_1, 8, 4, 0, 0, VAProfileVP9Profile1 }, > { FF_PROFILE_VP9_2, 10, 3, 1, 1, VAProfileVP9Profile2 }, > { FF_PROFILE_UNKNOWN } > }; LGTM, thx -Haihao
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index 284ce29888..f13daa5cff 100644 --- a/libavcodec/vaapi_encode.c +++ b/libavcodec/vaapi_encode.c @@ -1308,6 +1308,7 @@ static const VAAPIEncodeRTFormat vaapi_encode_rt_formats[] = { { "YUV422_10", VA_RT_FORMAT_YUV422_10, 10, 3, 1, 0 }, #endif { "YUV444", VA_RT_FORMAT_YUV444, 8, 3, 0, 0 }, + { "AYUV", VA_RT_FORMAT_YUV444, 8, 4, 0, 0 }, { "YUV411", VA_RT_FORMAT_YUV411, 8, 3, 2, 0 }, #if VA_CHECK_VERSION(0, 38, 1) { "YUV420_10", VA_RT_FORMAT_YUV420_10BPP, 10, 3, 1, 1 }, diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c index d5375add22..1de323af78 100644 --- a/libavcodec/vaapi_encode_h265.c +++ b/libavcodec/vaapi_encode_h265.c @@ -1278,6 +1278,8 @@ static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = { #if VA_CHECK_VERSION(1, 2, 0) { FF_PROFILE_HEVC_REXT, 8, 3, 1, 0, VAProfileHEVCMain422_10 }, { FF_PROFILE_HEVC_REXT, 10, 3, 1, 0, VAProfileHEVCMain422_10 }, + // Four channels because this uses the AYUV format which has Alpha + { FF_PROFILE_HEVC_REXT, 8, 4, 0, 0, VAProfileHEVCMain444 }, #endif { FF_PROFILE_UNKNOWN } }; diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c index 892ad770c6..9b455e10c9 100644 --- a/libavcodec/vaapi_encode_vp9.c +++ b/libavcodec/vaapi_encode_vp9.c @@ -228,6 +228,8 @@ static av_cold int vaapi_encode_vp9_configure(AVCodecContext *avctx) static const VAAPIEncodeProfile vaapi_encode_vp9_profiles[] = { { FF_PROFILE_VP9_0, 8, 3, 1, 1, VAProfileVP9Profile0 }, + // Four channels because this uses the AYUV format which has Alpha + { FF_PROFILE_VP9_1, 8, 4, 0, 0, VAProfileVP9Profile1 }, { FF_PROFILE_VP9_2, 10, 3, 1, 1, VAProfileVP9Profile2 }, { FF_PROFILE_UNKNOWN } };
Sufficiently recent Intel hardware is able to do encoding of 8bit 4:4:4 content in HEVC and VP9. The main requirement here is that the frames must be provided in the AYUV format. Enabling support is done by adding the appropriate encoding profiles and noting that AYUV is officially a four channel format with alpha so we must state that we expect all four channels. Also, there are currently very limited ways to get data into the right format. While our VUYA format exists, the swscale code that can convert to VUYA is pending, but I've tested it and it works as expected. Signed-off-by: Philip Langdale <philipl@overt.org> --- libavcodec/vaapi_encode.c | 1 + libavcodec/vaapi_encode_h265.c | 2 ++ libavcodec/vaapi_encode_vp9.c | 2 ++ 3 files changed, 5 insertions(+)