{"id":13561118,"url":"https://github.com/FDH2/UxPlay","last_synced_at":"2025-04-03T16:32:08.384Z","repository":{"id":37317032,"uuid":"391476365","full_name":"FDH2/UxPlay","owner":"FDH2","description":"AirPlay Unix mirroring server","archived":false,"fork":true,"pushed_at":"2025-03-31T18:03:14.000Z","size":3539,"stargazers_count":1882,"open_issues_count":10,"forks_count":91,"subscribers_count":15,"default_branch":"master","last_synced_at":"2025-03-31T19:23:25.326Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"antimof/UxPlay","license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/FDH2.png","metadata":{"files":{"readme":"README.html","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2021-07-31T22:41:15.000Z","updated_at":"2025-03-31T18:47:58.000Z","dependencies_parsed_at":"2023-09-26T09:52:51.534Z","dependency_job_id":null,"html_url":"https://github.com/FDH2/UxPlay","commit_stats":null,"previous_names":[],"tags_count":100,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/FDH2%2FUxPlay","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/FDH2%2FUxPlay/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/FDH2%2FUxPlay/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/FDH2%2FUxPlay/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/FDH2","download_url":"https://codeload.github.com/FDH2/UxPlay/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247037107,"owners_count":20873097,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T13:00:52.708Z","updated_at":"2025-04-03T16:32:03.376Z","avatar_url":"https://github.com/FDH2.png","language":"C","funding_links":[],"categories":["C","HarmonyOS","Useful"],"sub_categories":["Windows Manager"],"readme":"\u003ch1\nid=\"uxplay-1.70-airplay-mirror-and-airplay-audio-server-for-linux-macos-and-unix-now-also-runs-on-windows.\"\u003eUxPlay\n1.70: AirPlay-Mirror and AirPlay-Audio server for Linux, macOS, and Unix\n(now also runs on Windows).\u003c/h1\u003e\n\u003ch3\nid=\"now-developed-at-the-github-site-httpsgithub.comfdh2uxplay-where-all-user-issues-should-be-posted-and-latest-versions-can-be-found.\"\u003e\u003cstrong\u003eNow\ndeveloped at the GitHub site \u003ca\nhref=\"https://github.com/FDH2/UxPlay\"\u003ehttps://github.com/FDH2/UxPlay\u003c/a\u003e\n(where ALL user issues should be posted, and latest versions can be\nfound).\u003c/strong\u003e\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cem\u003e\u003cstrong\u003eNEW in v1.70\u003c/strong\u003e: Support for 4k (h265) video with\nthe new “-h265” option.\u003c/em\u003e (Recent Apple devices will send HEVC (h265)\nvideo in AirPlay mirror mode if larger resolutions (\u003cem\u003eh\u003c/em\u003e \u0026gt;\n1080) are requested with UxPlay’s “-s wxh” option; wired ethernet\nconnection is prefered to wireless in this mode, and may also be\nrequired by the client; the “-h265” option changes the default\nresolution from 1920x1080 to 3840x2160, but leaves default maximum\nframerate (“-fps” option) at 30fps.)\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights:\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eGPLv3, open source.\u003c/li\u003e\n\u003cli\u003eOriginally supported only AirPlay Mirror protocol, now has added\nsupport for AirPlay Audio-only (Apple Lossless ALAC) streaming from\ncurrent iOS/iPadOS clients. \u003cstrong\u003eThere is no current support for\nAirplay HLS video-streaming (e.g., YouTube video) but this is in\ndevelopment.\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003emacOS computers (2011 or later, both Intel and “Apple Silicon” M1/M2\nsystems) can act either as AirPlay clients, or as the server running\nUxPlay. Using AirPlay, UxPlay can emulate a second display for macOS\nclients.\u003c/li\u003e\n\u003cli\u003eSupport for older iOS clients (such as 32-bit iPad 2nd gen., iPod\nTouch 5th gen. and iPhone 4S, when upgraded to iOS 9.3.5, or later\n64-bit devices), plus a Windows AirPlay-client emulator, AirMyPC.\u003c/li\u003e\n\u003cli\u003eUses GStreamer plugins for audio and video rendering (with options\nto select different hardware-appropriate output “videosinks” and\n“audiosinks”, and a fully-user-configurable video streaming\npipeline).\u003c/li\u003e\n\u003cli\u003eSupport for server behind a firewall.\u003c/li\u003e\n\u003cli\u003eRaspberry Pi support \u003cstrong\u003eboth with and without hardware video\ndecoding\u003c/strong\u003e by the Broadcom GPU. \u003cem\u003eTested on Raspberry Pi Zero 2\nW, 3 Model B+, 4 Model B, and 5.\u003c/em\u003e\u003c/li\u003e\n\u003cli\u003eSupport for running on Microsoft Windows (builds with the MinGW-64\ncompiler in the unix-like MSYS2 environment).\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNote: AirPlay2 multi-room audio streaming is not supported: use \u003ca\nhref=\"https://github.com/mikebrady/shairport-sync\"\u003eshairport-sync\u003c/a\u003e\nfor that.\u003c/p\u003e\n\u003ch2 id=\"packaging-status-linux-and-bsd-distributions\"\u003ePackaging status\n(Linux and *BSD distributions)\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://repology.org/project/uxplay/versions\"\u003e\u003cimg\nsrc=\"https://repology.org/badge/vertical-allrepos/uxplay.svg\"\nalt=\"Current Packaging status\" /\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eInstall uxplay on Debian-based Linux systems with\n“\u003ccode\u003esudo apt install uxplay\u003c/code\u003e”; on FreeBSD with\n“\u003ccode\u003esudo pkg install uxplay\u003c/code\u003e”. Also available on Arch-based\nsystems through AUR. Since v. 1.66, uxplay is now also packaged in RPM\nformat by Fedora 38 (“\u003ccode\u003esudo dnf install uxplay\u003c/code\u003e”).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eFor other RPM-based distributions which have not yet packaged\nUxPlay, a RPM “specfile” \u003cstrong\u003euxplay.spec\u003c/strong\u003e is now provided\nwith recent \u003ca\nhref=\"https://github.com/FDH2/UxPlay/releases\"\u003ereleases\u003c/a\u003e (see their\n“Assets”), and can also be found in the UxPlay source top directory. See\nthe section on using this specfile for \u003ca\nhref=\"#building-an-installable-rpm-package\"\u003ebuilding an installable RPM\npackage\u003c/a\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAfter installation:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e(On Linux and *BSD): if a firewall is active on the server\nhosting UxPlay, make sure the default network port (UDP 5353) for\nmDNS/DNS-SD queries is open (see \u003ca\nhref=\"#troubleshooting\"\u003eTroubleshooting\u003c/a\u003e below for more details);\nalso open three UDP and three TCP ports for Uxplay, and use the “uxplay\n-p \u003cn\u003e” option (see “\u003ccode\u003eman uxplay\u003c/code\u003e” or\n“\u003ccode\u003euxplay -h\u003c/code\u003e”).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eEven if you install your distribution’s pre-compiled uxplay\nbinary package, you may need to read the instructions below for \u003ca\nhref=\"#running-uxplay\"\u003erunning UxPlay\u003c/a\u003e to see which of your\ndistribution’s \u003cstrong\u003eGStreamer plugin packages\u003c/strong\u003e you should\nalso install.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eFor Audio-only mode (Apple Music, etc.) best quality is obtained\nwith the option “uxplay -async”, but there is then a 2 second latency\nimposed by iOS.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eAdd any UxPlay options you want to use as defaults to a startup\nfile \u003ccode\u003e~/.uxplayrc\u003c/code\u003e (see “\u003ccode\u003eman uxplay\u003c/code\u003e” or\n“\u003ccode\u003euxplay -h\u003c/code\u003e” for format and other possible locations). In\nparticular, if your system uses PipeWire audio or Wayland video systems,\nyou may wish to add “as pipewiresink” or “vs waylandsink” as defaults to\nthe file. \u003cem\u003e(Output from terminal commands “ps waux | grep pulse” or\n“pactl info” will contain “pipewire” if your Linux/BSD system uses\nit).\u003c/em\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eOn Raspberry Pi: If you use Ubuntu 22.10 or earlier, GStreamer\nmust be \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches\"\u003epatched\u003c/a\u003e\nto use hardware video decoding by the Broadcom GPU (also recommended but\noptional for Raspberry Pi OS (Bullseye): use option\n“\u003ccode\u003euxplay -bt709\u003c/code\u003e” if you do not use the patch).\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTo (easily) compile the latest UxPlay from source, see the section \u003ca\nhref=\"#getting-uxplay\"\u003eGetting UxPlay\u003c/a\u003e.\u003c/p\u003e\n\u003ch1 id=\"detailed-description-of-uxplay\"\u003eDetailed description of\nUxPlay\u003c/h1\u003e\n\u003cp\u003eThis project is a GPLv3 open source unix AirPlay2 Mirror server for\nLinux, macOS, and *BSD. It was initially developed by \u003ca\nhref=\"http://github.com/antimof/Uxplay\"\u003eantimof\u003c/a\u003e using code from\nOpenMAX-based \u003ca href=\"https://github.com/FD-/RPiPlay\"\u003eRPiPlay\u003c/a\u003e,\nwhich in turn derives from \u003ca\nhref=\"https://github.com/KqsMea8/AirplayServer\"\u003eAirplayServer\u003c/a\u003e, \u003ca\nhref=\"https://github.com/juhovh/shairplay\"\u003eshairplay\u003c/a\u003e, and \u003ca\nhref=\"https://github.com/EstebanKubata/playfair\"\u003eplayfair\u003c/a\u003e. (The\nantimof site is no longer involved in development, but periodically\nposts updates pulled from the new main \u003ca\nhref=\"https://github.com/FDH2/UxPlay\"\u003eUxPlay site\u003c/a\u003e).\u003c/p\u003e\n\u003cp\u003eUxPlay is tested on a number of systems, including (among others)\nDebian (10 “Buster”, 11 “Bullseye”, 12 “Bookworm”), Ubuntu (20.04 LTS,\n22.04 LTS, 23.04 (also Ubuntu derivatives Linux Mint, Pop!_OS), Red Hat\nand clones (Fedora 38, Rocky Linux 9.2), openSUSE Leap 15.5, Mageia 9,\nOpenMandriva “ROME”, PCLinuxOS, Arch Linux, Manjaro, and should run on\nany Linux system. Also tested on macOS Catalina and Ventura (Intel) and\nSonoma (M2), FreeBSD 14.0, Windows 10 and 11 (64 bit).\u003c/p\u003e\n\u003cp\u003eOn Raspberry Pi 4 model B, it is tested on Raspberry Pi OS (Bullseye\nand Bookworm) (32- and 64-bit), Ubuntu 22.04 LTS and 23.04, Manjaro RPi4\n23.02, and (without hardware video decoding) on openSUSE 15.5. Also\ntested on Raspberry Pi Zero 2 W, 3 model B+, and now 5.\u003c/p\u003e\n\u003cp\u003eIts main use is to act like an AppleTV for screen-mirroring (with\naudio) of iOS/iPadOS/macOS clients (iPhone, iPod Touch, iPad, Mac\ncomputers) on the server display of a host running Linux, macOS, or\nother unix (and now also Microsoft Windows). UxPlay supports Apple’s\nAirPlay2 protocol using “Legacy Protocol”, but some features are\nmissing. (Details of what is publicly known about Apple’s AirPlay 2\nprotocol can be found \u003ca\nhref=\"https://openairplay.github.io/airplay-spec/\"\u003ehere\u003c/a\u003e, \u003ca\nhref=\"https://github.com/SteeBono/airplayreceiver/wiki/AirPlay2-Protocol\"\u003ehere\u003c/a\u003e\nand \u003ca href=\"https://emanuelecozzi.net/docs/airplay2\"\u003ehere\u003c/a\u003e; see also\n\u003ca href=\"https://pyatv.dev/documentation/protocols\"\u003epyatv\u003c/a\u003e which\ncould be a resource for adding modern protocols.) While there is no\nguarantee that future iOS releases will keep supporting “Legacy\nProtocol”, iOS 17 continues support.\u003c/p\u003e\n\u003cp\u003eThe UxPlay server and its client must be on the same local area\nnetwork, on which a \u003cstrong\u003eBonjour/Zeroconf mDNS/DNS-SD server\u003c/strong\u003e\nis also running (only DNS-SD “Service Discovery” service is strictly\nnecessary, it is not necessary that the local network also be of the\n“.local” mDNS-based type). On Linux and BSD Unix servers, this is\nusually provided by \u003ca href=\"https://www.avahi.org\"\u003eAvahi\u003c/a\u003e, through\nthe avahi-daemon service, and is included in most Linux distributions\n(this service can also be provided by macOS, iOS or Windows\nservers).\u003c/p\u003e\n\u003cp\u003eConnections to the UxPlay server by iOS/MacOS clients can be\ninitiated both in \u003cstrong\u003eAirPlay Mirror\u003c/strong\u003e mode (which streams\nlossily-compressed AAC audio while mirroring the client screen, or in\nthe alternative \u003cstrong\u003eAirPlay Audio\u003c/strong\u003e mode which streams Apple\nLossless (ALAC) audio without screen mirroring. In\n\u003cstrong\u003eAudio\u003c/strong\u003e mode, metadata is displayed in the uxplay\nterminal; if UxPlay option \u003ccode\u003e-ca \u0026lt;name\u0026gt;\u003c/code\u003e is used, the\naccompanying cover art is also output to a periodically-updated file\n\u003ccode\u003e\u0026lt;name\u0026gt;\u003c/code\u003e, and can be viewed with a (reloading) graphics\nviewer of your choice. \u003cem\u003eSwitching between\u003c/em\u003e\n\u003cstrong\u003eMirror\u003c/strong\u003e \u003cem\u003eand\u003c/em\u003e \u003cstrong\u003eAudio\u003c/strong\u003e \u003cem\u003emodes\nduring an active connection is possible: in\u003c/em\u003e \u003cstrong\u003eMirror\u003c/strong\u003e\n\u003cem\u003emode, stop mirroring (or close the mirror window) and start an\u003c/em\u003e\n\u003cstrong\u003eAudio\u003c/strong\u003e \u003cem\u003emode connection, switch back by initiating\na\u003c/em\u003e \u003cstrong\u003eMirror\u003c/strong\u003e \u003cem\u003emode connection; cover-art display\nstops/restarts as you leave/re-enter\u003c/em\u003e \u003cstrong\u003eAudio\u003c/strong\u003e\n\u003cem\u003emode.\u003c/em\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eNote that Apple video-DRM (as found in “Apple TV app”\ncontent on the client) cannot be decrypted by UxPlay, and the Apple TV\napp cannot be watched using UxPlay’s AirPlay Mirror mode (only the\nunprotected audio will be streamed, in AAC format), but both video and\naudio content from DRM-free apps like “YouTube app” will be streamed by\nUxPlay in Mirror mode.\u003c/strong\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eAs UxPlay does not currently support non-Mirror AirPlay\nvideo streaming (where the client controls a web server on the AirPlay\nserver that directly receives HLS content to avoid it being decoded and\nre-encoded by the client), using the icon for AirPlay video in apps such\nas the YouTube app will only send audio (in lossless ALAC format)\nwithout the accompanying video (there are plans to support HLS video in\nfuture releases of UxPlay)\u003c/strong\u003e\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\nid=\"possibility-for-using-hardware-accelerated-h264h265-video-decoding-if-available.\"\u003ePossibility\nfor using hardware-accelerated h264/h265 video-decoding, if\navailable.\u003c/h3\u003e\n\u003cp\u003eUxPlay uses \u003ca href=\"https://gstreamer.freedesktop.org\"\u003eGStreamer\u003c/a\u003e\n“plugins” for rendering audio and video. This means that video and audio\nare supported “out of the box”, using a choice of plugins. AirPlay\nstreams video in h264 format: gstreamer decoding is plugin agnostic, and\nuses accelerated GPU hardware h264 decoders if available; if not,\nsoftware decoding is used.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eVAAPI for Intel and AMD integrated graphics, NVIDIA with\n“Nouveau” open-source driver\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWith an Intel or AMD GPU, hardware decoding with the open-source\nVAAPI gstreamer plugin is preferable. The open-source “Nouveau” drivers\nfor NVIDIA graphics are also in principle supported: see \u003ca\nhref=\"https://nouveau.freedesktop.org/VideoAcceleration.html\"\u003ehere\u003c/a\u003e,\nbut this requires VAAPI to be supplemented with firmware extracted from\nthe proprietary NVIDIA drivers.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eNVIDIA with proprietary drivers\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003envh264dec\u003c/code\u003e plugin (included in\ngstreamer1.0-plugins-bad since GStreamer-1.18.0) can be used for\naccelerated video decoding on the NVIDIA GPU after NVIDIA’s CUDA driver\n\u003ccode\u003elibcuda.so\u003c/code\u003e is installed. For GStreamer-1.16.3 or earlier,\nthe plugin is called \u003ccode\u003envdec\u003c/code\u003e, and must be \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/NVIDIA-nvdec-and-nvenc-plugins\"\u003ebuilt\nby the user\u003c/a\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eVideo4Linux2 support for h264 hardware decoding on\nRaspberry Pi (Pi 4B and older)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eRaspberry Pi (RPi) computers (tested on Pi 4 Model B) can now run\nUxPlay using software video decoding, but hardware-accelerated h264/h265\ndecoding by firmware in the Pi’s Broadcom 2835 GPU is prefered. UxPlay\naccesses this using the GStreamer-1.22 Video4Linux2 (v4l2) plugin; Uses\nthe out-of-mainline Linux kernel module bcm2835-codec maintained by\nRaspberry Pi, so far only included in Raspberry Pi OS, and two other\ndistributions (Ubuntu, Manjaro) available with Raspberry Pi Imager.\n\u003cem\u003e(For GStreamer \u0026lt; 1.22, see the \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches\"\u003eUxPlay\nWiki\u003c/a\u003e)\u003c/em\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003e(New): Support for h265 (HEVC) hardware decoding on\nRaspberry Pi (Pi 4 model B and Pi 5)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSupport is present, but so far satisfactory results have not been\nobtained. Pi model 5 only provides hardware-accelerated (GPU) decoding\nfor h265 video, but not H264, as its CPU is powerful enough for\nsatisfactory software H264 decoding\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"note-to-packagers\"\u003eNote to packagers:\u003c/h3\u003e\n\u003cp\u003eUxPlay’s GPLv3 license does not have an added “GPL exception”\nexplicitly allowing it to be distributed in compiled form when linked to\nOpenSSL versions \u003cstrong\u003eprior to v. 3.0.0\u003c/strong\u003e (older versions of\nOpenSSL have a license clause incompatible with the GPL unless OpenSSL\ncan be regarded as a “System Library”, which it is in *BSD). Many Linux\ndistributions treat OpenSSL as a “System Library”, but some\n(e.g. Debian) do not: in this case, the issue is solved by linking with\nOpenSSL-3.0.0 or later.\u003c/p\u003e\n\u003ch1 id=\"getting-uxplay\"\u003eGetting UxPlay\u003c/h1\u003e\n\u003cp\u003eEither download and unzip \u003ca\nhref=\"https://github.com/FDH2/UxPlay/archive/refs/heads/master.zip\"\u003eUxPlay-master.zip\u003c/a\u003e,\nor (if git is installed): “git clone https://github.com/FDH2/UxPlay”.\nYou can also download a recent or earlier version listed in \u003ca\nhref=\"https://github.com/FDH2/UxPlay/releases\"\u003eReleases\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA recent UxPlay can also be found on the original \u003ca\nhref=\"https://github.com/antimof/UxPlay\"\u003eantimof site\u003c/a\u003e; that original\nproject is inactive, but is usually kept current or almost-current with\nthe \u003ca href=\"https://github.com/FDH2/UxPlay\"\u003eactive UxPlay github\nsite\u003c/a\u003e (thank you antimof!).\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"building-uxplay-on-linux-or-bsd\"\u003eBuilding UxPlay on Linux (or\n*BSD):\u003c/h2\u003e\n\u003ch3 id=\"debian-based-systems\"\u003eDebian-based systems:\u003c/h3\u003e\n\u003cp\u003e(Adapt these instructions for non-Debian-based Linuxes or *BSD; for\nmacOS, see specific instruction below). See \u003ca\nhref=\"#troubleshooting\"\u003eTroubleshooting\u003c/a\u003e below for help with any\ndifficulties.\u003c/p\u003e\n\u003cp\u003eYou need a C/C++ compiler (e.g. g++) with the standard development\nlibraries installed. Debian-based systems provide a package\n“build-essential” for use in compiling software. You also need\npkg-config: if it is not found by “\u003ccode\u003ewhich pkg-config\u003c/code\u003e”,\ninstall pkg-config or its work-alike replacement pkgconf. Also make sure\nthat cmake\u0026gt;=3.5 is installed: “\u003ccode\u003esudo apt install cmake\u003c/code\u003e”\n(add \u003ccode\u003ebuild-essential\u003c/code\u003e and \u003ccode\u003epkg-config\u003c/code\u003e (or\n\u003ccode\u003epkgconf\u003c/code\u003e) to this if needed).\u003c/p\u003e\n\u003cp\u003eMake sure that your distribution provides OpenSSL 1.1.1 or later, and\nlibplist 2.0 or later. (This means Debian 10 “Buster” based systems\n(e.g, Ubuntu 18.04) or newer; on Debian 10 systems “libplist” is an\nolder version, you need “libplist3”.) If it does not, you may need to\nbuild and install these from source (see instructions at the end of this\nREADME).\u003c/p\u003e\n\u003cp\u003eIf you have a non-standard OpenSSL installation, you may need to set\nthe environment variable OPENSSL_ROOT_DIR (\u003cem\u003ee.g.\u003c/em\u003e ,\n“\u003ccode\u003eexport OPENSSL_ROOT_DIR=/usr/local/lib64\u003c/code\u003e” if that is where\nit is installed). Similarly, for non-standard (or multiple) GStreamer\ninstallations, set the environment variable GSTREAMER_ROOT_DIR to the\ndirectory that contains the “…/gstreamer-1.0/” directory of the\ngstreamer installation that UxPlay should use (if this is \u003cem\u003ee.g.\u003c/em\u003e\n“~/my_gstreamer/lib/gstreamer-1.0/”, set this location with\n“\u003ccode\u003eexport GSTREAMER_ROOT_DIR=$HOME/my_gstreamer/lib\u003c/code\u003e”).\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMost users will use the GStreamer supplied by their distribution,\nbut a few (in particular users of Raspberry Pi OS Lite Legacy (Buster)\non a Raspberry Pi model 4B who wish to stay on that unsupported Legacy\nOS for compatibility with other apps) should instead build a newer\nGstreamer from source following \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Building-latest-GStreamer-from-source-on-distributions-with-older-GStreamer-(e.g.-Raspberry-Pi-OS-).\"\u003ethese\ninstructions\u003c/a\u003e . \u003cstrong\u003eDo this \u003cem\u003ebefore\u003c/em\u003e building\nUxPlay\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn a terminal window, change directories to the source directory of\nthe downloaded source code (“UxPlay-*”, “*” = “master” or the release\ntag for zipfile downloads, “UxPlay” for “git clone” downloads), then\nfollow the instructions below:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e By default UxPlay will be built with\noptimization for the computer it is built on; when this is not the case,\nas when you are packaging for a distribution, use the cmake option\n\u003ccode\u003e-DNO_MARCH_NATIVE=ON\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIf you use X11 Windows on Linux or *BSD, and wish to toggle in/out of\nfullscreen mode with a keypress (F11 or Alt_L+Enter) UxPlay needs to be\nbuilt with a dependence on X11. Starting with UxPlay-1.59, this will be\ndone by default \u003cstrong\u003eIF\u003c/strong\u003e the X11 development libraries are\ninstalled and detected. Install these with\n“\u003ccode\u003esudo apt install libx11-dev\u003c/code\u003e”. If GStreamer \u0026lt; 1.20 is\ndetected, a fix needed by screen-sharing apps (\u003cem\u003ee.g.\u003c/em\u003e, Zoom) will\nalso be made.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIf X11 development libraries are present, but you wish to build\nUxPlay \u003cem\u003ewithout\u003c/em\u003e any X11 dependence, use the cmake option\n\u003ccode\u003e-DNO_X11_DEPS=ON\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003col type=\"1\"\u003e\n\u003cli\u003e\u003ccode\u003esudo apt install libssl-dev libplist-dev\u003c/code\u003e“. (\u003cem\u003eunless\nyou need to build OpenSSL and libplist from source\u003c/em\u003e).\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esudo apt install libavahi-compat-libdnssd-dev\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esudo apt install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev\u003c/code\u003e.\n(*\u003cem\u003eSkip if you built Gstreamer from source\u003c/em\u003e)\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ecmake .\u003c/code\u003e (\u003cem\u003eFor a cleaner build, which is useful if\nyou modify the source, replace this by\u003c/em\u003e\n“\u003ccode\u003emkdir build; cd build; cmake ..\u003c/code\u003e”: \u003cem\u003eyou can then delete\nthe contents of the \u003ccode\u003ebuild\u003c/code\u003e directory if needed, without\naffecting the source.\u003c/em\u003e) Also add any cmake “\u003ccode\u003e-D\u003c/code\u003e” options\nhere as needed (e.g, \u003ccode\u003e-DNO_X11_DEPS=ON\u003c/code\u003e or\n\u003ccode\u003e-DNO_MARCH_NATIVE=ON\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003emake\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esudo make install\u003c/code\u003e (you can afterwards uninstall with\n\u003ccode\u003esudo make uninstall\u003c/code\u003e in the same directory in which this was\nrun).\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThis installs the executable file “\u003ccode\u003euxplay\u003c/code\u003e” to\n\u003ccode\u003e/usr/local/bin\u003c/code\u003e, (and installs a manpage to somewhere\nstandard like \u003ccode\u003e/usr/local/share/man/man1\u003c/code\u003e and README files to\nsomewhere like \u003ccode\u003e/usr/local/share/doc/uxplay\u003c/code\u003e). (If “man\nuxplay” fails, check if $MANPATH is set: if so, the path to the manpage\n(usually /usr/local/share/man/) needs to be added to $MANPATH .) The\nuxplay executable can also be found in the build directory after the\nbuild process, if you wish to test before installing (in which case the\nGStreamer plugins must first be installed).\u003c/p\u003e\n\u003ch3 id=\"building-on-non-debian-linux-and-bsd\"\u003eBuilding on non-Debian\nLinux and *BSD\u003c/h3\u003e\n\u003cp\u003e**For those with RPM-based distributions, a RPM spec file uxplay.spec\nis also available: see \u003ca\nhref=\"#building-an-installable-rpm-package\"\u003eBuilding an installable rpm\npackage\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eRed Hat, or clones like CentOS (now continued as Rocky\nLinux or Alma Linux):\u003c/strong\u003e (sudo dnf install, or sudo yum install)\nopenssl-devel libplist-devel avahi-compat-libdns_sd-devel\ngstreamer1-devel gstreamer1-plugins-base-devel (+libX11-devel for\nfullscreen X11) \u003cem\u003e(some of these may be in the “CodeReady” add-on\nrepository, called “PowerTools” by clones)\u003c/em\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eMageia, PCLinuxOS, OpenMandriva:\u003c/strong\u003e Same as Red\nHat, except for name changes: (Mageia) “gstreamer1.0-devel”,\n“gstreamer-plugins-base1.0-devel”; (OpenMandriva) “libopenssl-devel”,\n“gstreamer-devel”, “libgst-plugins-base1.0-devel”. PCLinuxOS: same as\nMageia, but uses synaptic (or apt) as its package manager.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eopenSUSE:\u003c/strong\u003e (sudo zypper install)\nlibopenssl-3-devel (formerly libopenssl-devel) libplist-2_0-devel\n(formerly libplist-devel) avahi-compat-mDNSResponder-devel\ngstreamer-devel gstreamer-plugins-base-devel (+ libX11-devel for\nfullscreen X11).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eArch Linux\u003c/strong\u003e (\u003cem\u003eAlso available as a package in\nAUR\u003c/em\u003e): (sudo pacman -Syu) openssl libplist avahi\ngst-plugins-base.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eFreeBSD:\u003c/strong\u003e (sudo pkg install) libplist gstreamer1.\nEither avahi-libdns or mDNSResponder must also be installed to provide\nthe dns_sd library. OpenSSL is already installed as a System\nLibrary.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4 id=\"building-an-installable-rpm-package\"\u003eBuilding an installable RPM\npackage\u003c/h4\u003e\n\u003cp\u003eFirst-time RPM builders should first install the rpm-build and\nrpmdevtools packages, then create the rpmbuild tree with\n“\u003ccode\u003erpmdev-setuptree\u003c/code\u003e”. Then download and copy uxplay.spec into\n\u003ccode\u003e~/rpmbuild/SPECS\u003c/code\u003e. In that directory, run\n“\u003ccode\u003erpmdev-spectool -g -R  uxplay.spec\u003c/code\u003e” to download the\ncorresponding source file \u003ccode\u003euxplay-*.tar.gz\u003c/code\u003e into\n\u003ccode\u003e~/rpmbuild/SOURCES\u003c/code\u003e (“rpmdev-spectool” may also be just\ncalled “spectool”); then run “\u003ccode\u003erpmbuild -ba uxplay.spec\u003c/code\u003e”\n(you will need to install any required dependencies this reports). This\nshould create the uxplay RPM package in a subdirectory of\n\u003ccode\u003e~/rpmbuild/RPMS\u003c/code\u003e. (\u003cstrong\u003euxplay.spec\u003c/strong\u003e is tested on\nFedora 38, Rocky Linux 9.2, openSUSE Leap 15.5, Mageia 9, OpenMandriva,\nPCLinuxOS; it can be easily modified to include dependency lists for\nother RPM-based distributions.)\u003c/p\u003e\n\u003ch2 id=\"running-uxplay\"\u003eRunning UxPlay\u003c/h2\u003e\n\u003ch3\nid=\"installing-plugins-debian-based-linux-distributions-including-ubuntu-and-raspberry-pi-os-skip-if-you-built-a-complete-gstreamer-from-source\"\u003eInstalling\nplugins (Debian-based Linux distributions, including Ubuntu and\nRaspberry Pi OS) (\u003cem\u003eskip if you built a complete GStreamer from\nsource\u003c/em\u003e)\u003c/h3\u003e\n\u003cp\u003eNext install the GStreamer plugins that are needed with\n\u003ccode\u003esudo apt install gstreamer1.0-\u0026lt;plugin\u0026gt;\u003c/code\u003e. Values of\n\u003ccode\u003e\u0026lt;plugin\u0026gt;\u003c/code\u003e required are:\u003c/p\u003e\n\u003col type=\"1\"\u003e\n\u003cli\u003e“\u003cstrong\u003eplugins-base\u003c/strong\u003e”\u003c/li\u003e\n\u003cli\u003e“\u003cstrong\u003elibav\u003c/strong\u003e” (for sound),\u003c/li\u003e\n\u003cli\u003e“\u003cstrong\u003eplugins-good\u003c/strong\u003e” (for v4l2 hardware h264\ndecoding)\u003c/li\u003e\n\u003cli\u003e“\u003cstrong\u003eplugins-bad\u003c/strong\u003e” (for h264 decoding).\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003eDebian-based distributions split some of the plugin packages\ninto smaller pieces:\u003c/strong\u003e some that may also be needed include\n“\u003cstrong\u003egl\u003c/strong\u003e” for OpenGL support (this provides the “-vs\nglimagesink” videosink, which can be very useful in many systems\n(including Raspberry Pi), and should always be used when using h264/h265\ndecoding by a NVIDIA GPU), “\u003cstrong\u003egtk3\u003c/strong\u003e” (which provides the\n“-vs gtksink” videosink), and “\u003cstrong\u003ex\u003c/strong\u003e” for X11 support,\nalthough these may already be installed; “\u003cstrong\u003evaapi\u003c/strong\u003e” is\nneeded for hardware-accelerated h264 video decoding by Intel or AMD\ngraphics (but not for use with NVIDIA using proprietary drivers). If\nsound is not working,\n“\u003cstrong\u003ealsa\u003c/strong\u003e”“,”\u003cstrong\u003epulseaudio\u003c/strong\u003e”, or\n“\u003cstrong\u003epipewire\u003c/strong\u003e” plugins may need to be installed, depending\non how your audio is set up.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAlso install “\u003cstrong\u003egstreamer1.0-tools\u003c/strong\u003e” to get the\nutility gst-inspect-1.0 for examining the GStreamer installation.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\nid=\"installing-plugins-non-debian-based-linux-or-bsd-skip-if-you-built-a-complete-gstreamer-from-source\"\u003eInstalling\nplugins (Non-Debian-based Linux or *BSD) (\u003cem\u003eskip if you built a\ncomplete GStreamer from source\u003c/em\u003e)\u003c/h3\u003e\n\u003cp\u003eIn some cases, because of patent issues, the libav plugin feature\n\u003cstrong\u003eavdec_aac\u003c/strong\u003e needed for decoding AAC audio in mirror mode\nis not provided in the official distribution: get it from community\nrepositories for those distributions.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eRed Hat, or clones like CentOS (now continued as Rocky\nLinux or Alma Linux):\u003c/strong\u003e Install gstreamer1-libav\ngstreamer1-plugins-bad-free (+ gstreamer1-vaapi for Intel/AMD graphics).\nIn recent Fedora, gstreamer1-libav is renamed gstreamer1-plugin-libav.\n\u003cstrong\u003eTo get avdec_aac, install packages from \u003ca\nhref=\"https://rpmfusion.org\"\u003erpmfusion.org\u003c/a\u003e\u003c/strong\u003e: (get\nffmpeg-libs from rpmfusion; on RHEL or clones, but not recent Fedora,\nalso get gstreamer1-libav from there).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eMageia, PCLinuxOS, OpenMandriva:\u003c/strong\u003e Install\ngstreamer1.0-libav gstreamer1.0-plugins-bad (+ gstreamer1.0-vaapi for\nIntel/AMD graphics). \u003cstrong\u003eOn Mageia, to get avdec_aac, install ffmpeg\nfrom the “tainted” repository\u003c/strong\u003e, (which also provides a more\ncomplete gstreamer1.0-plugins-bad).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eopenSUSE:\u003c/strong\u003e Install gstreamer-plugins-libav\ngstreamer-plugins-bad (+ gstreamer-plugins-vaapi for Intel/AMD\ngraphics). \u003cstrong\u003eTo get avdec_aac, install libav* packages for\nopenSUSE from \u003ca\nhref=\"https://ftp.gwdg.de/pub/linux/misc/packman/suse/\"\u003ePackman\u003c/a\u003e\n“Essentials”\u003c/strong\u003e; recommendation: after adding the Packman\nrepository, use the option in YaST Software management to switch all\nsystem packages for multimedia to Packman).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eArch Linux\u003c/strong\u003e Install gst-plugins-good\ngst-plugins-bad gst-libav (+ gstreamer-vaapi for Intel/AMD\ngraphics).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eFreeBSD:\u003c/strong\u003e Install gstreamer1-libav,\ngstreamer1-plugins, gstreamer1-plugins-* (* = core, good, bad, x, gtk,\ngl, vulkan, pulse, v4l2, …), (+ gstreamer1-vaapi for Intel/AMD\ngraphics).\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"starting-and-running-uxplay\"\u003eStarting and running UxPlay\u003c/h3\u003e\n\u003cp\u003eSince UxPlay-1.64, UxPlay can be started with options read from a\nconfiguration file, which will be the first found of (1) a file with a\npath given by environment variable \u003ccode\u003e$UXPLAYRC\u003c/code\u003e, (2)\n\u003ccode\u003e~/.uxplayrc\u003c/code\u003e in the user’s home directory (“~”), (3)\n\u003ccode\u003e~/.config/uxplayrc\u003c/code\u003e. The format is one option per line,\nomitting the initial \u003ccode\u003e\"-\"\u003c/code\u003e of the command-line option. Lines\nin the configuration file beginning with \u003ccode\u003e\"#\"\u003c/code\u003e are treated as\ncomments and ignored.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRun uxplay in a terminal window\u003c/strong\u003e. On some systems,\nyou can specify fullscreen mode with the \u003ccode\u003e-fs\u003c/code\u003e option, or\ntoggle into and out of fullscreen mode with F11 or (held-down left\nAlt)+Enter keys. Use Ctrl-C (or close the window) to terminate it when\ndone. If the UxPlay server is not seen by the iOS client’s drop-down\n“Screen Mirroring” panel, check that your DNS-SD server (usually\navahi-daemon) is running: do this in a terminal window with\n\u003ccode\u003esystemctl status avahi-daemon\u003c/code\u003e. If this shows the\navahi-daemon is not running, control it with\n\u003ccode\u003esudo systemctl [start,stop,enable,disable] avahi-daemon\u003c/code\u003e (on\nnon-systemd systems, such as *BSD, use\n\u003ccode\u003esudo service avahi-daemon [status, start, stop, restart, ...]\u003c/code\u003e).\nIf UxPlay is seen, but the client fails to connect when it is selected,\nthere may be a firewall on the server that prevents UxPlay from\nreceiving client connection requests unless some network ports are\nopened: \u003cstrong\u003eif a firewall is active, also open UDP port 5353 (for\nmDNS queries) needed by Avahi\u003c/strong\u003e. See \u003ca\nhref=\"#troubleshooting\"\u003eTroubleshooting\u003c/a\u003e below for help with this or\nother problems.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eUnlike an Apple TV, the UxPlay server does not by default require\nclients to initially “pair” with it using a pin code displayed by the\nserver (after which the client “trusts” the server, and does not need to\nrepeat this). Since v1.67, Uxplay offers such “pin-authentication” as an\noption: see “\u003ccode\u003e-pin\u003c/code\u003e” and “\u003ccode\u003e-reg\u003c/code\u003e” in \u003ca\nhref=\"#usage\"\u003eUsage\u003c/a\u003e for details, if you wish to use it. \u003cem\u003eSome\nclients with MDM (Mobile Device Management, often present on\nemployer-owned devices) are required to use pin-authentication: UxPlay\nwill provide this even when running without the pin\noption.\u003c/em\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eBy default, UxPlay is locked to its current client until that\nclient drops the connection; since UxPlay-1.58, the option\n\u003ccode\u003e-nohold\u003c/code\u003e modifies this behavior so that when a new client\nrequests a connection, it removes the current client and takes over.\nUxPlay 1.66 introduces a mechanism ( \u003ccode\u003e-restrict\u003c/code\u003e,\n\u003ccode\u003e-allow \u0026lt;id\u0026gt;\u003c/code\u003e, \u003ccode\u003e-block \u0026lt;id\u0026gt;\u003c/code\u003e) to\ncontrol which clients are allowed to connect, using their “deviceID”\n(which in Apple devices appears to be immutable).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eIn Mirror mode, GStreamer has a choice of \u003cstrong\u003etwo\u003c/strong\u003e\nmethods to play video with its accompanying audio: prior to UxPlay-1.64,\nthe video and audio streams were both played as soon as possible after\nthey arrived (the GStreamer “\u003cem\u003esync=false\u003c/em\u003e” method), with a\nGStreamer internal clock used to try to keep them synchronized.\n\u003cstrong\u003eStarting with UxPlay-1.64, the other method (GStreamer’s\n“\u003cem\u003esync=true\u003c/em\u003e” mode), which uses timestamps in the audio and video\nstreams sent by the client, is the new default\u003c/strong\u003e. On\nlow-decoding-power UxPlay hosts (such as Raspberry Pi Zero W or 3 B+\nmodels) this will drop video frames that cannot be decoded in time to\nplay with the audio, making the video jerky, but still\nsynchronized.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe older method which does not drop late video frames worked well on\nmore powerful systems, and is still available with the UxPlay option\n“\u003ccode\u003e-vsync no\u003c/code\u003e”; this method is adapted to “live streaming”,\nand may be better when using UxPlay as a second monitor for a Mac\ncomputer, for example, while the new default timestamp-based method is\nbest for watching a video, to keep lip movements and voices\nsynchronized. (Without use of timestamps, video will eventually lag\nbehind audio if it cannot be decoded fast enough: hardware-accelerated\nvideo-decoding helped to prevent this previously when timestamps were\nnot being used.)\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIn Audio-only mode the GStreamer “sync=false” mode (not using\ntimestamps) is still the default, but if you want to keep the audio\nplaying on the server synchronized with the video showing on the client,\nuse the \u003ccode\u003e-async\u003c/code\u003e timestamp-based option. (An example might be\nif you want to follow the Apple Music lyrics on the client while\nlistening to superior sound on the UxPlay server). This delays the video\non the client to match audio on the server, so leads to a slight delay\nbefore a pause or track-change initiated on the client takes effect on\nthe audio played by the server.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAirPlay volume-control attenuates volume (gain) by up to -30dB: the\ndecibel range -30:0 can be rescaled from \u003cem\u003eLow\u003c/em\u003e:0, or\n\u003cem\u003eLow\u003c/em\u003e:\u003cem\u003eHigh\u003c/em\u003e, using the option \u003ccode\u003e-db\u003c/code\u003e (“-db\n\u003cem\u003eLow\u003c/em\u003e” or “-db \u003cem\u003eLow\u003c/em\u003e:\u003cem\u003eHigh\u003c/em\u003e”), \u003cem\u003eLow\u003c/em\u003e must be\nnegative. Rescaling is linear in decibels. Note that GStreamer’s audio\nformat will “clip” any audio gain above +20db, so keep \u003cem\u003eHigh\u003c/em\u003e\nbelow that level. The option \u003ccode\u003e-taper\u003c/code\u003e provides a “tapered”\nAirPlay volume-control profile some users may prefer.\u003c/p\u003e\n\u003cp\u003eThe -vsync and -async options also allow an optional positive (or\nnegative) audio-delay adjustment in \u003cem\u003emilliseconds\u003c/em\u003e for\nfine-tuning : \u003ccode\u003e-vsync 20.5\u003c/code\u003e delays audio relative to video by\n0.0205 secs; a negative value advances it.)\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eyou may find video is improved by the setting -fps 60 that allows\nsome video to be played at 60 frames per second. (You can see what\nframerate is actually streaming by using -vs fpsdisplaysink, and/or\n-FPSdata.) When using this, you should use the default timestamp-based\nsynchronization option \u003ccode\u003e-vsync\u003c/code\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eSince UxPlay-1.54, you can display the accompanying “Cover Art”\nfrom sources like Apple Music in Audio-Only (ALAC) mode: run\n“\u003ccode\u003euxplay -ca \u0026lt;name\u0026gt; \u0026amp;\u003c/code\u003e” in the background, then run\na image viewer with an autoreload feature: an example is “feh”: run\n“\u003ccode\u003efeh -R 1 \u0026lt;name\u0026gt;\u003c/code\u003e” in the foreground; terminate feh\nand then Uxplay with “\u003ccode\u003ectrl-C fg ctrl-C\u003c/code\u003e”.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBy default, GStreamer uses an algorithm to search for the best\n“videosink” (GStreamer’s term for a graphics driver to display images)\nto use. You can overide this with the uxplay option\n\u003ccode\u003e-vs \u0026lt;videosink\u0026gt;\u003c/code\u003e. Which videosinks are available\ndepends on your operating system and graphics hardware: use\n“\u003ccode\u003egst-inspect-1.0 | grep sink | grep -e video -e Video -e image\u003c/code\u003e”\nto see what is available. Some possibilites on Linux/*BSD are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eglimagesink\u003c/strong\u003e (OpenGL),\n\u003cstrong\u003ewaylandsink\u003c/strong\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003exvimagesink\u003c/strong\u003e, \u003cstrong\u003eximagesink\u003c/strong\u003e\n(X11)\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003ekmssink\u003c/strong\u003e, \u003cstrong\u003efbdevsink\u003c/strong\u003e (console\ngraphics without X11)\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003evaapisink\u003c/strong\u003e (for Intel/AMD hardware-accelerated\ngraphics); for NVIDIA hardware graphics (with CUDA) use\n\u003cstrong\u003eglimagesink\u003c/strong\u003e combined with “\u003ccode\u003e-vd nvh264dec\u003c/code\u003e”\n(or “nvh264sldec”, a new variant which will become “nvh264dec” in\nGStreamer-1.24).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eIf the server is “headless” (no attached monitor, renders audio\nonly) use \u003ccode\u003e-vs 0\u003c/code\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGStreamer also searches for the best “audiosink”; override its choice\nwith \u003ccode\u003e-as \u0026lt;audiosink\u0026gt;\u003c/code\u003e. Choices on Linux include\npulsesink, alsasink, pipewiresink, oss4sink; see what is available with\n\u003ccode\u003egst-inspect-1.0 | grep sink | grep -e audio -e Audio\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOne common problem involves GStreamer attempting to use\nincorrectly-configured or absent accelerated hardware h264 video\ndecoding (e.g., VAAPI). Try “\u003ccode\u003euxplay -avdec\u003c/code\u003e” to force\nsoftware video decoding; if this works you can then try to fix\naccelerated hardware video decoding if you need it, or just uninstall\nthe GStreamer vaapi plugin.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSee \u003ca href=\"#usage\"\u003eUsage\u003c/a\u003e for more run-time options.\u003c/p\u003e\n\u003ch3\nid=\"special-instructions-for-raspberry-pi-tested-on-raspberry-pi-zero-2-w-3-model-b-4-model-b-and-5-only\"\u003e\u003cstrong\u003eSpecial\ninstructions for Raspberry Pi (tested on Raspberry Pi Zero 2 W, 3 Model\nB+, 4 Model B, and 5 only)\u003c/strong\u003e:\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eFor Framebuffer video (for Raspberry Pi OS “Lite” and other\nnon-X11 distributions) use the KMS videosink “-vs kmssink” (the DirectFB\nframebuffer videosink “dfbvideosink” is broken on the Pi, and\nsegfaults). \u003cem\u003eIn this case you should explicitly use the “-vs kmssink”\noption, as without it, autovideosink does not find the correct\nvideosink.\u003c/em\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eRaspberry Pi 5 does not provide hardware H264 decoding (and does\nnot need it).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003ePi Zero 2 W, 3 Model B+ and 4 Model B should use hardware H264\ndecoding by the Broadcom GPU, but it requires an out-of-mainstream\nkernel module bcm2835_codec maintained in the \u003ca\nhref=\"https://github.com/raspberrypi/linux\"\u003eRaspberry Pi kernel\ntree\u003c/a\u003e; distributions that are known to supply it include Raspberry Pi\nOS, Ubuntu, and Manjaro-RPi4. Use software decoding (option -avdec) if\nthis module is not available.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eUxplay uses the Video4Linux2 (v4l2) plugin from GStreamer-1.22\nand later to access the GPU, if hardware H264 decoding is used. This\nshould happen automatically. The option -v4l2 can be used, but it is\nusually best to just let GStreamer find the best video pipeline by\nitself.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eOn older distributions (GStreamer \u0026lt; 1.22), the v4l2 plugin\nneeds a patch: see the \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches\"\u003eUxPlay\nWiki\u003c/a\u003e. Legacy Raspberry Pi OS (Bullseye) has a partially-patched\nGStreamer-1.18.4 which needs the uxplay option -bt709 (and don’t use\n-v4l2); it is still better to apply the full patch from the UxPlay Wiki\nin this case.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eFor “double-legacy” Raspberry Pi OS (Buster), there is no patch\nfor GStreamer-1.14. Instead, first build a complete newer\nGStreamer-1.18.6 from source using \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Building-latest-GStreamer-from-source-on-distributions-with-older-GStreamer-(e.g.-Raspberry-Pi-OS-).\"\u003ethese\ninstructions\u003c/a\u003e before building UxPlay.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eRaspberry Pi 3 Model B+ running a 32 bit OS can also access the\nGPU with the GStreamer OMX plugin (use option\n“\u003ccode\u003e-vd omxh264dec\u003c/code\u003e”), but this is broken by Pi 4 Model B\nfirmware. OMX support was removed from Raspberry Pi OS (Bullseye), but\nis present in Buster.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eH265 (4K)\u003c/strong\u003e video is supported with hardware\ndecoding by the Broadcom GPU on Raspberry Pi 5 models, as well as on\nRaspberry Pi 4 model B. \u003cstrong\u003eWhile GStreamer seem to make use of this\nhardware decoding, satisfactory rendering speed of 4K video by UxPlay on\nthese Raspberry Pi models has not yet been acheived.\u003c/strong\u003e The option\n“-h265” is required for activating h265 support. A wired ethernet\nconnection is preferred in this mode (and may be required by the\nclient).\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEven with GPU video decoding, some frames may be dropped by the\nlower-power models to keep audio and video synchronized using\ntimestamps. In Legacy Raspberry Pi OS (Bullseye), raspi-config\n“Performance Options” allows specifying how much memory to allocate to\nthe GPU, but this setting appears to be absent in Bookworm (but it can\nstill be set to e.g. 128MB by adding a line “gpu_mem=128” in\n/boot/config.txt). A Pi Zero 2 W (which has 512MB memory) worked well\nwhen tested in 32 bit Bullseye or Bookworm Lite with 128MB allocated to\nthe GPU (default seems to be 64MB).\u003c/p\u003e\n\u003cp\u003eThe basic uxplay options for R Pi are\n\u003ccode\u003euxplay [-vs \u0026lt;videosink\u0026gt;]\u003c/code\u003e. The choice\n\u003ccode\u003e\u0026lt;videosink\u0026gt;\u003c/code\u003e = \u003ccode\u003eglimagesink\u003c/code\u003e is sometimes\nuseful. With the Wayland video compositor, use\n\u003ccode\u003e\u0026lt;videosink\u0026gt;\u003c/code\u003e = \u003ccode\u003ewaylandsink\u003c/code\u003e. With\nframebuffer video, use \u003ccode\u003e\u0026lt;videosink\u0026gt;\u003c/code\u003e =\n\u003ccode\u003ekmssink\u003c/code\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTip: to start UxPlay on a remote host (such as a Raspberry Pi) using\nssh:\u003c/li\u003e\n\u003c/ul\u003e\n\u003cpre\u003e\u003ccode\u003e   ssh user@remote_host\n   export DISPLAY=:0\n   nohup uxplay [options] \u0026gt; FILE \u0026amp;\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSound and video will play on the remote host; “nohup” will keep\nuxplay running if the ssh session is closed. Terminal output is saved to\nFILE (which can be /dev/null to discard it)\u003c/p\u003e\n\u003ch2\nid=\"building-uxplay-on-macos-intel-x86_64-and-apple-silicon-m1m2-macs\"\u003eBuilding\nUxPlay on macOS: \u003cstrong\u003e(Intel X86_64 and “Apple Silicon” M1/M2\nMacs)\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: A native AirPlay Server feature is included in macOS 12\nMonterey, but is restricted to recent hardware. UxPlay can run on older\nmacOS systems that will not be able to run Monterey, or can run Monterey\nbut not AirPlay.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThese instructions for macOS assume that the Xcode command-line\ndeveloper tools are installed (if Xcode is installed, open the Terminal,\ntype “sudo xcode-select –install” and accept the conditions).\u003c/p\u003e\n\u003cp\u003eIt is also assumed that CMake \u0026gt;= 3.13 is installed: this can be\ndone with package managers \u003ca\nhref=\"http://www.macports.org\"\u003eMacPorts\u003c/a\u003e\n(\u003ccode\u003esudo port install cmake\u003c/code\u003e), \u003ca\nhref=\"http://brew.sh\"\u003eHomebrew\u003c/a\u003e (\u003ccode\u003ebrew install cmake\u003c/code\u003e), or\nby a download from \u003ca\nhref=\"https://cmake.org/download/\"\u003ehttps://cmake.org/download/\u003c/a\u003e. Also\ninstall \u003ccode\u003egit\u003c/code\u003e if you will use it to fetch UxPlay.\u003c/p\u003e\n\u003cp\u003eNext install libplist and openssl-3.x. Note that static versions of\nthese libraries will be used in the macOS builds, so they can be\nuninstalled after building uxplay, if you wish.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eIf you use Homebrew:\n\u003ccode\u003ebrew install libplist openssl@3\u003c/code\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eif you use MacPorts:\n\u003ccode\u003esudo port install libplist-devel openssl3\u003c/code\u003e\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOtherwise, build libplist and openssl from source: see instructions\nnear the end of this README; requires development tools (autoconf,\nautomake, libtool, \u003cem\u003eetc.\u003c/em\u003e) to be installed.\u003c/p\u003e\n\u003cp\u003eNext get the latest macOS release of GStreamer-1.0.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eUsing “Official” GStreamer (Recommended for both MacPorts and\nHomebrew users)\u003c/strong\u003e: install the GStreamer release for macOS from\n\u003ca\nhref=\"https://gstreamer.freedesktop.org/download/\"\u003ehttps://gstreamer.freedesktop.org/download/\u003c/a\u003e.\n(This release contains its own pkg-config, so you don’t have to install\none.) Install both the gstreamer-1.0 and gstreamer-1.0-devel packages.\nAfter downloading, Shift-Click on them to install (they install to\n/Library/FrameWorks/GStreamer.framework). Homebrew or MacPorts users\nshould \u003cstrong\u003enot\u003c/strong\u003e install (or should uninstall) the GStreamer\nsupplied by their package manager, if they use the “official”\nrelease.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSince GStreamer v1.22, the “Official” (gstreamer.freedesktop.org)\nmacOS binaries require a wrapper “gst_macos_main” around the actual main\nprogram (uxplay). This should have been applied during the UxPlay\ncompilation process, and the initial UxPlay terminal message should\nconfirm it is being used. (UxPlay can also be built using “Official”\nGStreamer v.1.20.7 binaries, which work without the wrapper.)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eUsing Homebrew’s GStreamer\u003c/strong\u003e: pkg-config is needed:\n(“brew install pkg-config gstreamer”). This causes a large number of\nextra packages to be installed by Homebrew as dependencies. The \u003ca\nhref=\"https://formulae.brew.sh/formula/gstreamer#default\"\u003eHomebrew\ngstreamer installation\u003c/a\u003e has recently been reworked into a single\n“formula” named \u003ccode\u003egstreamer\u003c/code\u003e, which now works without needing\nGST_PLUGIN_PATH to be set in the enviroment. Homebrew installs gstreamer\nto \u003ccode\u003eHOMEBREW_PREFIX/lib/gstreamer-1.0\u003c/code\u003e where by default\n\u003ccode\u003eHOMEBREW_PREFIX/*\u003c/code\u003e is \u003ccode\u003e/opt/homebrew/*\u003c/code\u003e on Apple\nSilicon Macs, and \u003ccode\u003e/usr/local/*\u003c/code\u003e on Intel Macs; do not put\nany extra non-Homebrew plugins (that you build yourself) there, and\ninstead set GST_PLUGIN_PATH to point to their location (Homebrew does\nnot supply a complete GStreamer, but seems to have everything needed for\nUxPlay). \u003cstrong\u003eNew: the UxPlay build script will now also detect\nHomebrew installations in non-standard locations indicated by the\nenvironment variable \u003ccode\u003e$HOMEBREW_PREFIX\u003c/code\u003e.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eUsing GStreamer installed from MacPorts\u003c/strong\u003e: this is\n\u003cstrong\u003enot\u003c/strong\u003e recommended, as currently the MacPorts GStreamer is\nold (v1.16.2), unmaintained, and built to use X11:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eInstead \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Building-GStreamer-from-Source-on-macOS-with-MacPorts\"\u003ebuild\ngstreamer yourself\u003c/a\u003e if you use MacPorts and do not want to use the\n“Official” Gstreamer binaries.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cem\u003e(If you really wish to use the MacPorts GStreamer-1.16.2, install\npkgconf (“sudo port install pkgconf”), then “sudo port install\ngstreamer1-gst-plugins-base gstreamer1-gst-plugins-good\ngstreamer1-gst-plugins-bad gstreamer1-gst-libav”. For X11 support on\nmacOS, compile UxPlay using a special cmake option\n\u003ccode\u003e-DUSE_X11=ON\u003c/code\u003e, and run it from an XQuartz terminal with -vs\nximagesink; older non-retina macs require a lower resolution when using\nX11: \u003ccode\u003euxplay -s 800x600\u003c/code\u003e.)\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eAfter installing GStreamer, build and install uxplay: open a terminal\nand change into the UxPlay source directory (“UxPlay-master” for zipfile\ndownloads, “UxPlay” for “git clone” downloads) and build/install with\n“cmake . ; make ; sudo make install” (same as for Linux).\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eRunning UxPlay while checking for GStreamer warnings (do this\nwith “export GST_DEBUG=2” before runnng UxPlay) reveals that with the\ndefault (since UxPlay 1.64) use of timestamps for video synchonization,\nmany video frames are being dropped (only on macOS), perhaps due to\nanother error (about videometa) that shows up in the GStreamer warnings.\n\u003cstrong\u003eRecommendation: use the new UxPlay “no timestamp” option\n“\u003ccode\u003e-vsync no\u003c/code\u003e”\u003c/strong\u003e (you can add a line “vsync no” in the\nuxplayrc configuration file).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eOn macOS with this installation of GStreamer, the only videosinks\navailable seem to be glimagesink (default choice made by autovideosink)\nand osxvideosink. The window title does not show the Airplay server\nname, but the window is visible to screen-sharing apps (e.g., Zoom). The\nonly available audiosink seems to be osxaudiosink.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eThe option -nc is always used, whether or not it is selected.\nThis is a workaround for a problem with GStreamer videosinks on macOS:\nif the GStreamer pipeline is destroyed while the mirror window is still\nopen, a segfault occurs.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eIn the case of glimagesink, the resolution settings “-s wxh” do\nnot affect the (small) initial OpenGL mirror window size, but the window\ncan be expanded using the mouse or trackpad. In contrast, a window\ncreated with “-vs osxvideosink” is initially big, but has the wrong\naspect ratio (stretched image); in this case the aspect ratio changes\nwhen the window width is changed by dragging its side; the option\n\u003ccode\u003e-vs \"osxvideosink force-aspect-ratio=true\"\u003c/code\u003e can be used to\nmake the window have the correct aspect ratio when it first\nopens.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\nid=\"building-uxplay-on-microsoft-windows-using-msys2-with-the-mingw-64-compiler.\"\u003eBuilding\nUxPlay on Microsoft Windows, using MSYS2 with the MinGW-64\ncompiler.\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003etested on Windows 10 and 11, 64-bit.\u003c/li\u003e\n\u003c/ul\u003e\n\u003col type=\"1\"\u003e\n\u003cli\u003e\u003cp\u003eDownload and install \u003cstrong\u003eBonjour SDK for Windows\nv3.0\u003c/strong\u003e. You can download the SDK without any registration at \u003ca\nhref=\"https://www.softpedia.com/get/Programming/SDK-DDK/Bonjour-SDK.shtml\"\u003esoftpedia.com\u003c/a\u003e,\nor get it from the official Apple site \u003ca\nhref=\"https://developer.apple.com/download/all/?q=Bonjour%20SDK%20for%20Windows\"\u003ehttps://developer.apple.com/download\u003c/a\u003e\n(Apple makes you register as a developer to access it from their site).\nThis should install the Bonjour SDK as\n\u003ccode\u003eC:\\Program Files\\Bonjour SDK\u003c/code\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e(This is for 64-bit Windows; a build for 32-bit Windows should be\npossible, but is not tested.) The unix-like MSYS2 build environment will\nbe used: download and install MSYS2 from the official site \u003ca\nhref=\"https://www.msys2.org\"\u003ehttps://www.msys2.org/\u003c/a\u003e. Accept the\ndefault installation location \u003ccode\u003eC:\\mysys64\u003c/code\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003ca href=\"https://packages.msys2.org/package/\"\u003eMSYS2 packages\u003c/a\u003e\nare installed with a variant of the “pacman” package manager used by\nArch Linux. Open a “MSYS2 MINGW64” terminal from the MSYS2 tab in the\nWindows Start menu, and update the new MSYS2 installation with “pacman\n-Syu”. Then install the \u003cstrong\u003eMinGW-64\u003c/strong\u003e compiler and\n\u003cstrong\u003ecmake\u003c/strong\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003epacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe compiler with all required dependencies will be installed in the\nmsys64 directory, with default path \u003ccode\u003eC:/msys64/mingw64\u003c/code\u003e. Here\nwe will simply build UxPlay from the command line in the MSYS2\nenvironment (this uses “\u003ccode\u003eninja\u003c/code\u003e” in place of\n“\u003ccode\u003emake\u003c/code\u003e” for the build system).\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eDownload the latest UxPlay from github \u003cstrong\u003e(to use\n\u003ccode\u003egit\u003c/code\u003e, install it with \u003ccode\u003epacman -S git\u003c/code\u003e, then\n“\u003ccode\u003egit clone https://github.com/FDH2/UxPlay\u003c/code\u003e”)\u003c/strong\u003e, then\ninstall UxPlay dependencies (openssl is already installed with\nMSYS2):\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003epacman -S mingw-w64-x86_64-libplist mingw-w64-x86_64-gstreamer mingw-w64-x86_64-gst-plugins-base\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eIf you are trying a different Windows build system, MSVC versions of\nGStreamer for Windows are available from the \u003ca\nhref=\"https://gstreamer.freedesktop.org/download/\"\u003eofficial GStreamer\nsite\u003c/a\u003e, but only the MinGW 64-bit build on MSYS2 has been\ntested.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003ecd to the UxPlay source directory, then\n“\u003ccode\u003emkdir build\u003c/code\u003e” and “\u003ccode\u003ecd build\u003c/code\u003e”. The build\nprocess assumes that the Bonjour SDK is installed at\n\u003ccode\u003eC:\\Program Files\\Bonjour SDK\u003c/code\u003e. If it is somewhere else, set\nthe enviroment variable BONJOUR_SDK_HOME to point to its location. Then\nbuild UxPlay with\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ecmake ..\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eninja\u003c/code\u003e\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eAssuming no error in either of these, you will have built the\nuxplay executable \u003cstrong\u003euxplay.exe\u003c/strong\u003e in the current (“build”)\ndirectory. The “sudo make install” and “sudo make uninstall” features\noffered in the other builds are not available on Windows; instead, the\nMSYS2 environment has \u003ccode\u003e/mingw64/...\u003c/code\u003e available, and you can\ninstall the uxplay.exe executable in \u003ccode\u003eC:/msys64/mingw64/bin\u003c/code\u003e\n(plus manpage and documentation in\n\u003ccode\u003eC:/msys64/mingw64/share/...\u003c/code\u003e) with\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ecmake --install . --prefix /mingw64\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eTo be able to view the manpage, you need to install the manpage\nviewer with “\u003ccode\u003epacman -S man\u003c/code\u003e”.\u003c/p\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eTo run \u003cstrong\u003euxplay.exe\u003c/strong\u003e you need to install some gstreamer\nplugin packages with\n\u003ccode\u003epacman -S mingw-w64-x86_64-gst-\u0026lt;plugin\u0026gt;\u003c/code\u003e, where the\nrequired ones have \u003ccode\u003e\u0026lt;plugin\u0026gt;\u003c/code\u003e given by\u003c/p\u003e\n\u003col type=\"1\"\u003e\n\u003cli\u003e\u003cstrong\u003elibav\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eplugins-good\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eplugins-bad\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eOther possible MSYS2 gstreamer plugin packages you might use are\nlisted in \u003ca href=\"https://packages.msys2.org/package/\"\u003eMSYS2\npackages\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eYou also will need to grant permission to the uxplay executable\nuxplay.exe to access data through the Windows firewall. You may\nautomatically be offered the choice to do this when you first run\nuxplay, or you may need to do it using \u003cstrong\u003eWindows\nSettings-\u0026gt;Update and Security-\u0026gt;Windows Security-\u0026gt;Firewall \u0026amp;\nnetwork protection -\u0026gt; allow an app through firewall\u003c/strong\u003e. If your\nvirus protection flags uxplay.exe as “suspicious” (but without a true\nmalware signature) you may need to give it an exception.\u003c/p\u003e\n\u003cp\u003eNow test by running “\u003ccode\u003euxplay\u003c/code\u003e” (in a MSYS2 terminal\nwindow). If you need to specify the audiosink, there are two main\nchoices on Windows: the older DirectSound plugin\n“\u003ccode\u003e-as directsoundsink\u003c/code\u003e”, and the more modern Windows Audio\nSession API (wasapi) plugin “\u003ccode\u003e-as wasapisink\u003c/code\u003e”, which\nsupports \u003ca\nhref=\"https://gstreamer.freedesktop.org/documentation/wasapi/wasapisink.html\"\u003eadditional\noptions\u003c/a\u003e such as\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003euxplay -as \u0026#39;wasapisink device=\\\u0026quot;\u0026lt;guid\u0026gt;\\\u0026quot;\u0026#39; \u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003ewhere \u003ccode\u003e\u0026lt;guid\u0026gt;\u003c/code\u003e specifies an available audio device\nby its GUID, which can be found using\n“\u003ccode\u003egst-device-monitor-1.0 Audio\u003c/code\u003e”: \u003ccode\u003e\u0026lt;guid\u0026gt;\u003c/code\u003e\nhas a form like\n\u003ccode\u003e\\{0.0.0.00000000\\}.\\{98e35b2b-8eba-412e-b840-fd2c2492cf44\\}\u003c/code\u003e.\nIf “\u003ccode\u003edevice\u003c/code\u003e” is not specified, the default audio device is\nused.\u003c/p\u003e\n\u003cp\u003eIf you wish to specify the videosink using the\n\u003ccode\u003e-vs \u0026lt;videosink\u0026gt;\u003c/code\u003e option, some choices for\n\u003ccode\u003e\u0026lt;videosink\u0026gt;\u003c/code\u003e are \u003ccode\u003ed3d11videosink\u003c/code\u003e,\n\u003ccode\u003ed3dvideosink\u003c/code\u003e, \u003ccode\u003eglimagesink\u003c/code\u003e,\n\u003ccode\u003egtksink\u003c/code\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWith Direct3D 11.0 or greater, you can either always be in\nfullscreen mode using option\n\u003ccode\u003e-vs \"d3d11videosink fullscreen-toggle-mode=property fullscreen=true\"\u003c/code\u003e,\nor get the ability to toggle into and out of fullscreen mode using the\nAlt-Enter key combination with option\n\u003ccode\u003e-vs \"d3d11videosink fullscreen-toggle-mode=alt-enter\"\u003c/code\u003e. For\nconvenience, these options will be added if just\n\u003ccode\u003e-vs d3d11videosink\u003c/code\u003e with or without the fullscreen option\n“-fs” is used. \u003cem\u003e(Windows users may wish to add\n“\u003ccode\u003evs d3d11videosink\u003c/code\u003e” (no initial “\u003ccode\u003e-\u003c/code\u003e”) to the\nUxPlay startup options file; see “man uxplay” or “uxplay -h”.)\u003c/em\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe executable uxplay.exe can also be run without the MSYS2\nenvironment, in the Windows Terminal, with\n\u003ccode\u003eC:\\msys64\\mingw64\\bin\\uxplay\u003c/code\u003e.\u003c/p\u003e\n\u003ch1 id=\"usage\"\u003eUsage\u003c/h1\u003e\n\u003cp\u003eOptions:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThese can also be written (one option per line, without the initial\n“\u003ccode\u003e-\u003c/code\u003e” character) in the UxPlay startup file (either given by\nenvironment variable \u003ccode\u003e$UXPLAYRC\u003c/code\u003e, or \u003ccode\u003e~/.uxplayrc\u003c/code\u003e\nor \u003ccode\u003e~/.config/uxplayrc\u003c/code\u003e); lines begining with\n“\u003ccode\u003e#\u003c/code\u003e” are treated as comments, and ignored. Command line\noptions supersede options in the startup file.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e-n server_name\u003c/strong\u003e (Default: UxPlay);\nserver_name@_hostname_ will be the name that appears offering AirPlay\nservices to your iPad, iPhone etc, where \u003cem\u003ehostname\u003c/em\u003e is the name\nof the server running uxplay. This will also now be the name shown above\nthe mirror display (X11) window.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-nh\u003c/strong\u003e Do not append “\u003cspan class=\"citation\"\ndata-cites=\"_hostname_\"\u003e@_hostname_\u003c/span\u003e” at the end of the AirPlay\nserver name.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-h265\u003c/strong\u003e Activate “ScreenMultiCodec” support (AirPlay\n“Features” bit 42) for accepting h265 (4K/HEVC) video in addition to\nh264 video (1080p) in screen-mirror mode. When this option is used, two\n“video pipelines” (one for h264, one for h265) are created. If any\nGStreamer plugins in the pipeline are specific for h264 or h265, the\ncorrect version will be used in each pipeline. A wired Client-Server\nethernet connection is preferred over Wifi for 4K video, and might be\nrequired by the client. Only recent Apple devices (M1/M2 Macs or iPads,\nand some iPhones) can send h265 video if a resolut “-s wxh” with h \u0026gt;\n1080 is requested. The “-h265” option changes the default resolution\n(“-s” option) from 1920x1080 to 3840x2160, and leaves default maximum\nframerate (“-fps” option) at 30fps.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-pin [nnnn]\u003c/strong\u003e: (since v1.67) use Apple-style\n(one-time) “pin” authentication when a new client connects for the first\ntime: a four-digit pin code is displayed on the terminal, and the client\nscreen shows a login prompt for this to be entered. When “-pin” is used\nby itself, a new random pin code is chosen for each authentication; if\n“-pin nnnn” (e.g., “-pin 3939”) is used, this will set an unchanging\nfixed code. Authentication adds the server to the client’s list of\n“trusted servers” and the client will not need to reauthenticate\nprovided that the client and server public keys remain unchanged. (By\ndefault since v1.68, the server public key is generated from the MAC\naddress, which can be changed with the -m option; see the -key option\nfor an alternative method of key generation). \u003cem\u003e(Add a line “pin” in\nthe UxPlay startup file if you wish the UxPlay server to use the pin\nauthentication protocol).\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-reg [\u003cem\u003efilename\u003c/em\u003e]\u003c/strong\u003e: (since v1.68). If “-pin”\nis used, this option maintains a register of pin-authenticated “trusted\nclients” in $HOME/.uxplay.register (or optionally, in\n\u003cem\u003efilename\u003c/em\u003e). Without this option, returning clients that skip\npin-authentication are trusted and not checked. This option may be\nuseful if UxPlay is used in a more public environment, to record client\ndetails; the register is text, one line per client, with client’s public\nkey (base-64 format), Device ID, and Device name; commenting out (with\n“#”) or deleting a line deregisters the corresponding client (see\noptions -restrict, -block, -allow for more ways to control client\naccess). \u003cem\u003e(Add a line “reg” in the startup file if you wish to use\nthis feature.)\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vsync [x]\u003c/strong\u003e (In Mirror mode:) this option\n(\u003cstrong\u003enow the default\u003c/strong\u003e) uses timestamps to synchronize audio\nwith video on the server, with an optional audio delay in (decimal)\nmilliseconds (\u003cem\u003ex\u003c/em\u003e = “20.5” means 0.0205 seconds delay: positive\nor negative delays less than a second are allowed.) It is needed on\nlow-power systems such as Raspberry Pi without hardware video\ndecoding.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vsync no\u003c/strong\u003e (In Mirror mode:) this switches off\ntimestamp-based audio-video synchronization, restoring the default\nbehavior prior to UxPlay-1.64. Standard desktop systems seem to work\nwell without use of timestamps: this mode is appropriate for “live\nstreaming” such as using UxPlay as a second monitor for a mac computer,\nor monitoring a webcam; with it, no video frames are dropped.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-async [x]\u003c/strong\u003e (In Audio-Only (ALAC) mode:) this option\nuses timestamps to synchronize audio on the server with video on the\nclient, with an optional audio delay in (decimal) milliseconds\n(\u003cem\u003ex\u003c/em\u003e = “20.5” means 0.0205 seconds delay: positive or negative\ndelays less than a second are allowed.) Because the client adds a video\ndelay to account for latency, the server in -async mode adds an\nequivalent audio delay, which means that audio changes such as a pause\nor a track-change will not take effect immediately. \u003cem\u003eThis might in\nprinciple be mitigated by using the \u003ccode\u003e-al\u003c/code\u003e audio latency\nsetting to change the latency (default 0.25 secs) that the server\nreports to the client, but at present changing this does not seem to\nhave any effect\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-async no\u003c/strong\u003e. This is the still the default behavior in\nAudio-only mode, but this option may be useful as a command-line option\nto switch off a \u003ccode\u003e-async\u003c/code\u003e option set in a “uxplayrc”\nconfiguration file.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-db \u003cem\u003elow\u003c/em\u003e[:\u003cem\u003ehigh\u003c/em\u003e]\u003c/strong\u003e Rescales the\nAirPlay volume-control attenuation (gain) from -30dB:0dB to\n\u003cem\u003elow\u003c/em\u003e:0dB or \u003cem\u003elow\u003c/em\u003e:\u003cem\u003ehigh\u003c/em\u003e. The lower limit\n\u003cem\u003elow\u003c/em\u003e must be negative (attenuation); the upper limit\n\u003cem\u003ehigh\u003c/em\u003e can be either sign. (GStreamer restricts\nvolume-augmentation by \u003cem\u003ehigh\u003c/em\u003e so that it cannot exceed +20dB).\nThe rescaling is “flat”, so that for -db -50:10, a change in Airplay\nattenuation by -7dB is translated to a -7 x (60/30) = -14dB attenuation,\nand the maximum volume (AirPlay 0dB) is a 10dB augmentation, and Airplay\n-30dB would become -50dB. Note that the minimum AirPlay value (-30dB\nexactly) is translated to “mute”.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-taper\u003c/strong\u003e Provides a “tapered” Airplay volume-control\nprofile (matching the one called “dasl-tapering” in \u003ca\nhref=\"https://github.com/mikebrady/shairport-sync\"\u003eshairport-sync\u003c/a\u003e):\neach time the length of the volume slider (or the number of steps above\nmute, where 16 steps = full volume) is reduced by 50%, the perceived\nvolume is halved (a 10dB attenuation). (This is modified at low volumes,\nto use the “untapered” volume if it is louder.)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-s wxh\u003c/strong\u003e e.g. -s 1920x1080 (= “1080p”), the default\nwidth and height resolutions in pixels for h264 video. (The default\nbecomes 3840x2160 (= “4K”) when the -h265 option is used.) This is just\na request made to the AirPlay client, and perhaps will not be the final\nresolution you get. w and h are whole numbers with four digits or less.\nNote that the \u003cstrong\u003eheight\u003c/strong\u003e pixel size is the controlling one\nused by the client for determining the streaming format; the width is\ndynamically adjusted to the shape of the image (portrait or landscape\nformat, depending on how an iPad is held, for example).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-s wxh@r\u003c/strong\u003e As above, but also informs the AirPlay\nclient about the screen refresh rate of the display. Default is r=60 (60\nHz); r must be a whole number less than 256.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-o\u003c/strong\u003e turns on an “overscanned” option for the display\nwindow. This reduces the image resolution by using some of the pixels\nrequested by option -s wxh (or their default values 1920x1080) by adding\nan empty boundary frame of unused pixels (which would be lost in a\nfull-screen display that overscans, and is not displayed by gstreamer).\nRecommendation: \u003cstrong\u003edon’t use this option\u003c/strong\u003e unless there is\nsome special reason to use it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-fs\u003c/strong\u003e uses fullscreen mode, but only works with X11,\nWayland, VAAPI, and D3D11 (Windows).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-p\u003c/strong\u003e allows you to select the network ports used by\nUxPlay (these need to be opened if the server is behind a firewall). By\nitself, -p sets “legacy” ports TCP 7100, 7000, 7001, UDP 6000, 6001,\n7011. -p n (e.g. -p 35000) sets TCP and UDP ports n, n+1, n+2. -p\nn1,n2,n3 (comma-separated values) sets each port separately; -p n1,n2\nsets ports n1,n2,n2+1. -p tcp n or -p udp n sets just the TCP or UDP\nports. Ports must be in the range [1024-65535].\u003c/p\u003e\n\u003cp\u003eIf the -p option is not used, the ports are chosen dynamically\n(randomly), which will not work if a firewall is running.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-avdec\u003c/strong\u003e forces use of software h264 decoding using\nGstreamer element avdec_h264 (libav h264 decoder). This option should\nprevent autovideosink choosing a hardware-accelerated videosink plugin\nsuch as vaapisink.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vp \u003cem\u003eparser\u003c/em\u003e\u003c/strong\u003e choses the GStreamer pipeline’s\nh264 parser element, default is h264parse. Using quotes “…” allows\noptions to be added.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vd \u003cem\u003edecoder\u003c/em\u003e\u003c/strong\u003e chooses the GStreamer\npipeline’s h264 decoder element, instead of the default value\n“decodebin” which chooses it for you. Software decoding is done by\navdec_h264; various hardware decoders include: vaapih264dec, nvdec,\nnvh264dec, v4l2h264dec (these require that the appropriate hardware is\navailable). Using quotes “…” allows some parameters to be included with\nthe decoder name.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vc \u003cem\u003econverter\u003c/em\u003e\u003c/strong\u003e chooses the GStreamer\npipeline’s videoconverter element, instead of the default value\n“videoconvert”. When using Video4Linux2 hardware-decoding by a\nGPU,\u003ccode\u003e-vc  v4l2convert\u003c/code\u003e will also use the GPU for video\nconversion. Using quotes “…” allows some parameters to be included with\nthe converter name.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vs \u003cem\u003evideosink\u003c/em\u003e\u003c/strong\u003e chooses the GStreamer\nvideosink, instead of the default value “autovideosink” which chooses it\nfor you. Some videosink choices are: ximagesink, xvimagesink, vaapisink\n(for intel graphics), gtksink, glimagesink, waylandsink, osxvideosink\n(for macOS), kmssink (for systems without X11, like Raspberry Pi OS\nlite) or fpsdisplaysink (which shows the streaming framerate in fps).\nUsing quotes “…” allows some parameters to be included with the\nvideosink name. For example, \u003cstrong\u003efullscreen\u003c/strong\u003e mode is\nsupported by the vaapisink plugin, and is obtained using\n\u003ccode\u003e-vs \"vaapisink fullscreen=true\"\u003c/code\u003e; this also works with\n\u003ccode\u003ewaylandsink\u003c/code\u003e. The syntax of such options is specific to a\ngiven plugin (see GStreamer documentation), and some choices of\nvideosink might not work on your system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vs 0\u003c/strong\u003e suppresses display of streamed video. In\nmirror mode, the client’s screen is still mirrored at a reduced rate of\n1 frame per second, but is not rendered or displayed. This option should\nalways be used if the server is “headless” (with no attached screen to\ndisplay video), and only used to render audio, which will be AAC\nlossily-compressed audio in mirror mode with unrendered video, and\nsuperior-quality ALAC Apple Lossless audio in Airplay audio-only\nmode.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-v4l2\u003c/strong\u003e Video settings for hardware h264 video\ndecoding in the GPU by Video4Linux2. Equivalent to\n\u003ccode\u003e-vd v4l2h264dec -vc v4l2convert\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-bt709\u003c/strong\u003e A workaround for the failure of the older\nVideo4Linux2 plugin to recognize Apple’s use of an uncommon (but\npermitted) “full-range color” variant of the bt709 color standard for\ndigital TV. This is no longer needed by GStreamer-1.20.4 and backports\nfrom it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-rpi\u003c/strong\u003e Equivalent to “-v4l2” (Not valid for Raspberry\nPi model 5, and removed in UxPlay 1.67)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-rpigl\u003c/strong\u003e Equivalent to “-rpi -vs glimagesink”.\n(Removed since UxPlay 1.67)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-rpifb\u003c/strong\u003e Equivalent to “-rpi -vs kmssink” (Removed\nsince UxPlay 1.67)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-rpiwl\u003c/strong\u003e Equivalent to “-rpi -vs waylandsink”.\n(Removed since UxPlay 1.67)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-as \u003cem\u003eaudiosink\u003c/em\u003e\u003c/strong\u003e chooses the GStreamer\naudiosink, instead of letting autoaudiosink pick it for you. Some\naudiosink choices are: pulsesink, alsasink, pipewiresink, osssink,\noss4sink, jackaudiosink, osxaudiosink (for macOS), wasapisink,\ndirectsoundsink (for Windows). Using quotes “…” might allow some\noptional parameters (e.g. \u003ccode\u003e-as \"alsasink device=...\"\u003c/code\u003e to\nspecify a non-default output device). The syntax of such options is\nspecific to a given plugin (see GStreamer documentation), and some\nchoices of audiosink might not work on your system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-as 0\u003c/strong\u003e (or just \u003cstrong\u003e-a\u003c/strong\u003e) suppresses\nplaying of streamed audio, but displays streamed video.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-al \u003cem\u003ex\u003c/em\u003e\u003c/strong\u003e specifies an audio latency \u003cem\u003ex\u003c/em\u003e\nin (decimal) seconds in Audio-only (ALAC), that is reported to the\nclient. Values in the range [0.0, 10.0] seconds are allowed, and will be\nconverted to a whole number of microseconds. Default is 0.25 sec (250000\nusec). \u003cem\u003e(However, the client appears to ignore this reported latency,\nso this option seems non-functional.)\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-ca \u003cem\u003efilename\u003c/em\u003e\u003c/strong\u003e provides a file (where\n\u003cem\u003efilename\u003c/em\u003e can include a full path) used for output of “cover\nart” (from Apple Music, \u003cem\u003eetc.\u003c/em\u003e,) in audio-only ALAC mode. This\nfile is overwritten with the latest cover art as it arrives. Cover art\n(jpeg format) is discarded if this option is not used. Use with a image\nviewer that reloads the image if it changes, or regularly (\u003cem\u003ee.g.\u003c/em\u003e\nonce per second.). To achieve this, run\n“\u003ccode\u003euxplay -ca [path/to/]filename \u0026amp;\u003c/code\u003e” in the background,\nthen run the the image viewer in the foreground. Example, using\n\u003ccode\u003efeh\u003c/code\u003e as the viewer: run\n“\u003ccode\u003efeh -R 1 [path/to/]filename\u003c/code\u003e” (in the same terminal window\nin which uxplay was put into the background). To quit, use\n\u003ccode\u003ectrl-C fg ctrl-C\u003c/code\u003e to terminate the image viewer, bring\n\u003ccode\u003euxplay\u003c/code\u003e into the foreground, and terminate it too.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-reset n\u003c/strong\u003e sets a limit of \u003cem\u003en\u003c/em\u003e consecutive\ntimeout failures of the client to respond to ntp requests from the\nserver (these are sent every 3 seconds to check if the client is still\npresent, and synchronize with it). After \u003cem\u003en\u003c/em\u003e failures, the client\nwill be presumed to be offline, and the connection will be reset to\nallow a new connection. The default value of \u003cem\u003en\u003c/em\u003e is 5; the value\n\u003cem\u003en\u003c/em\u003e = 0 means “no limit” on timeouts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-nofreeze\u003c/strong\u003e closes the video window after a reset due\nto ntp timeout (default is to leave window open to allow a smoother\nreconection to the same client). This option may be useful in fullscreen\nmode.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-nc\u003c/strong\u003e maintains previous UxPlay \u0026lt; 1.45 behavior\nthat does \u003cstrong\u003enot close\u003c/strong\u003e the video window when the the\nclient sends the “Stop Mirroring” signal. \u003cem\u003eThis option is currently\nused by default in macOS, as the window created in macOS by GStreamer\ndoes not terminate correctly (it causes a segfault) if it is still open\nwhen the GStreamer pipeline is closed.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-nohold\u003c/strong\u003e Drops the current connection when a new\nclient attempts to connect. Without this option, the current client\nmaintains exclusive ownership of UxPlay until it disconnects.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-restrict\u003c/strong\u003e Restrict clients allowed to connect to\nthose specified by \u003ccode\u003e-allow \u0026lt;deviceID\u0026gt;\u003c/code\u003e. The deviceID\nhas the form of a MAC address which is displayed by UxPlay when the\nclient attempts to connect, and appears to be immutable. It has the\nformat \u003ccode\u003eXX:XX:XX:XX:XX:XX\u003c/code\u003e, X = 0-9,A-F, and is possibly the\n“true” hardware MAC address of the device. Note that iOS clients\ngenerally expose different random “private Wi_Fi addresses” (“fake” MAC\naddresses) to different networks (for privacy reasons, to prevent\ntracking), which may change, and do not correpond to the deviceID.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-restrict no\u003c/strong\u003e Remove restrictions (default). This is\nuseful as a command-line argument to overide restrictions set in the\nStartup file.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-allow \u003cem\u003eid\u003c/em\u003e\u003c/strong\u003e Adds the deviceID = \u003cem\u003eid\u003c/em\u003e\nto the list of allowed clients when client restrictions are being\nenforced. Usually this will be an entry in the uxplayrc startup\nfile.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-block \u003cem\u003eid\u003c/em\u003e\u003c/strong\u003e Always block clients with\ndeviceID = \u003cem\u003eid\u003c/em\u003e, even when client restrictions are not being\nenforced generally. Usually this will be an entry in the uxplayrc\nstartup file.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-FPSdata\u003c/strong\u003e Turns on monitoring of regular reports\nabout video streaming performance that are sent by the client. These\nwill be displayed in the terminal window if this option is used. The\ndata is updated by the client at 1 second intervals.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-fps n\u003c/strong\u003e sets a maximum frame rate (in frames per\nsecond) for the AirPlay client to stream video; n must be a whole number\nless than 256. (The client may choose to serve video at any frame rate\nlower than this; default is 30 fps.) A setting of 60 fps may give you\nimproved video but is not recommended on Raspberry Pi. A setting below\n30 fps might be useful to reduce latency if you are running more than\none instance of uxplay at the same time. \u003cem\u003eThis setting is only an\nadvisory to the client device, so setting a high value will not force a\nhigh framerate.\u003c/em\u003e (You can test using “-vs fpsdisplaysink” to see\nwhat framerate is being received, or use the option -FPSdata which\ndisplays video-stream performance data continuously sent by the client\nduring video-streaming.)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-f {H|V|I}\u003c/strong\u003e implements “videoflip” image transforms:\nH = horizontal flip (right-left flip, or mirror image); V = vertical\nflip ; I = 180 degree rotation or inversion (which is the combination of\nH with V).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-r {R|L}\u003c/strong\u003e 90 degree Right (clockwise) or Left\n(counter-clockwise) rotations; these image transforms are carried out\nafter any \u003cstrong\u003e-f\u003c/strong\u003e transforms.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-m [mac]\u003c/strong\u003e changes the MAC address (Device ID) used by\nUxPlay (default is to use the true hardware MAC address reported by the\nhost computer’s network card). (Different server_name, MAC addresses,\nand network ports are needed for each running uxplay if you attempt to\nrun more than one instance of uxplay on the same computer.) If [mac] (in\nform xx:xx:xx:xx:xx:xx, 6 hex octets) is not given, a random MAC address\nis generated. If UxPlay fails to find the true MAC address of a network\ncard, (more specifically, the MAC address used by the first active\nnetwork interface detected) a random MAC address will be used even if\noption \u003cstrong\u003e-m\u003c/strong\u003e was not specified. (Note that a random MAC\naddress will be different each time UxPlay is started).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-key [\u003cem\u003efilename\u003c/em\u003e]\u003c/strong\u003e: This (more secure) option\nfor generating and storing a persistant public key (needed for the -pin\noption) has been replaced by default with a (less secure) method which\ngenerates a key from the server’s “device ID” (MAC address, which can be\nchanged with the -m option, conveniently as a startup file option). When\nthe -key option is used, a securely generated keypair is generated and\nstored in \u003ccode\u003e$HOME/.uxplay.pem\u003c/code\u003e, if that file does not exist,\nor read from it, if it exists. (Optionally, the key can be stored in\n\u003cem\u003efilename\u003c/em\u003e.) This method is more secure than the new default\nmethod, (because the Device ID is broadcast in the DNS_SD announcement)\nbut still leaves the private key exposed to anyone who can access the\npem file. This option should be set in the UxPlay startup file as a line\n“key” or “key \u003cem\u003efilename\u003c/em\u003e” (no initial “-”), where\n\u003cem\u003efilename\u003c/em\u003e is a full path which should be enclosed in quotes\n(\u003ccode\u003e\"....\"\u003c/code\u003e) if it contains any blank spaces. \u003cstrong\u003eBecause\nthe default method is simpler, and security of client access to uxplay\nis unlikely to be an important issue, the -key option is no longer\nrecommended\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-dacp [\u003cem\u003efilename\u003c/em\u003e]\u003c/strong\u003e: Export current client\nDACP-ID and Active-Remote key to file: default is $HOME/.uxplay.dacp.\n(optionally can be changed to \u003cem\u003efilename\u003c/em\u003e). Can be used by remote\ncontrol applications. File is transient: only exists while client is\nconnected.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-vdmp\u003c/strong\u003e Dumps h264 video to file videodump.h264. -vdmp\nn dumps not more than n NAL units to videodump.x.h264; x= 1,2,…\nincreases each time a SPS/PPS NAL unit arrives. To change the name\n\u003cem\u003evideodump\u003c/em\u003e, use -vdmp [n] \u003cem\u003efilename\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-admp\u003c/strong\u003e Dumps audio to file audiodump.x.aac (AAC-ELD\nformat audio), audiodump.x.alac (ALAC format audio) or audiodump.x.aud\n(other-format audio), where x = 1,2,3… increases each time the audio\nformat changes. -admp \u003cem\u003en\u003c/em\u003e restricts the number of packets dumped\nto a file to \u003cem\u003en\u003c/em\u003e or less. To change the name \u003cem\u003eaudiodump\u003c/em\u003e,\nuse -admp [n] \u003cem\u003efilename\u003c/em\u003e. \u003cem\u003eNote that (unlike dumped video) the\ndumped audio is currently only useful for debugging, as it is not\ncontainerized to make it playable with standard audio players.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e-d\u003c/strong\u003e Enable debug output. Note: this does not show\nGStreamer error or debug messages. To see GStreamer error and warning\nmessages, set the environment variable GST_DEBUG with “export\nGST_DEBUG=2” before running uxplay. To see GStreamer information\nmessages, set GST_DEBUG=4; for DEBUG messages, GST_DEBUG=5; increase\nthis to see even more of the GStreamer inner workings.\u003c/p\u003e\n\u003ch1 id=\"troubleshooting\"\u003eTroubleshooting\u003c/h1\u003e\n\u003cp\u003eNote: \u003ccode\u003euxplay\u003c/code\u003e is run from a terminal command line, and\ninformational messages are written to the terminal.\u003c/p\u003e\n\u003ch3 id=\"problems-in-compiling-uxplay.\"\u003e0. Problems in compiling\nUxPlay.\u003c/h3\u003e\n\u003cp\u003eOne user (on Ubuntu) found compilation failed with messages about\nlinking to “usr/local/lib/libcrypto.a” and “zlib”. This was because (in\naddition to the standard ubuntu installation of libssl-dev), the user\nwas unaware that a second installation with libcrypto in /usr/local was\npresent. Solution: when more than one installation of OpenSSL is\npresent, set the environment variable OPEN_SSL_ROOT_DIR to point to the\ncorrect one; on 64-bit Ubuntu, this is done by running\n\u003ccode\u003eexport OPENSSL_ROOT_DIR=/usr/lib/X86_64-linux-gnu/\u003c/code\u003e before\nrunning cmake.\u003c/p\u003e\n\u003ch3 id=\"avahidns_sd-bonjourzeroconf-issues\"\u003e1. \u003cstrong\u003eAvahi/DNS_SD\nBonjour/Zeroconf issues\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eThe DNS_SD Service-Discovery (“Bonjour” or “Zeroconf”) service is\nrequired for UxPlay to work. On Linux, it will be usually provided by\nAvahi, and to troubleshoot this, you should use the tool\n\u003ccode\u003eavahi-browse\u003c/code\u003e. (You may need to install a separate package\nwith a name like \u003ccode\u003eavahi-utils\u003c/code\u003e to get this.)\u003c/p\u003e\n\u003cp\u003eOn Linux, make sure Avahi is installed, and start the avahi-daemon\nservice on the system running uxplay (your distribution will document\nhow to do this, for example:\n\u003ccode\u003esudo systemctl \u0026lt;cmd\u0026gt; avahi-daemon\u003c/code\u003e or\n\u003ccode\u003esudo service avahi-daemon \u0026lt;cmd\u0026gt;\u003c/code\u003e, with\n\u003ccode\u003e\u0026lt;cmd\u0026gt;\u003c/code\u003e one of enable, disable, start, stop, status.\nYou might need to edit the avahi-daemon.conf file (it is typically in\n/etc/avahi/, find it with\n“\u003ccode\u003esudo find /etc -name avahi-daemon.conf\u003c/code\u003e”): make sure that\n“disable-publishing” is \u003cstrong\u003enot\u003c/strong\u003e a selected option). Some\nsystems may instead use the mdnsd daemon as an alternative to provide\nDNS-SD service. (FreeBSD offers both alternatives, but only Avahi was\ntested; see \u003ca\nhref=\"https://gist.github.com/reidransom/6033227\"\u003ehere\u003c/a\u003e.)\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003euxplay starts, but either stalls or stops after “Initialized\nserver socket(s)” appears (\u003cem\u003ewithout the server name showing on the\nclient\u003c/em\u003e)\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf UxPlay stops with the “No DNS-SD Server found” message, this means\nthat your network \u003cstrong\u003edoes not have a running Bonjour/zeroconf\nDNS-SD server.\u003c/strong\u003e Before v1.60, UxPlay used to stall silently if\nDNS-SD service registration failed, but now stops with an error message\nreturned by the DNSServiceRegister function: kDNSServiceErr_Unknown if\nno DNS-SD server was found: \u003cem\u003e(A NixOS user found that in NixOS, this\nerror can also occur if avahi-daemon service IS running with publishing\nenabled, but reports “the error disappeared on NixOS by setting\nservices.avahi.openFirewall to true”.)\u003c/em\u003e Other mDNS error codes are\nin the range FFFE FF00 (-65792) to FFFE FFFF (-65537), and are listed in\nthe dnssd.h file. An older version of this (the one used by avahi) is\nfound \u003ca\nhref=\"https://github.com/lathiat/avahi/blob/master/avahi-compat-libdns_sd/dns_sd.h\"\u003ehere\u003c/a\u003e.\nA few additional error codes are defined in a later version from \u003ca\nhref=\"https://opensource.apple.com/source/mDNSResponder/mDNSResponder-544/mDNSShared/dns_sd.h.auto.html\"\u003eApple\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eIf UxPlay stalls \u003cem\u003ewithout an error message\u003c/em\u003e and \u003cem\u003ewithout\nthe server name showing on the client\u003c/em\u003e, \u003cstrong\u003ethis is a network\nproblem\u003c/strong\u003e (if your UxPlay version is older than 1.60, it is also\nthe behavior when no DNS-SD server is found.)\u003c/p\u003e\n\u003cp\u003eA useful tool for examining such network problems from the client end\nis the (free) Discovery DNS-SD browser \u003ca\nhref=\"https://apps.apple.com/us/developer/lily-ballard/id305441020\"\u003eavailable\nin the Apple App Store\u003c/a\u003e for both iOS (works on iPadOS too) and\nmacOS.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSome users using dual-band (2.4GHz/5GHz) routers have reported that\nclients using the 5GHz band (sometimes) “fail to see UxPlay” (i.e., do\nnot get a response to their mDNS queries), but the 2.4GHz band works.\nOther projects using Bonjour/mDNS have had similar reports; the issue\nseems to be router-specific, perhaps related to “auto” rather than fixed\nchannel selection (5GHz has many more channels to switch between), or\nchannel width selections; one speculation is that since mDNS uses UDP\nprotocol (where “lost” messages are not resent), a mDNS query might get\nlost if channel switching occurs during the query.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf your router has this problem, a reported “fix” is to (at least on\n5GHz) use fixed channel and/or fixed (not dynamic) channel width.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAvahi works at first, but new clients do not see UxPlay, or\nclients that initially saw it stop doing so after they\ndisconnect\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis is usually because Avahi is only using the “loopback” network\ninterface, and is not receiving mDNS queries from new clients that were\nnot listening when UxPlay started.\u003c/p\u003e\n\u003cp\u003eTo check this, after starting uxplay, use the utility\n\u003ccode\u003eavahi-browse -a -t\u003c/code\u003e \u003cstrong\u003ein a different terminal\nwindow\u003c/strong\u003e on the server to verify that the UxPlay AirTunes and\nAirPlay services are correctly registered (only the AirTunes service is\nused in the “Legacy” AirPlay Mirror mode used by UxPlay, but the AirPlay\nservice is used for the initial contact).\u003c/p\u003e\n\u003cp\u003eThe results returned by avahi-browse should show entries for uxplay\nlike\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e+   eno1 IPv6 UxPlay                                        AirPlay Remote Video local\n+   eno1 IPv4 UxPlay                                        AirPlay Remote Video local\n+     lo IPv4 UxPlay                                        AirPlay Remote Video local\n+   eno1 IPv6 863EA27598FE@UxPlay                           AirTunes Remote Audio local\n+   eno1 IPv4 863EA27598FE@UxPlay                           AirTunes Remote Audio local\n+     lo IPv4 863EA27598FE@UxPlay                           AirTunes Remote Audio local\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIf only the loopback (“lo”) entries are shown, a firewall on the\nUxPlay host is probably blocking full DNS-SD service, and you need to\nopen the default UDP port 5353 for mDNS requests, as loopback-based\nDNS-SD service is unreliable.\u003c/p\u003e\n\u003cp\u003eIf the UxPlay services are listed by avahi-browse as above, but are\nnot seen by the client, the problem is likely to be a problem with the\nlocal network.\u003c/p\u003e\n\u003ch3\nid=\"uxplay-starts-but-stalls-after-initialized-server-sockets-appears-with-the-server-name-showing-on-the-client-but-the-client-fails-to-connect-when-the-uxplay-server-is-selected.\"\u003e2.\nuxplay starts, but stalls after “Initialized server socket(s)” appears,\n\u003cem\u003ewith the server name showing on the client\u003c/em\u003e (but the client\nfails to connect when the UxPlay server is selected).\u003c/h3\u003e\n\u003cp\u003eThis shows that a \u003cem\u003eDNS-SD\u003c/em\u003e service is working, clients hear\nUxPlay is available, but the UxPlay server is not receiving the response\nfrom the client. This is usually because a firewall on the server is\nblocking the connection request from the client. (One user who insisted\nthat the firewall had been turned off turned out to have had\n\u003cem\u003etwo\u003c/em\u003e active firewalls (\u003cem\u003efirewalld\u003c/em\u003e and \u003cem\u003eufw\u003c/em\u003e)\n\u003cem\u003eboth\u003c/em\u003e running on the server!) If possible, either turn off the\nfirewall to see if that is the problem, or get three consecutive network\nports, starting at port n, all three in the range 1024-65535, opened for\nboth tcp and udp, and use “uxplay -p n” (or open UDP 7011,6001,6000 TCP\n7100,7000,7001 and use “uxplay -p”).\u003c/p\u003e\n\u003cp\u003eIf you are \u003cem\u003ereally\u003c/em\u003e sure there is no firewall, you may need to\ninvestigate your network transmissions with a tool like netstat, but\nalmost always this is a firewall issue.\u003c/p\u003e\n\u003ch3 id=\"problems-after-the-client-server-connection-has-been-made\"\u003e3.\nProblems \u003cem\u003eafter\u003c/em\u003e the client-server connection has been made:\u003c/h3\u003e\n\u003cp\u003eIf you do \u003cem\u003enot\u003c/em\u003e see the message\n\u003ccode\u003eraop_rtp_mirror starting mirroring\u003c/code\u003e, something went wrong\nbefore the client-server negotiations were finished. For such problems,\nuse “uxplay -d” (debug log option) to see what is happening: it will\nshow how far the connection process gets before the failure occurs. You\ncan compare your debug output to that from a successful start of UxPlay\nin the \u003ca href=\"https://github.com/FDH2/UxPlay/wiki\"\u003eUxPlay\nWiki\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIf UxPlay reports that mirroring started, but you get no\nvideo or audio, the problem is probably from a GStreamer plugin that\ndoesn’t work on your system\u003c/strong\u003e (by default, GStreamer uses the\n“autovideosink” and “autoaudiosink” algorithms to guess what are the\n“best” plugins to use on your system). A different reason for no audio\noccurred when a user with a firewall only opened two udp network ports:\n\u003cstrong\u003ethree\u003c/strong\u003e are required (the third one receives the audio\ndata).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRaspberry Pi\u003c/strong\u003e devices (\u003cem\u003ePi 4B+ and earlier: this\ndoes not apply to the Pi 5, which does not provide hardware h264\ndecoding, and does not need it\u003c/em\u003e) work best with hardware GPU h264\nvideo decoding if the Video4Linux2 plugin in GStreamer v1.20.x or\nearlier has been patched (see the UxPlay \u003ca\nhref=\"https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches\"\u003eWiki\u003c/a\u003e\nfor patches). This is fixed in GStreamer-1.22, and by backport patches\nfrom this in distributions such as Raspberry Pi OS (Bullseye):\n\u003cstrong\u003euse option \u003ccode\u003e-bt709\u003c/code\u003e with the GStreamer-1.18.4 from\nRaspberry Pi OS\u003c/strong\u003e. This also needs the bcm2835-codec kernel\nmodule that is not in the standard Linux kernel (it is available in\nRaspberry Pi OS, Ubuntu and Manjaro).\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eIf this kernel module is not available in your Raspberry Pi\noperating system, or if GStreamer \u0026lt; 1.22 is not patched, use option\n\u003ccode\u003e-avdec\u003c/code\u003e for software h264-decoding.\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSometimes “autovideosink” may select the OpenGL renderer\n“glimagesink” which may not work correctly on your system. Try the\noptions “-vs ximagesink” or “-vs xvimagesink” to see if using one of\nthese fixes the problem.\u003c/p\u003e\n\u003cp\u003eOther reported problems are connected to the GStreamer VAAPI plugin\n(for hardware-accelerated Intel graphics, but not NVIDIA graphics). Use\nthe option “-avdec” to force software h264 video decoding: this should\nprevent autovideosink from selecting the vaapisink videosink.\nAlternatively, find out if the gstreamer1.0-vaapi plugin is installed,\nand if so, uninstall it. (If this does not fix the problem, you can\nreinstall it.)\u003c/p\u003e\n\u003cp\u003eThere are some reports of other GStreamer problems with\nhardware-accelerated Intel HD graphics. One user (on Debian) solved this\nwith “sudo apt install intel-media-va-driver-non-free”. This is a driver\nfor 8’th (or later) generation “*-lake” Intel chips, that seems to be\nrelated to VAAPI accelerated graphics.\u003c/p\u003e\n\u003cp\u003eIf you \u003cem\u003edo\u003c/em\u003e have Intel HD graphics, and have installed the\nvaapi plugin, but \u003ccode\u003e-vs vaapisink\u003c/code\u003e does not work, check that\nvaapi is not “blacklisted” in your GStreamer installation: run\n\u003ccode\u003egst-inspect-1.0 vaapi\u003c/code\u003e, if this reports\n\u003ccode\u003e0 features\u003c/code\u003e, you need to\n\u003ccode\u003eexport GST_VAAPI_ALL_DRIVERS=1\u003c/code\u003e before running uxplay, or\nset this in the default environment.\u003c/p\u003e\n\u003cp\u003eYou can try to fix audio or video problems by using the\n“\u003ccode\u003e-as \u0026lt;audiosink\u0026gt;\u003c/code\u003e” or\n“\u003ccode\u003e-vs \u0026lt;videosink\u0026gt;\u003c/code\u003e” options to choose the GStreamer\naudiosink or videosink , rather than letting GStreamer choose one for\nyou. (See above, in \u003ca href=\"#starting-and-running-uxplay\"\u003eStarting and\nrunning UxPlay\u003c/a\u003e for choices of \u003ccode\u003e\u0026lt;audiosink\u0026gt;\u003c/code\u003e or\n\u003ccode\u003e\u0026lt;videosink\u0026gt;\u003c/code\u003e.)\u003c/p\u003e\n\u003cp\u003eThe “OpenGL renderer” window created on Linux by “-vs glimagesink”\nsometimes does not close properly when its “close” button is clicked.\n(this is a GStreamer issue). You may need to terminate uxplay with\nCtrl-C to close a “zombie” OpenGl window. If similar problems happen\nwhen the client sends the “Stop Mirroring” signal, try the no-close\noption “-nc” that leaves the video window open.\u003c/p\u003e\n\u003ch3 id=\"gstreamer-issues-missing-plugins-etc.\"\u003e4. GStreamer issues\n(missing plugins, etc.):\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eclearing the user’s GStreamer cache with\n\u003ccode\u003erm -rf ~/.cache/gstreamer-1.0/*\u003c/code\u003e may be the solution to\nproblems where gst-inspect-1.0 does not show a plugin that you believe\nis installed. The cache will be regenerated next time GStreamer is\nstarted. \u003cstrong\u003eThis is the solution to puzzling problems that turn out\nto come from corruption of the cache, and should be tried\nfirst.\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf UxPlay fails to start, with a message that a required GStreamer\nplugin (such as “libav”) was not found, first check with the GStreamer\ntool gst-inspect-1.0 to see what GStreamer knows is available. (You may\nneed to install some additional GStreamer “tools” package to get\ngst-inspect-1.0). For, \u003cem\u003ee.g.\u003c/em\u003e a libav problem, check with\n“\u003ccode\u003egst-inspect-1.0 libav\u003c/code\u003e”. If it is not shown as available to\nGStreamer, but your package manager shows the relevant package as\ninstalled (as one user found), try entirely removing and reinstalling\nthe package. That user found that a solution to a “\u003cstrong\u003eRequired\ngstreamer plugin ‘libav’ not found\u003c/strong\u003e” message that kept recurring\nwas to clear the user’s gstreamer cache.\u003c/p\u003e\n\u003cp\u003eIf it fails to start with an error like\n‘\u003ccode\u003eno element \"avdec_aac\"\u003c/code\u003e’ this is because even though\ngstreamer-libav is installed. it is incomplete because some plugin\nfeatures are missing: “\u003ccode\u003egst-inspect-1.0 | grep avdec_aac\u003c/code\u003e”\nwill show if avdec_aac is available. Unlike other GStreamer plugins, the\nlibav plugin is a front end to FFmpeg codecs which provide avdec_*.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eSome distributions (RedHat, SUSE, etc) provide incomplete\nversions of FFmpeg because of patent issues with codecs used by certain\nplugins. In those cases there will be some “extra package” provider like\n\u003ca href=\"https://rpmfusion.org\"\u003eRPM fusion\u003c/a\u003e (RedHat), \u003ca\nhref=\"http://packman.links2linux.org/\"\u003epackman\u003c/a\u003e (SUSE) where you can\nget complete packages (your distribution will usually provide\ninstructions for this, Mageia puts them in an optional “tainted” repo).\nThe packages needed may be “ffmpeg*” or “libav*” packages: the GStreamer\nlibav plugin package does not contain any codecs itself, it just\nprovides a way for GStreamer to use ffmpeg/libav codec libraries which\nmust be installed separately. For similar reasons, distributions may\nship incomplete packages of GStreamer “plugins-bad”. Use user on Fedora\nthought they had installed from rpmfusion, but the system had not\nobeyed: \u003cem\u003e“Adding –allowerasing to the dnf command fixed it after a\nrestart”\u003c/em\u003e.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003estarting with release UxPlay-1.65.3, UxPlay will continue to\nfunction, but without audio in mirror mode, if avdec_aac is\nmissing.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTo troubleshoot GStreamer execute “export GST_DEBUG=2” to set the\nGStreamer debug-level environment-variable in the terminal where you\nwill run uxplay, so that you see warning and error messages; see \u003ca\nhref=\"https://gstreamer.freedesktop.org/documentation/tutorials/basic/debugging-tools.html\"\u003eGStreamer\ndebugging tools\u003c/a\u003e for how to see much more of what is happening inside\nGStreamer. Run “gst-inspect-1.0” to see which GStreamer plugins are\ninstalled on your system.\u003c/p\u003e\n\u003cp\u003eSome extra GStreamer packages for special plugins may need to be\ninstalled (or reinstalled: a user using a Wayland display system as an\nalternative to X11 reported that after reinstalling Lubuntu 18.4, UxPlay\nwould not work until gstreamer1.0-x was installed, presumably for\nWayland’s X11-compatibility mode). Different distributions may break up\nGStreamer 1.x into packages in different ways; the packages listed above\nin the build instructions should bring in other required GStreamer\npackages as dependencies, but will not install all possible plugins.\u003c/p\u003e\n\u003cp\u003eThe GStreamer video pipeline, which is shown in the initial output\nfrom \u003ccode\u003euxplay -d\u003c/code\u003e, has the default form\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eappsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! autovideosink name=video_sink sync=false\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe pipeline is fully configurable: default elements “h264parse”,\n“decodebin”, “videoconvert”, and “autovideosink” can respectively be\nreplaced by using uxplay options \u003ccode\u003e-vp\u003c/code\u003e, \u003ccode\u003e-vd\u003c/code\u003e,\n\u003ccode\u003e-vc\u003c/code\u003e, and \u003ccode\u003e-vs\u003c/code\u003e, if there is any need to modify\nit (entries can be given in quotes “…” to include options).\u003c/p\u003e\n\u003ch3 id=\"mirror-screen-freezes-a-network-problem\"\u003e5. Mirror screen\nfreezes (a network problem):\u003c/h3\u003e\n\u003cp\u003eThis can happen if the TCP video stream from the client stops\narriving at the server, probably because of network problems (the UDP\naudio stream may continue to arrive). At 3-second intervals, UxPlay\nchecks that the client is still connected by sending it a request for a\nNTP time signal. If a reply is not received from the client within a 0.3\nsec time-window, an “ntp timeout” is registered. If a certain number\n(currently 5) of consecutive ntp timeouts occur, UxPlay assumes that the\nclient is “dead”, and resets the connection, becoming available for\nconnection to a new client, or reconnection to the previous one.\nSometimes the connection may recover before the timeout limit is\nreached, and if the default limit is not right for your network, it can\nbe modified using the option “-reset \u003cem\u003en\u003c/em\u003e”, where \u003cem\u003en\u003c/em\u003e is\nthe desired timeout-limit value (\u003cem\u003en\u003c/em\u003e = 0 means “no limit”). If\nthe connection starts to recover after ntp timeouts, a corrupt video\npacket from before the timeout may trigger a “connection reset by peer”\nerror, which also causes UxPlay to reset the connection.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhen the connection is reset, the “frozen” mirror screen of the\nprevious connection is left in place, but does \u003cstrong\u003enot\u003c/strong\u003e\nblock new connections, and will be taken over by a new client connection\nwhen it is made.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\nid=\"protocol-issues-with-decryption-of-the-encrypted-audio-and-video-streams-sent-by-the-client.\"\u003e6.\nProtocol issues (with decryption of the encrypted audio and video\nstreams sent by the client).\u003c/h3\u003e\n\u003cp\u003eA protocol failure may trigger an unending stream of error messages,\nand means that the audio decryption key (also used in video decryption)\nwas not correctly extracted from data sent by the client.\u003c/p\u003e\n\u003cp\u003eThe protocol was modifed in UxPlay-1.65 after it was discovered that\nthe client-server “pairing” step could be avoided (leading to a much\nquicker connection setup, without a 5 second delay) by disabling\n“Supports Legacy Pairing” (bit 27) in the “features” code UxPlay\nadvertises on DNS-SD Service Discovery. Most clients will then not\nattempt the setup of a “shared secret key” when pairing, which is used\nby AppleTV for simultaneous handling of multiple clients (UxPlay only\nsupports one client at a time). \u003cstrong\u003eThis change is now well-tested,\nbut in case it causes any protocol failures, UxPlay can be reverted to\nthe previous behavior by uncommenting the previous “FEATURES_1” setting\n(and commenting out the new one) in lib/dnssdint.h, and then rebuilding\nUxPlay.\u003c/strong\u003e (“Pairing” is re-enabled when the new Apple-style\none-time “pin” authentication is activated by running UxPlay with the\n“-pin” option introduced in UxPlay 1.67.)\u003c/p\u003e\n\u003cp\u003eProtocol failure should not happen for iOS 9.3 or later clients.\nHowever, if a client uses the same older version of the protocol that is\nused by the Windows-based AirPlay client emulator \u003cem\u003eAirMyPC\u003c/em\u003e, the\nprotocol can be switched to the older version by the setting\n\u003ccode\u003eOLD_PROTOCOL_CLIENT_USER_AGENT_LIST\u003c/code\u003e in\n\u003ccode\u003eUxPlay/lib/global.h\u003c/code\u003e. UxPlay reports the client’s “User\nAgent” string when it connects. If some other client also fails to\ndecrypt all audio and video, try adding its “User Agent” string in place\nof “xxx” in the entry “AirMyPC/2.0;xxx” in global.h and rebuild\nuxplay.\u003c/p\u003e\n\u003cp\u003eNote that for DNS-SD Service Discovery, Uxplay declares itself to be\nan AppleTV3,2 (a 32 bit device) with a sourceVersion 220.68; this can\nalso be changed in global.h. UxPlay also works if it declares itself as\nan AppleTV6,2 with sourceVersion 380.20.1 (an AppleTV 4K 1st gen,\nintroduced 2017, running tvOS 12.2.1), so it does not seem to matter\nwhat version UxPlay claims to be.\u003c/p\u003e\n\u003ch1 id=\"changelog\"\u003eChangelog\u003c/h1\u003e\n\u003cp\u003e1.70 2024-10-04 Add support for 4K (h265) video (resolution 3840 x\n2160). Fix issue with GStreamer \u0026gt;= 1.24 when client sleeps, then\nwakes.\u003c/p\u003e\n\u003cp\u003e1.69 2024-08-09 Internal improvements (e.g. in -nohold option,\nidentifying GStreamer videosink selected by autovideosink, finding X11\ndisplay) in anticipation of future HLS video support. New -nofreeze\noption to not leave frozen video in place when a network connection is\nreset. Fixes for GStreamer-1.24.x changes.\u003c/p\u003e\n\u003cp\u003e1.68 2023-12-31 New simpler (default) method for generating a\npersistent public key from the server MAC address (which can now be set\nwith the -m option). (The previous method is still available with -key\noption). New option -reg to maintain a register of pin-authenticated\nclients. Corrected volume-control: now interprets AirPlay volume range\n-30dB:0dB as decibel gain attenuation, with new option -db low[:high]\nfor “flat” rescaling of the dB range. Add -taper option for a “tapered”\nAirPlay volume-control profile.\u003c/p\u003e\n\u003cp\u003e1.67 2023-11-30 Add support for Apple-style one-time pin\nauthentication of clients with option “-pin”: (uses SRP6a authentication\nprotocol and public key persistence). Detection with error message of\n(currently) unsupported H265 video when requesting high resolution over\nwired ethernet. Removed rpi* options (which are not valid with new\nRaspberry Pi model 5, and can be replaced by combinations of other\noptions). Added optional argument “mac” to “-m” option, to specify a\nreplacement MAC address/Device ID. Update llhttp to v. 9.1.3. Add -dacp\noption for exporting current client DACP info (for remotes).\u003c/p\u003e\n\u003cp\u003e1.66 2023-09-05 Fix IPV6 support. Add option to restrict clients to\nthose on a list of allowed deviceIDs, or to block connections from\nclients on a list of blocked deviceIDs. Fix for #207 from \u003cspan\nclass=\"citation\" data-cites=\"thiccaxe\"\u003e@thiccaxe\u003c/span\u003e (screen lag in\nvsync mode after client wakes from sleep).\u003c/p\u003e\n\u003cp\u003e1.65.3 2023-07-23 Add RPM spec file; add warning if required\ngstreamer libav feature “avdec_aac” is missing: (this occurs in\nRPM-based distributions that ship an incomplete FFmpeg for Patent or\nLicense reasons, and rely on users installing an externally-supplied\ncomplete FFmpeg). Mirror-mode airplay will now work without audio if\navdec_aac is missing.\u003c/p\u003e\n\u003cp\u003e1.65 2023-06-03 Eliminate pair_setup part of connection protocol to\nallow faster connections with clients (thanks to \u003cspan class=\"citation\"\ndata-cites=\"shuax\"\u003e@shuax\u003c/span\u003e #176 for this discovery); to revert,\nuncomment a line in lib/dnssdint.h. Disconnect from audio device when\nconnection closes, to not block its use by other apps if uxplay is\nrunning but not connected. Fix for AirMyPC client (broken since 1.60),\nso its older non-NTP timestamp protocol works with -vsync. Corrected\nparsing of configuration file entries that were in quotes.\u003c/p\u003e\n\u003cp\u003e1.64 2023-04-23 Timestamp-based synchronization of audio and video is\nnow the default in Mirror mode. (Use “-vsync no” to restore previous\nbehavior.) A configuration file can now be used for startup options.\nAlso some internal cleanups and a minor bugfix that fixes #192.\u003c/p\u003e\n\u003cp\u003e1.63 2023-02-12 Reworked audio-video synchronization, with new\noptions -vsync (for Mirror mode) and -async (for Audio-Only mode, to\nsync with client video). Option -vsync makes software h264 decoding of\nstreamed videos with option -avdec viable on some recent Raspberry Pi\nmodels. Internal change: all times are now processed in nanoseconds\nunits. Removed -ao option introduced in 1.62.\u003c/p\u003e\n\u003cp\u003e1.62 2023-01-18 Added Audio-only mode time offset -ao x to allow user\nsynchronization of ALAC audio playing on the server with video, song\nlyrics, etc. playing on the client. x = 5.0 appears to be optimal in\nmany cases. Quality fixes: cleanup in volume changes, timestamps, some\nbugfixes.\u003c/p\u003e\n\u003cp\u003e1.61 2022-12-30 Removed -t option (workaround for an Avahi issue,\ncorrectly solved by opening network port UDP 5353 in firewall). Remove\n-g debug flag from CMAKE_CFLAGS. Postpend (instead of prepend) build\nenvironment CFLAGS to CMAKE_CFLAGS. Refactor parts of uxplay.cpp\u003c/p\u003e\n\u003cp\u003e1.60 2022-12-15 Added exit with error message if DNSServiceRegister\nfails (instead of just stalling). Test for Client’s attempt to using\nunsupported AirPlay 2 “REMOTE CONTROL” protocol (with no timing\nchannel), and exit if this occurs. Reworked metadata processing to\ncorrectly parse DMAP header (previous version worked with DMAP messages\ncurrently received, but was not correct).\u003c/p\u003e\n\u003cp\u003e1.59 2022-12-12 remove “ZOOMFIX” compile option and make compilation\nwith X11-dependence the default if X11 development libraries are\ndetected (this now also provides fullscreen mode with a F11 or Alt+Enter\nkey toggle); ZOOMFIX is now automatically applied for GStreamer \u0026lt;\n1.20. New cmake option -DNO_X11_DEPS compiles uxplay without X11\ndependence. Reworked internal metadata handling. Fix segfault with “-vs\n0”.\u003c/p\u003e\n\u003cp\u003e1.58 2022-10-29 Add option “-nohold” that ","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FFDH2%2FUxPlay","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FFDH2%2FUxPlay","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FFDH2%2FUxPlay/lists"}