[Bug 752958] vaapidecode: cannot detect and output NV12

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=752958

--- Comment #15 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to Julien Isorce from comment #14)
> (In reply to Víctor Manuel Jáquez Leal from comment #12)
> > After sketching these patches, if found out that the context's available
> > formats (vaQuerySurfaceAttributes()) in the intel backend is also NV12 only.
> > 
> > Intersecting with vaQueryImageFormats() won't help.
> 
> Hi Victor, that's great that you looked at this bug. But would you mind to
> clarify your 2 last comments (#12 and #13). It looks to me that in first
> hand you are saying the intersection is not useful because
> vaQuerySurfaceAttributes returns always NV12 with intel vaapi backend. But
> then in your comment #13 you are pointing the function that actually shows
> that intel vaapi backend does not always return NV12 since it can return
> I420 depending on the hardware. Which would make the intersection actually
> useful. What am I missing ? :)

D'oh! Yes, sorry.

Comment #12 was the result of my frustration after coded the posted patches and
found that only NV12 was used in my setup (Haswell).

But today I saw the guts of vaQuerySurfaceAttributes(). And the results are in
comment #13. So, yes, the intersection looks interesting.

But I dig also in the vaGetImage():

* Intel backend can perform several color transformations according to the
hardware, and also supports a few by software as fallback
https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_drv_video.c#n4550
* mesa tracker only supports from NV12 to YV12
* old vdpau backend, supports from its native format to I420 and NV12

But those chroma transformation capabilities are not be "queried", as far as
know.

This leads me to a try-and-fail algorithm to check if I420 is supported.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.