GNOME Bugzilla – Bug 748686
encodebin/decodebin: va/non-va does not play happily together as good children should
Last modified: 2018-11-03 15:46:49 UTC
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?
(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.
Moving to Product:GStreamer, Component:gstreamer-vaapi
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/30.