On Tue, 31 Jan 2017 00:15:17 +0000 Mark Thompson <[email protected]> wrote:
> Adds a new driver quirk to indicate no support at all for surface > attributes. > > Based on a patch by wm4 <[email protected]>. > --- > On 30/01/17 12:48, wm4 wrote: > > On Mon, 30 Jan 2017 10:58:07 +0000 > > Mark Thompson <[email protected]> wrote: > >> We now require it in order to get the surface formats. It fails on OOM or > >> if the query function returns failure, so I think depending on it is > >> reasonable. (Though if you want the VDPAU wrapper to continue to work > >> that might require more hackery...) > > > > Should be fine then. > > > > Regarding the vdpau wrapper, I have a patch that makes it working with > > Libav git master, but I guess it's better to drop it. > > Does this work? It just avoids anything to do with surface attributes > entirely; the render target format should be sufficient on creation and the > allowed surface formats can be guessed to be the same as the image formats. > It might choose funny surface formats as a result, but since it's backed by > VDPAU that should be irrelevant because we can't map - all the access has to > go through transfer anyway. > > > libavutil/hwcontext_vaapi.c | 79 > ++++++++++++++++++++++++++------------------- > libavutil/hwcontext_vaapi.h | 7 ++++ > 2 files changed, 52 insertions(+), 34 deletions(-) I tried the patch you've sent on IRC. It still works for me. Whether this is worth supporting, I don't know. I find it nice being able to test at least some vaapi stuff on machines where only vdpau is available. But the driver is quite literally bitrotting, and there hasn't been a single commit to it for 4.5 years. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
