diff --git a/README.html b/README.html index 9ebe47cc..f5b15918 100644 --- a/README.html +++ b/README.html @@ -1,6 +1,6 @@

UxPlay -1.63: AirPlay-Mirror and AirPlay-Audio server for Linux, macOS, and Unix +id="uxplay-1.64-airplay-mirror-and-airplay-audio-server-for-linux-macos-and-unix-now-also-runs-on-windows.">UxPlay +1.64: AirPlay-Mirror and AirPlay-Audio server for Linux, macOS, and Unix (now also runs on Windows).

Now @@ -83,12 +83,14 @@

Detailed description of href="https://github.com/FDH2/UxPlay">UxPlay site).

UxPlay is tested on a number of systems, including (among others) Debian 10.11 “Buster” and 11.2 “Bullseye”, Ubuntu 20.04 LTS and 22.04.1 -LTS, Linux Mint 20.3, Pop!_OS 22.04 (NVIDIA edition), Rocky Linux 8.6 (a -CentOS successor), Fedora 36, OpenSUSE 15.4, Arch Linux 22.10, macOS -12.3 (Intel and M1), FreeBSD 13.1, Windows 10 and 11 (64 bit).

+LTS, (also Ubuntu derivatives Linux Mint 20.3, Pop!_OS 22.04 (NVIDIA +edition)), Rocky Linux 9.1 (a CentOS successor), Fedora 36, OpenSUSE +15.4, Arch Linux 22.10, macOS 13.3 (Intel and M2), FreeBSD 13.2, Windows +10 and 11 (64 bit).

On Raspberry Pi 4 model B, it is tested on Raspberry Pi OS (Bullseye) -(32- and 64-bit), Ubuntu 22.10, Manjaro RPi4 23.02, and (without -hardware video decoding) on OpenSUSE 15.4.

+(32- and 64-bit), Ubuntu 22.04 and 22.10, Manjaro RPi4 23.02, and +(without hardware video decoding) on OpenSUSE 15.4. Also tested on +Raspberry Pi 3 model B+.

Its main use is to act like an AppleTV for screen-mirroring (with audio) of iOS/iPadOS/macOS clients (iPhone, iPod Touch, iPad, Mac computers) on the server display of a host running Linux, macOS, or @@ -356,6 +358,14 @@

Installing graphics).

Starting and running UxPlay

+

Since UxPlay-1.64, UxPlay can be started with options read from a +configuration file, which will be the first found of (1) a file with a +path given by environment variable $UXPLAYRC, (2) +~/.uxplayrc in the user’s home directory (“~”), (3) +~/.config/uxplayrc. The format is one option per line, +omitting the initial "-" of the command-line option. Lines +in the configuration file beginning with "#" are treated as +comments and ignored.

Run uxplay in a terminal window. On some systems, you can toggle into and out of fullscreen mode with F11 or (held-down left Alt)+Enter keys. Use Ctrl-C (or close the window) to terminate it @@ -381,31 +391,37 @@

Starting and running UxPlay

requests a connection, it removes the current client and takes over.

  • In Mirror mode, GStreamer has a choice of two -methods to play video with its accompanying audio: the default mode -(“sync=false”) just plays both streams as soon as possible after they -arrive, and the (“sync=true”) mode used by the -vsync -option (first introduced in UxPlay-1.63), uses the timestamps in the -streams sent by the Airplay client to play audio and video frames -together at the correct time. For playing long video sequences on any -UxPlay server, use the -vsync option: this may become the default in -future UxPlay releases.

    • +methods to play video with its accompanying audio: prior to UxPlay-1.64, +the video and audio streams were both played as soon as possible after +they arrived (the GStreamer “sync=false” method), with a +GStreamer internal clock used to try to keep them synchronized. +Starting with UxPlay-1.64, the other method (GStreamer’s +“sync-true” mode), which uses timestamps in the audio and video +streams sent by the client, is the new default. On +low-decoding-power UxPlay hosts (such as Raspberry Pi 3 models) this +will drop video frames that cannot be decoded in time to play with the +audio, making the video jerky, but still synchronized.

    -

    Provided the UxPlay host can process the video sufficently fast, the -default “sync=false” mode seems to work well at keeping video and audio -synchronized, but on lower decoding-power systems (e.g. Raspberry Pi 3 -Model B+), the -vsync option is definitely needed: this will drop video -frames that do not get decoded in time to match the audio, perhaps -making the video “jerky”, but keeping it synchronized with the -audio.

    +

    The older method which does not drop late video frames worked well on +more powerful systems, and is still available with the UxPlay option +“-vsync no”; this method is adapted to “live streaming”, +and may be better when Using UxPlay as a second monitor for a Mac +computer, for example, while the new default timestamp-based method is +best for watching a video, to keep lip movements and voices +synchronized. (Without use of timestamps, video will eventually lag +behind audio if it cannot be decoded fast enough: hardware-accelerated +video-decoding helped to prevent this previously when timestamps were +not being used.)

    The -vsync and -async options also allow an optional positive (or negative) audio-delay adjustment in milliseconds for @@ -415,8 +431,8 @@

    Starting and running UxPlay

  • you may find video is improved by the setting -fps 60 that allows some video to be played at 60 frames per second. (You can see what framerate is actually streaming by using -vs fpsdisplaysink, and/or --FPSdata.) When using this, you probably should use the -vsync -option.

    • +-FPSdata.) When using this, you should use the default timestamp-based +synchronization option -vsync.

  • Since UxPlay-1.54, you can display the accompanying “Cover Art” from sources like Apple Music in Audio-Only (ALAC) mode: run “uxplay -ca <name> &” in the background, then run @@ -438,10 +454,9 @@

    Starting and running UxPlay

    model B+):