From 52ede494987c1e5ef1ad43507bfc0358ae416863 Mon Sep 17 00:00:00 2001 From: fduncanh Date: Thu, 24 Feb 2022 03:50:46 -0500 Subject: [PATCH] README edits --- README.html | 4 ++-- README.md | 8 +++++--- README.txt | 6 ++++-- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/README.html b/README.html index ccb68f6..744abcf 100644 --- a/README.html +++ b/README.html @@ -13,7 +13,7 @@

The UxPlay server and its client must be on the same local area network, on which a Bonjour/Zeroconf mDNS/DNS-SD server is also running (only DNS-SD “Service Discovery” service is strictly necessary, it is not necessary that the local network also be of the “.local” mDNS-based type). On Linux and BSD Unix servers, this is usually provided by Avahi, through the avahi-daemon service, and is included in most Linux distributions (this service can also be provided by macOS, iOS or Windows servers).

Connections to the UxPlay server by iOS/MacOS clients can be initiated both in AirPlay Mirror mode (which streams lossily-compressed AAC audio while mirroring the client screen, or in the alternative AirPlay Audio mode which streams Apple Lossless (ALAC) audio without screen mirroring (the accompanying metadata and cover art in this mode is not displayed). Switching between these two modes during an active connection is possible: in Mirror mode, close the mirror window and start an Audio mode connection, switch back by initiating a Mirror mode connection. Note that Apple DRM (as in Apple TV app content on the client) cannot be decrypted by UxPlay, and (unlike with a true AppleTV), the client cannot run a http connection on the server instead of streaming content from one on the client.

UxPlay uses GStreamer Plugins for rendering audio and video, and does not offer the alternative Raspberry-Pi-specific audio and video renderers available in RPiPlay. It is tested on a number of systems, including (among others) Debian 10.11 “Buster” and 11.2 “Bullseye”, Ubuntu 20.04 and 21.10, Linux Mint 20.2, Pop!_OS 21.10 (NVIDIA edition), Rocky Linux 8.5 (a CentOS successor), OpenSUSE 15.3, Arch Linux 5.16.8, macOS 10.15.7, FreeBSD 13.0.

-

Using Gstreamer means that video and audio are supported “out of the box”, using a choice of plugins. Gstreamer decoding is plugin agnostic, and uses accelerated decoders if available. For Intel integrated graphics, the VAAPI plugin is preferable. VAAPI is convenient for Intel and some AMD systems. For NVIDIA graphics, the proprietary nvdec (or nvh264dec) plugin can be used with the NVIDIA GPU if you manage to build and install it; v4l2h264dec would be the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, if you can get it working (UxPlay does not run well on the Raspberry PI if GPU hardware h264 decoding is not used, as its CPU is not powerful enough for satisfactory software h264 video decoding). The -vd, -vc, and -vs options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders.

+

Using Gstreamer means that video and audio are supported “out of the box”, using a choice of plugins. Gstreamer decoding is plugin agnostic, and uses accelerated decoders if available. For Intel integrated graphics, the VAAPI plugin is preferable. VAAPI is convenient for Intel and some AMD systems. For NVIDIA graphics, the proprietary nvdec (or nvh264dec) plugin can be used with the NVIDIA GPU if you manage to build and install it (it is part of GStreameter-plugins-bad, but the user must build them after adding some files from NVIDIA). The decoder v4l2h264dec (from GStreamer1.0-plugins-good) would be the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, if you can get it working (UxPlay does not run well on the Raspberry PI if GPU hardware h264 decoding is not used, as its CPU is not powerful enough for satisfactory software h264 video decoding). The -vd, -vc, and -vs options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders.

Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.

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.

@@ -79,7 +79,7 @@

Also: image transforms that had been added to RPiPlay have been ported to UxPlay:

-f {H|V|I} implements “videoflip” image transforms: H = horizontal flip (right-left flip, or mirror image); V = vertical flip ; I = 180 degree rotation or inversion (which is the combination of H with V).

-r {R|L} 90 degree Right (clockwise) or Left (counter-clockwise) rotations; these are carried out after any -f transforms.

-

-vd decoder chooses the GStreamer pipeline’s h264 decoder, instead of letting decodebin pick it for you. Software deconing is done by avdec_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes “…” allows some parameters to be included with the decoder name.

+

-vd decoder chooses the GStreamer pipeline’s h264 decoder, instead of letting decodebin pick it for you. Software decoding is done by avdec_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes “…” allows some parameters to be included with the decoder name.

-vc converter chooses the GStreamer pipeline’s videoconverter, instead of letting videoconvert choose what to do. When using video4linux hardware decoding by a GPU, v4l2convert will also use the GPU for video conversion. Using quotes “…” allows some parameters to be included with the converter name.

-vs videosink chooses the GStreamer videosink, instead of letting autovideosink pick it for you. Some videosink choices are: ximagesink, xvimagesink, vaapisink (for intel graphics), gtksink, glimagesink, waylandsink, osximagesink (for macOS), or fpsdisplaysink (which shows the streaming framerate in fps). Using quotes “…” allows some parameters to be included with the videosink name. For example, fullscreen mode is supported by the vaapisink plugin, and is obtained using -vs "vaapisink fullscreen=true"; this also works with waylandsink. The syntax of such options is specific to a given plugin, and some choices of videosink might not work on your system.

-vs 0 suppresses display of streamed video, but plays streamed audio. (The client’s screen is still mirrored at a reduced rate of 1 frame per second, but is not rendered or displayed.) This feature (which streams audio in AAC audio format) is now probably unneeded, as UxPlay can now stream superior-quality Apple Lossless audio without video in Airplay non-mirror mode.

diff --git a/README.md b/README.md index 71c31bf..fc541bd 100644 --- a/README.md +++ b/README.md @@ -60,8 +60,10 @@ Rocky Linux 8.5 (a CentOS successor), OpenSUSE 15.3, Arch Linux 5.16.8, macOS 10 Using Gstreamer means that video and audio are supported "out of the box", using a choice of plugins. Gstreamer decoding is plugin agnostic, and uses accelerated decoders if available. For Intel integrated graphics, the VAAPI plugin is preferable. VAAPI is convenient for Intel and some AMD systems. -For NVIDIA graphics, the proprietary nvdec (or nvh264dec) plugin can be used with the NVIDIA GPU if you manage to build and install it; v4l2h264dec -would be the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, if you can get it working (UxPlay +For NVIDIA graphics, the proprietary nvdec (or nvh264dec) plugin can be used with the NVIDIA GPU if you manage to build and install it (it is part of +GStreameter-plugins-bad, but the user must build them after adding some files from NVIDIA). +The decoder v4l2h264dec +(from GStreamer1.0-plugins-good) would be the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, if you can get it working (UxPlay does not run well on the Raspberry PI if GPU hardware h264 decoding is not used, as its CPU is not powerful enough for satisfactory software h264 video decoding). The -vd, -vc, and -vs options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders. @@ -320,7 +322,7 @@ Also: image transforms that had been added to RPiPlay have been ported to UxPlay rotations; these are carried out after any **-f** transforms. **-vd _decoder_** chooses the GStreamer pipeline's h264 decoder, instead of letting - decodebin pick it for you. Software deconing is done by avdec_h264; various hardware decoders + decodebin pick it for you. Software decoding is done by avdec_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes "..." allows some parameters to be included with the decoder name. diff --git a/README.txt b/README.txt index 294caf9..6078b41 100644 --- a/README.txt +++ b/README.txt @@ -78,7 +78,9 @@ and uses accelerated decoders if available. For Intel integrated graphics, the VAAPI plugin is preferable. VAAPI is convenient for Intel and some AMD systems. For NVIDIA graphics, the proprietary nvdec (or nvh264dec) plugin can be used with the NVIDIA GPU if you manage to build -and install it; v4l2h264dec would be the appropriate choice for the +and install it (it is part of GStreameter-plugins-bad, but the user must +build them after adding some files from NVIDIA). The decoder v4l2h264dec +(from GStreamer1.0-plugins-good) would be the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, if you can get it working (UxPlay does not run well on the Raspberry PI if GPU hardware h264 decoding is not used, as its CPU is not powerful enough for satisfactory software @@ -409,7 +411,7 @@ degree rotation or inversion (which is the combination of H with V). rotations; these are carried out after any **-f** transforms. **-vd *decoder*** chooses the GStreamer pipeline's h264 decoder, instead -of letting decodebin pick it for you. Software deconing is done by +of letting decodebin pick it for you. Software decoding is done by avdec\_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes "..." allows some parameters to be included