"GStreamer" (GNOME Bugzilla)
2015-04-30 08:49:29 UTC
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-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@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?
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-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@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.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.