[Bug 786954] gst-validate scenarios case fail on DRM mode.

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from sreerenj <bsreerenj at gmail.com> ---
Easy way to reproduce the issue :
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm

Here the problem is that gst_vaapisink_set_caps() always return TRUE for drm 
display type with out even setting the plugin caps, pool and other attributes.
Then in the render frame routine vaapisink trying to copy the raw data from
input buffer to a va_surface backed sink buffer through
gst_vaapi_plugin_base_get_input_buffer() which is obviously going to fail since
we haven't created the sinkpad pool yet.

We usually don't hit this issue since even for drm use case the pool is shared
between upstream element and vaapisink (eg: decodebin ! vaapisink display=drm).

This particular test case is different since there is no pool shared between
the upstream element and vaapisink and eventually we have to copy the incoming
raw data buffer to vaapisink buffer from the pool.

Either we can just return from sink render function for drm display type or
make sure that all sink attributes including caps, pool etc set in set_caps().

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