gstreamer

mirrors/gstreamer

Fork 0

mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-08 18:39:54 +00:00

Commit graph

Author	SHA1	Message	Date
Haihao Xiang	956d6e8ff7	va: sort the device queue If so, the elements will be registered per drm node in order of renderD128, renderD129, ... etc, an element with constant name will be registered on renderD128 on a hardware with multiple drm nodes. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1988>	2021-02-02 10:28:04 +08:00
Víctor Manuel Jáquez Leal	f6a623d565	va: device: use gst_clear_object() Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>	2020-09-23 18:19:22 +02:00
Víctor Manuel Jáquez Leal	79d11c2022	va: VA-API H.264 decoder and infrastructure New plugin with an element for H.264 decoding with VA-API. This novel approach, different from gstreamer-vaapi, uses gstcodecs library for state handling. The code is expected to looks cleaner because it uses VA-API without further layers or wrappers. * It uses the first supported DRM device as default VA display (other displays will be supported through user's GstContext) * Requires libva >= 1.6 * No multiview/stereo profiles neither interlaced streams because gstcodecs doesn't handle them yet * It is incompatible with gstreamer-vaapi * Even if memory:VAMemory is exposed, it is not handled yet by any other element * Caps templates are generated dynamically querying VAAPI, but YV12 and I420 are added for system memory caps because they seem to be supported for all the drivers when downloading frames onto main memory, as they are used by xvimagesink and others, avoiding color conversion. * Surfaces aren't bounded to context, so they can grow beyond the DBP size, allowing smooth reverse playback. * There isn't yet error handling and recovery. * 10-bit H.264 streams aren't supported by libva. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>	2020-06-28 11:47:35 +02:00

Author

SHA1

Message

Date

Haihao Xiang

956d6e8ff7

va: sort the device queue

If so, the elements will be registered per drm node in order of
renderD128, renderD129, ... etc, an element with constant name will be
registered on renderD128 on a hardware with multiple drm nodes.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1988>

2021-02-02 10:28:04 +08:00

Víctor Manuel Jáquez Leal

f6a623d565

va: device: use gst_clear_object()

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1529>

2020-09-23 18:19:22 +02:00

Víctor Manuel Jáquez Leal

79d11c2022

va: VA-API H.264 decoder and infrastructure

New plugin with an element for H.264 decoding with VA-API. This novel
approach, different from gstreamer-vaapi, uses gstcodecs library for
state handling.

The code is expected to looks cleaner because it uses VA-API without
further layers or wrappers.

* It uses the first supported DRM device as default VA display (other
  displays will be supported through user's GstContext)
* Requires libva >= 1.6
* No multiview/stereo profiles neither interlaced streams because
  gstcodecs doesn't handle them yet
* It is incompatible with gstreamer-vaapi
* Even if memory:VAMemory is exposed, it is not handled yet by any
  other element
* Caps templates are generated dynamically querying VAAPI, but YV12
  and I420 are added for system memory caps because they seem to be
  supported for all the drivers when downloading frames onto main
  memory, as they are used by xvimagesink and others, avoiding color
  conversion.
* Surfaces aren't bounded to context, so they can grow beyond the DBP
  size, allowing smooth reverse playback.
* There isn't yet error handling and recovery.
* 10-bit H.264 streams aren't supported by libva.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1379>

2020-06-28 11:47:35 +02:00

3 commits