[FFmpeg-devel] PATCH: Fallback to NV12 format in VAAPI drivers
Lluís Batlle i Rossell
viric at viric.name
Sun Aug 11 23:21:22 EEST 2024
On Sun, Aug 11, 2024 at 06:57:49PM +0100, Mark Thompson wrote:
> On 10/08/2024 09:51, Lluís Batlle i Rossell wrote:
> > On Fri, Aug 09, 2024 at 09:43:53AM +0200, Lluís Batlle i Rossell wrote:
> >> On Fri, Aug 09, 2024 at 11:49:54AM +0800, Zhao Zhili wrote:
> >>>> vaapi drivers often lack proper image converesions and not all
> >>>> situations allow vagetimage or vaputimage with the image formats
> >>>> reported by the api. nv12 seems allowed in all circumstances.
> >>>>
> >>>> with this change now one can use the hwaccel directly without
> >>>> explicit conversions to nv12 for frame downloading to work.
> >>>>
> >>>> gstreamer adopted a similar approach:
> >>>> https://bugzilla.gnome.org/show_bug.cgi?id=752958
> >>>
> >>> Isn’t it break all pixel formats with bit depth > 8?
> >>> I think we already have hwcontext API to select sw_format, this isn’t a bug
> >>> inside ffmpeg.
> >>
> >> Correct... I didn't think of the need beyond NV12.
> >>
> >> What if I redo the patch so I keep all formats, but I simply move NV12 to
> >> the first place? That will make ffmpeg pick NV12 as default if NONE
> >> specified.
> >
> > I attach a different patch, so NV12 is only picked in case the dst format
> > is NONE.
>
> What are the surface formats where this actually gets used, and on what hardware and driver?
>
> It seems probably ok if this were restricted to 4:2:0 8-bit formats (as a surprise implicit downsample which can't be told anything about the source format seems very bad), but then what is it actually covering?
>
I have found that webcams doing mjpeg get the hw frames as yuv422, and
despite yuv422 is announced in ImageFormats, vaGetImage cannot download
it, with a pair of Intel cpus I tried. I looked at the driver code and
it looked broad.
So with the patches I'm exploring what can be a good approach to this
problem: va drivers report formats that maybe work through vaPutImage, but
not with vaGetImage, for what I've seen.
The immediate user problem of that is that operations using hwaccel vaapi
with mjpeg will end up failing, unless you specify an output format that
actually works. Otherwise, the vaGetImage operation says "not
implemented". So mjpeg hw decoding will not work unless
"-hwaccel_output_format" is given, or proper format is given to hwdownload
in filters.
More information about the ffmpeg-devel
mailing list