[FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around codec/profile selection

[Fu, Linjie]

> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Mark Thompson
> Sent: Monday, April 13, 2020 21:14
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around
> codec/profile selection
> 
> On 12/04/2020 18:19, Fu, Linjie wrote:
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Mark Thompson
> >> Sent: Sunday, April 12, 2020 21:00
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: [FFmpeg-devel] [PATCH] vaapi_decode: Improve logging around
> >> codec/profile selection
> >>
> >> ---
> >> On 12/04/2020 13:14, Mark Thompson wrote:
> >>> ...  This does rather suggest that the error messages in that file should be
> >> clearer, though - it would be nice if it could distinguish between "this
> codec
> >> isn't supported by libavcodec at all", "this codec might work but hasn't
> built
> >> into this libavcodec" and "this codec is supported by libavcodec but not by
> >> your hardware".
> >>
> >> Something like this?
> >>
> >>
> >>  libavcodec/vaapi_decode.c | 39
> +++++++++++++++++++++++++++++++----
> >> ----
> >>  1 file changed, 31 insertions(+), 8 deletions(-)
> >>
> >> --
> > Generally makes sense, however there is one concern if I got it correctly:
> >
> > If a codec is not supported by VAAPI in current libavcodec build,
> ff_get_format()
> > would not select VAAPI as the HW acceleration.
> > Instead, it would fallback to the native software decoding path, and won't
> trigger
> > the (!found_codec) logic.
> >
> > ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
> >
> > $ ffmpeg -v debug -hwaccel vaapi -
> i ./hevc_rext_decode/Main_422_10_A_RExt_Sony_2.bin -f null -
> >
> > Log:
> > [hevc @ 0x5592f7b0fec0] Format yuv422p10le chosen by get_format().
> >
> > VAAPI error return would not be triggered.
> 
> Yeah, it's not covering that case because of how get_format() works - the
> caller can't choose the VAAPI format, so we never get here.  If the caller
> really wanted VAAPI then they need to deal with it externally (for ffmpeg,
> you want something like the proposed -decode_format option:
> <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2018-
> November/236205.html>).
> 
> The case where the "no codec" message is triggered is when you can pick it
> (the hwaccel is enabled) but the build still doesn't have the codec in the table
> (for example if it were built against older libva headers).
> 
Yep, got the point and looks reasonable, thanks for elaboration.

- Linjie