[gst-devel] decodebin2 + VA-API integration

[Gwenole Beauchesne]

Hi,

On Mon, 10 May 2010, Michael Smith wrote:

>> $ gst-launch filesrc ! decodebin2 ! vaapisink
>>
>> Then, I changed GST_RANK_NONE to GST_RANK_PRIMARY, decodebin2 will now see
>> and use vaapidecode. However, it will fail to link vaapidecode to
>> vaapisink. Rather, it tries to link vaapidecode0:src to some
>> decodepad2:proxypad3 element.
>
> The proxy pad is an internal detail of how ghost pads work. The
> capabilities and so on of the ghost pad should be the same as the real
> pad, so this should work fine. If it's not... you need to figure out
> why it's not linking - the actual pad seems correct here.

OK, the reason why decodebin2 doesn't link vaapidecode to vaapisink is 
because it considers video/x-vaapi-surface as non final caps so it's still 
trying to find a better candidate for the next element. i.e. it tries to 
find another element to place between vaapidecode and vaapisink with 
video/x-vaapi-surface caps.

The problem is decode_bin->caps are hardcoded to some defaults that don't 
include video/x-vaapi-surface. So are_raw_caps() returns FALSE and we 
never go to the expose_pad case.

This means, gst-launch filesrc ! decodebin2 ! vaapisink can never work 
unless either (i) decode_bin->caps include video/x-vaapi-surface or (ii) 
we replace video/x-vaapi-surface with some known caps, possibly 
specialised with a specific format to mean a VA surface.

What would be the proper fix to this problem? Could we consider an 
"official" video/x-hw-surface caps with format = (string) 
VAAPI|VDPAU|Cairo, etc.?

BTW, I now can get a working playbin2 pipeline. The trick is to make sure 
any VA-API sink (vaapisink, cluttergstsink, etc.) has a custom 
buffer_alloc function and communicates the VA display through it.

Thanks,
Gwenole.