mirror of
https://github.com/morgan9e/UxPlay
synced 2026-04-14 00:04:13 +09:00
edit README
This commit is contained in:
@@ -14,9 +14,9 @@
|
||||
<p>Its main use is to act like an AppleTV for screen-mirroring (with audio) of iOS/iPadOS/macOS clients (iPhones, iPads, MacBooks) in a window on the server display (with the possibility of sharing that window on screen-sharing applications such as Zoom) on a host running Linux, macOS, or other unix. UxPlay supports a “legacy” form of Apple’s AirPlay Mirror protocol introduced in iOS 12; client devices running iOS/iPadOS 9.3.5 or later are supported, as is a (non-free) Windows-based AirPlay-client software emulator, AirMyPC. (Details of what is publically known about Apple’s AirPlay2 protocol can be found <a href="https://github.com/SteeBono/airplayreceiver/wiki/AirPlay2-Protocol">here</a> and <a href="https://emanuelecozzi.net/docs/airplay2">here</a>).</p>
|
||||
<p>The UxPlay server and its client must be on the same local area network, on which a <strong>Bonjour/Zeroconf mDNS/DNS-SD server</strong> 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 <a href="https://www.avahi.org">Avahi</a>, through the avahi-daemon service, and is included in most Linux distributions (this service can also be provided by macOS, iOS or Windows servers).</p>
|
||||
<p>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). <em>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.</em> <strong>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.</strong></p>
|
||||
<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. 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.</p>
|
||||
<p>For NVIDIA graphics with the proprietary drivers, the nvdec plugin (recently renamed nvh264dec) can be used with the NVIDIA GPU. This 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> The plugin should be used with the <code>-vd nvdec</code> (or nvh264dec) and <code>-vs glimagesink</code> uxplay options.</p>
|
||||
<p>The decoder v4l2h264dec (from GStreamer1.0-plugins-good) is the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, (UxPlay does not run well on the Raspberry Pi if GPU hardware h264 video decoding is not used, as its CPU is not powerful enough for satisfactory software-based decoding without large latency); uxplay options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders, and a special option <code>-rpi</code> creates a pipeline appropriate for the Raspberry Pi.</p>
|
||||
<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. Gstreamer decoding is plugin agnostic, and uses accelerated GPU decoders if available. For Intel integrated graphics, the VAAPI plugin is preferable. VAAPI is open-source, and supports some AMD systems, as well as INTEL, and open-source “Nouveau” NVIDIA drivers.</p>
|
||||
<p>For NVIDIA graphics with the proprietary drivers (and CUDA), the nvdec plugin (recently renamed nvh264dec) can be used for accelerated video decoding on the NVIDIA GPU. This 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> The plugin should be used with the <code>-vd nvdec</code> (or nvh264dec) and <code>-vs glimagesink</code> uxplay options.</p>
|
||||
<p>The Video4Linux2 decoder v4l2h264dec (from GStreamer1.0-plugins-good) is the appropriate choice for the Broadcom GPU in the Raspberry Pi 4, (UxPlay does not run well on the Raspberry Pi if GPU hardware h264 video decoding is not used, as its CPU is not powerful enough for satisfactory software-based decoding without large latency); uxplay options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders, and a special option <code>-rpi</code> creates a pipeline appropriate for the Raspberry Pi. <em>(This is “Work In Progess”, has worked, but not yet consistently.)</em></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>
|
||||
|
||||
Reference in New Issue
Block a user