UxPlay uses GStreamer Plugins for rendering audio and video, This means that video and audio are supported “out of the box”, using a choice of plugins. AirPlay streams video in h264 format: gstreamer decoding is plugin agnostic, and uses accelerated GPU hardware h264 decoders if available; if not, software decoding is used.
For systems with Intel integrated graphics, hardware GPU decoding with the gstreamer VAAPI plugin is preferable. VAAPI is open-source, and in addition to Intel, can support some AMD GPU’s (the open-source “Nouveau” drivers for NVIDIA graphics are also in principle supported when VAAPI is supplemented with firmware extracted from the proprietary NVIDIA drivers).
For NVIDIA graphics with the proprietary drivers, the nvdec plugin (recently renamed nvh264dec) can be used for accelerated video decoding on the NVIDIA GPU with CUDA. The nvdec plugin is part of gstreamer1.0-plugins-bad, but is generally not included in binary packages, as NVIDIA’s proprietary Video Codec SDK must be downloaded, and three header files from it must be added to the gstreamer source before the plugin can be compiled. Users must do this themselves: see these instructions, and adapt them as necessary for your GStreamer installation. This plugin should be used with the -vd nvdec (or nvh264dec) and -vs glimagesink uxplay options.
The Raspberry Pi has a Broadcom GPU which is needed for hardware-accelerated h264 decoding, as UxPlay has unacceptible latency on the Pi when software decoding is used. The Pi has been supported by RPiPlay using omx (OpenMAX) drivers. These 32-bit drivers are deprecated, and were recently removed from Raspberry Pi OS (Bullseye). The designated replacement for OpenMAX is Video4linux2, and the options that should provide hardware decoding with UxPlay are -vd v4l2h264dec (best supplemented with -vc v4l2convert), which is a plugin from gstreamer1.0-plugins-good. Unfortunately, with this plugin GStreamer “caps negotiation” usually fails; a workaround has not yet been found. This is currently an open Issue. UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.
The Raspberry Pi has a Broadcom GPU which is needed for hardware-accelerated h264 decoding, as UxPlay has unacceptible latency on the Pi when software decoding is used. The Pi has been supported by RPiPlay using omx (OpenMAX) drivers. These 32-bit drivers are deprecated, and are unsupported on Raspberry Pi OS (Bullseye), though they can still be installed on the 32-bit version of the OS, allowing RPiPlay to still be used. The designated replacement for OpenMAX is Video4linux2, and the options that should provide GStreamerhardware decoding with UxPlay are -vd v4l2h264dec (best supplemented with -vc v4l2convert), which is a plugin from gstreamer1.0-plugins-good. Unfortunately, with this plugin GStreamer “caps negotiation” usually fails; a workaround has not yet been found. This is currently an open Issue. UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.
Some Linux distributions such as Debian do not allow distribution of compiled GPL code linked to OpenSSL-1.1.1 because its “dual OpenSSL/SSLeay” license has some incompatibilities with GPL, unless all code authors have explicitly given an “exception” to allow such linking (the historical origins of UxPlay make this impossible to obtain). Other distributions treat OpenSSL as a “System Library” which the GPL allows linking to.
For “GPL-strict” distributions, UxPlay can be built using OpenSSL- 3.0.0, which has a new GPLv3-compatible license.
diff --git a/README.md b/README.md index fc663fc..fe858a9 100644 --- a/README.md +++ b/README.md @@ -78,8 +78,9 @@ This plugin should be used with the `-vd nvdec` (or nvh264dec) and `-vs glimages The Raspberry Pi has a Broadcom GPU which is needed for hardware-accelerated h264 decoding, as UxPlay has unacceptible latency on the Pi when software decoding is used. The Pi has been supported by [RPiPlay](http://github.com/FD-/RPiPlay) using omx (OpenMAX) -drivers. These 32-bit drivers are deprecated, and were recently removed from Raspberry Pi OS (Bullseye). -The designated replacement for OpenMAX is Video4linux2, and the options that _should_ provide hardware decoding with UxPlay +drivers. These 32-bit drivers are deprecated, and are unsupported on Raspberry Pi OS (Bullseye), though they can still be installed on the +32-bit version of the OS, allowing RPiPlay to still be used. +The designated replacement for OpenMAX is Video4linux2, and the options that _should_ provide GStreamerhardware decoding with UxPlay are `-vd v4l2h264dec` (best supplemented with `-vc v4l2convert`), which is a plugin from gstreamer1.0-plugins-good. Unfortunately, with this plugin GStreamer "caps negotiation" usually fails; a workaround has not yet been found. This is currently diff --git a/README.txt b/README.txt index e55f2c7..d1cbfe3 100644 --- a/README.txt +++ b/README.txt @@ -104,13 +104,15 @@ The Raspberry Pi has a Broadcom GPU which is needed for hardware-accelerated h264 decoding, as UxPlay has unacceptible latency on the Pi when software decoding is used. The Pi has been supported by [RPiPlay](http://github.com/FD-/RPiPlay) using omx (OpenMAX) drivers. -These 32-bit drivers are deprecated, and were recently removed from -Raspberry Pi OS (Bullseye). The designated replacement for OpenMAX is -Video4linux2, and the options that *should* provide hardware decoding -with UxPlay are `-vd v4l2h264dec` (best supplemented with -`-vc v4l2convert`), which is a plugin from gstreamer1.0-plugins-good. -Unfortunately, with this plugin GStreamer "caps negotiation" usually -fails; a workaround has not yet been found. This is currently an open +These 32-bit drivers are deprecated, and are unsupported on Raspberry Pi +OS (Bullseye), though they can still be installed on the 32-bit version +of the OS, allowing RPiPlay to still be used. The designated replacement +for OpenMAX is Video4linux2, and the options that *should* provide +GStreamerhardware decoding with UxPlay are `-vd v4l2h264dec` (best +supplemented with `-vc v4l2convert`), which is a plugin from +gstreamer1.0-plugins-good. Unfortunately, with this plugin GStreamer +"caps negotiation" usually fails; a workaround has not yet been found. +This is currently an open [Issue](https://github.com/FDH2/UxPlay/issues/70). **UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.**