[Bug 748686] encodebin/decodebin: va/non-va does not play happily together as good children should

[gstreamer-vaapi (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk
          Component|gst-plugins-base            |general
           Assignee|gstreamer-bugs at lists.freede |gstreamer-vaapi-maint at gnome
                   |sktop.org                   |.bugs
            Product|GStreamer                   |gstreamer-vaapi
   Target Milestone|git master                  |---
         QA Contact|gstreamer-bugs at lists.freede |gstreamer-vaapi-maint at gnome
                   |sktop.org                   |.bugs

--- Comment #1 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Marc Leeman from comment #0)
> 
> 1/ encodebin (and decodebin) only plug in the va variants on supported CPUs.
> Maybe the va elements should return when there is no support.

This is already handled in decodebin by trying to set the element to READY
state before using it.

> 
> 2/ It should be configurable to use the va/non-va variant on a higher level
> so that e.g. the first 6 instances use the va variants and others the non-va
> variant. Would it be a good idea in a mechanism like playbin where the
> diplay element can be specified as a property?

Dealing with instance and resources saturation should be handled by not letting
a new element got to ready state. Though note that detecting HW saturation is
non-trivial for VA since the needed HW is highly shared.

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