morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

update README about R Pi

Browse Source
This commit is contained in:
fduncanh
2022-03-07 11:17:16 -05:00
parent f950e0efa3
commit 605f899a3f
3 changed files with 35 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
README.html
View File

@@ -18,7 +18,10 @@
<p>UxPlay uses <a href="https://gstreamer.freedesktop.org">GStreamer</a> 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.</p>
<p>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).</p>
<p>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 <a href="https://docs.nvidia.com/video-technologies/video-codec-sdk/nvdec-video-decoder-api-prog-guide/">Video Codec SDK</a> 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 <a href="https://gist.github.com/corenel/a615b6f7eb5b5425aa49343a7b409200">these instructions</a>, and adapt them as necessary for your GStreamer installation. This plugin should be used with the <code>-vd nvdec</code> (or nvh264dec) and <code>-vs glimagesink</code> uxplay options.</p>
<p>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 <a href="http://github.com/FD-/RPiPlay">RPiPlay</a> 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 <em>should</em> provide GStreamer hardware decoding with UxPlay are <code>-vd v4l2h264dec</code> (best supplemented with <code>-vc v4l2convert</code>), 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 <a href="https://github.com/FDH2/UxPlay/issues/70">Issue</a>. <strong>UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.</strong></p>
<ul>
<li><p><strong>Support for Raspberry Pi (not yet).</strong></p>
<p>The Raspberry Pi (e.g, model 4B) is powerful enough to run UxPlay, but only with hardware-accelerated h264 decoding by its Broadcom GPU (software decoding with uxplay option <code>-avdec</code> works, but with unacceptible latency). Raspberry Pi OS (Bullseye) has abandoned the omx (OpenMAX) GPU driver used by <a href="http://github.com/FD-/RPiPlay">RPiPlay</a>, and the corresponding GStreamer plugin omxh264dec has been deprecated and broken for some time. The replacement is the Video4Linux (v4l2) plugin v4l2h264dec from gstreamer1.0-plugins-good, which works well for playing mp4 files on the Pi. Unfortunately, features needed by UxPlay are currently broken in this plugin, see the open <a href="https://github.com/FDH2/UxPlay/issues/70">Issue</a>. The (undocumented) UxPlay option <code>-rpi</code> will use the Pi’s GPU for video decoding, but will only work when an updated v4l2h264dec plugin becomes available. There is now work on this in the GStreamer development cycle: hopefully this might get backported to GStreamer-1.18 or 1.20 for the Pi, otherwise it will appear in v1.22.</p></li>
</ul>
<h3 id="note-to-packagers-openssl-3.0.0-solves-gpl-v3-license-issues.">Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.</h3>
<p>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.</p>
<p>For “GPL-strict” distributions, UxPlay can be built using OpenSSL- 3.0.0, which has a new <a href="https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/">GPLv3-compatible license</a>.</p>

20
README.md
View File

@@ -76,15 +76,17 @@ Users must do this themselves: see [these instructions](https://gist.github.com/
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](http://github.com/FD-/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 GStreamer 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](https://github.com/FDH2/UxPlay/issues/70). **UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.**
* **Support for Raspberry Pi (not yet).**
The Raspberry Pi (e.g, model 4B) is powerful enough to run UxPlay, but only with hardware-accelerated h264 decoding by
its Broadcom GPU (software decoding with uxplay option `-avdec` works, but with unacceptible latency). Raspberry Pi OS (Bullseye)
has abandoned the omx (OpenMAX) GPU driver used by [RPiPlay](http://github.com/FD-/RPiPlay), and the corresponding
GStreamer plugin omxh264dec has been deprecated and broken for some time. The replacement is the Video4Linux (v4l2) plugin
v4l2h264dec from gstreamer1.0-plugins-good, which works well for playing mp4 files on the Pi. Unfortunately, features needed
by UxPlay are currently broken in this plugin, see the open [Issue](https://github.com/FDH2/UxPlay/issues/70). The (undocumented)
UxPlay option `-rpi` will use the Pi's GPU for video decoding, but will only work when an updated v4l2h264dec plugin becomes available.
There is now work on this in the GStreamer development cycle: hopefully this might get backported to GStreamer-1.18 or 1.20 for the Pi,
otherwise it will appear in v1.22.
### Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.

35
README.txt
View File

@@ -100,21 +100,26 @@ 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](http://github.com/FD-/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
GStreamer 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](https://github.com/FDH2/UxPlay/issues/70). **UxPlay support for
the Pi may need to wait for a fix to the v4l2 plugin.**
- **Support for Raspberry Pi (not yet).**
The Raspberry Pi (e.g, model 4B) is powerful enough to run UxPlay,
but only with hardware-accelerated h264 decoding by its Broadcom GPU
(software decoding with uxplay option `-avdec` works, but with
unacceptible latency). Raspberry Pi OS (Bullseye) has abandoned the
omx (OpenMAX) GPU driver used by
[RPiPlay](http://github.com/FD-/RPiPlay), and the corresponding
GStreamer plugin omxh264dec has been deprecated and broken for some
time. The replacement is the Video4Linux (v4l2) plugin v4l2h264dec
from gstreamer1.0-plugins-good, which works well for playing mp4
files on the Pi. Unfortunately, features needed by UxPlay are
currently broken in this plugin, see the open
[Issue](https://github.com/FDH2/UxPlay/issues/70). The
(undocumented) UxPlay option `-rpi` will use the Pi's GPU for video
decoding, but will only work when an updated v4l2h264dec plugin
becomes available. There is now work on this in the GStreamer
development cycle: hopefully this might get backported to
GStreamer-1.18 or 1.20 for the Pi, otherwise it will appear in
v1.22.
### Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.