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

edits to README

Browse Source
This commit is contained in:
fduncanh
2022-03-03 02:03:01 -05:00
parent a467fe7858
commit 80052546e1
3 changed files with 22 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.html
View File

@@ -18,9 +18,7 @@
<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>
<ul>
<li><strong>possible support for Raspberry Pi</strong> (<em>not working</em>): the CPU of the Raspberry Pi is not powerful enough for GStreamer to decode the h264 video stream using software decoding (option <code>-avdec</code> ) without unacceptable latency. The Pi has a Broadcom GPU for accelerated hardware h264 decoding, and in the past this has been supported by <a href="https://github.com/FD-/RPiPlay">RPiPlay</a> using the deprecated 32-bit omx (OpenMax) driver. Unfortunately, with the move to a 64-bit OS, this has been removed from recent Raspberry Pi OS (Bullseye), and there has been user interest in making UxPlay work on the Pi. The designated replacement for OpenMAX is Video4linux2, and the options that <em>should</em> work with UxPlay are <code>-vd v4l2h264dec -vc v4l2convert</code>, which are from gstreamer1.0-plugins-good. This has occasionally worked, and when it did, it worked well, with no appreciable latency. Unfortunately, the v4l2h264dec GStreamer plugin usually fails to match the “caps” (capacities) of the h264 source to the videosink, and h264 hardware decoding fails. It is not clear whether there is any workaround before an updated v4l2h264dec plugin becomes available. GStreamer-knowledgeable users who wish to experiment can see if any video pipeline modifications can provide a workaround: the pipeline is <code>(video stream from appsrc) ... ! h264parse ! decodebin ! videoconvert ! autovideosink ...</code>; the elements h264parse, decodebin, videoconvert, and autovideosink can respectively be modified with options -vp, -vd, -vc, and -vs. Please report any successes! (See <a href="https://github.com/raspberrypi/firmware/issues/1673">this</a>, which suggests some workaround involving “capssetter” might be possible; <code>export GST_DEBUG=GST_CAPS:5</code> may be useful in debugging the pipeline.)</li>
</ul>
<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 were recently removed from Raspberry Pi OS (Bullseye). The designated replacement for OpenMAX is Video4linux2, and the options that <em>should</em> provide 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>. ** UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.**</p>
<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>

24
README.md
View File

@@ -76,22 +76,14 @@ 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.
* **possible support for Raspberry Pi** (_not working_): the CPU of the Raspberry Pi is not powerful
enough for GStreamer to decode the h264 video stream using software decoding (option `-avdec` ) without unacceptable latency.
The Pi has a Broadcom GPU for accelerated hardware h264 decoding, and in the past this has been
supported by [RPiPlay](https://github.com/FD-/RPiPlay) using the deprecated 32-bit omx (OpenMax) driver. Unfortunately, with the move
to a 64-bit OS, this has been removed from recent Raspberry Pi OS (Bullseye), and there has been user interest in making UxPlay work on the Pi.
The designated replacement for OpenMAX is Video4linux2, and the options that
_should_ work with UxPlay are `-vd v4l2h264dec -vc v4l2convert`, which are from gstreamer1.0-plugins-good.
This has occasionally worked, and when it did, it worked well, with no
appreciable latency. Unfortunately, the v4l2h264dec GStreamer plugin usually fails to match the "caps" (capacities) of the h264
source to the videosink, and h264 hardware decoding fails. It is
not clear whether there is any workaround before an updated v4l2h264dec plugin becomes available. GStreamer-knowledgeable users
who wish to experiment can see if any video pipeline modifications can provide a workaround:
the pipeline is ` (video stream from appsrc) ... ! h264parse ! decodebin ! videoconvert ! autovideosink ... `; the elements h264parse,
decodebin, videoconvert, and autovideosink can respectively be modified with options -vp, -vd, -vc, and -vs. Please report any successes!
(See [this](https://github.com/raspberrypi/firmware/issues/1673), which suggests some workaround involving "capssetter" might be possible;
`export GST_DEBUG=GST_CAPS:5` may be useful in debugging the pipeline.)
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 [Issue](https://github.com/FDH2/UxPlay/issues/70). ** UxPlay support for the Pi may need to wait for a fix to the v4l2 plugin.**
### Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.

42
README.txt
View File

@@ -100,35 +100,19 @@ 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.
- **possible support for Raspberry Pi** (*not working*): the CPU of
the Raspberry Pi is not powerful enough for GStreamer to decode the
h264 video stream using software decoding (option `-avdec` ) without
unacceptable latency. The Pi has a Broadcom GPU for accelerated
hardware h264 decoding, and in the past this has been supported by
[RPiPlay](https://github.com/FD-/RPiPlay) using the deprecated
32-bit omx (OpenMax) driver. Unfortunately, with the move to a
64-bit OS, this has been removed from recent Raspberry Pi OS
(Bullseye), and there has been user interest in making UxPlay work
on the Pi. The designated replacement for OpenMAX is Video4linux2,
and the options that *should* work with UxPlay are
`-vd v4l2h264dec -vc v4l2convert`, which are from
gstreamer1.0-plugins-good. This has occasionally worked, and when it
did, it worked well, with no appreciable latency. Unfortunately, the
v4l2h264dec GStreamer plugin usually fails to match the "caps"
(capacities) of the h264 source to the videosink, and h264 hardware
decoding fails. It is not clear whether there is any workaround
before an updated v4l2h264dec plugin becomes available.
GStreamer-knowledgeable users who wish to experiment can see if any
video pipeline modifications can provide a workaround: the pipeline
is
`(video stream from appsrc) ... ! h264parse ! decodebin ! videoconvert ! autovideosink ...`;
the elements h264parse, decodebin, videoconvert, and autovideosink
can respectively be modified with options -vp, -vd, -vc, and
-vs. Please report any successes! (See
[this](https://github.com/raspberrypi/firmware/issues/1673), which
suggests some workaround involving "capssetter" might be possible;
`export GST_DEBUG=GST_CAPS:5` may be useful in debugging the
pipeline.)
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
[Issue](https://github.com/FDH2/UxPlay/issues/70). \*\* UxPlay support
for the Pi may need to wait for a fix to the v4l2 plugin.\*\*
### Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.