thanks you Mark! will follow up on libva changes first.

David

On 2024-08-11 14:42, Mark Thompson wrote:
On 11/08/2024 19:27, Mark Thompson wrote:
On 30/07/2024 21:02, David (Ming Qiang) Wu via ffmpeg-devel wrote:
AV1Profile2 VAAPI is supported and tested on AMD VCN5.

Signed-off-by: David (Ming Qiang) Wu <david....@amd.com>
---
  libavcodec/av1dec.c       | 3 +++
  libavcodec/vaapi_decode.c | 3 +++
  2 files changed, 6 insertions(+)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 1d5b9ef4f4..77f63661a0 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -599,6 +599,9 @@ static int get_pixel_format(AVCodecContext *avctx)
      case AV_PIX_FMT_YUV420P12:
  #if CONFIG_AV1_VULKAN_HWACCEL
          *fmtp++ = AV_PIX_FMT_VULKAN;
+#endif
+#if CONFIG_AV1_VAAPI_HWACCEL
+        *fmtp++ = AV_PIX_FMT_VAAPI;
  #endif
          break;
      case AV_PIX_FMT_YUV422P:
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index a59194340f..a077e47326 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -448,6 +448,9 @@ static const struct {
      MAP(AV1,         AV1_MAIN,        AV1Profile0),
      MAP(AV1,         AV1_HIGH,        AV1Profile1),
  #endif
+#if VA_CHECK_VERSION(1, 23, 0)
+    MAP(AV1,         AV1_PROFESSIONAL, AV1Profile2),
+#endif
#undef MAP
  };
Based on <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30429> this 
is supporting profile 2 only for 4:2:0 12-bit, and therefore can't advertise profile 
2 generally for the decoder because that would imply support for all 4:2:2 and 4:4:4 
cases as well.

I think this wants something added to VAAPI in order to be able to advertise 
partial support for a profile?

(It would be very confusing if we got "AV1Profile2" in VAAPI meaning only 4:2:0 12-bit 
and then have to add a separate "AV1Profile2exceptreallythistime" to meant actual AV1 
profile 2.)
I commented in <https://github.com/intel/libva/pull/828>.

Please fix this before it get further in Mesa, having a version reporting 
incorrect decoder capabilities which we need to hack around elsewhere would be 
non-ideal.

Thanks,

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to