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

Reply via email to