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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 748686
           Summary: encodebin/decodebin: va/non-va does not play happily
                    together as good children should
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: marc.leeman at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

The problem is likely in essence similar for encoding and decoding.

When using CPUs that have some form of VA (e.g. QuickSync) and when the
gst-vaapi elements are installed, when encoding and/or decoding; the va variant
of the decoder/encoder is chosen (software and hardware elements seem to have
the same rank though).

This is fine in most cases where a user wants to decode a single video.

When more streams are processed, it is easy to overload the system (as seen in
framedrops for encoding and/or decoding), even thought the system has capacity
left.

On top of that, it is seen that, when the vaapi elements are installed on a
non-VA enabled system; it will break the functionality (tested for encoding at
least).

Improvements would be:

1/ encodebin (and decodebin) only plug in the va variants on supported CPUs.
Maybe the va elements should return when there is no support.

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?

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