morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

README update

Browse Source
This commit is contained in:
fduncanh
2021-12-18 19:00:06 -05:00
parent 501673afc7
commit 6a58f74868
3 changed files with 52 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
README.html
View File

@@ -47,12 +47,13 @@
</ol>
<h1 id="troubleshooting"><strong>Troubleshooting:</strong></h1>
<p>Note: <code>uxplay</code> is run from a terminal command line, and informational messages are written to the terminal.</p>
<h3 id="uxplay-starts-but-stalls-after-initialized-server-sockets-appears-without-any-server-name-showing-on-the-client.">1. uxplay starts, but stalls after “Initialized server socket(s)” appears, without any server name showing on the client.</h3>
<h3 id="uxplay-starts-but-stalls-after-initialized-server-sockets-appears-without-any-server-name-showing-on-the-client.">1. uxplay starts, but stalls after “Initialized server socket(s)” appears, <em>without any server name showing on the client</em>.</h3>
<p>Stalling this way, with <em>no</em> server name showing <em>on the client</em> as available, probably means that your network <strong>does not have a running Bonjour/zeroconf DNS-SD server.</strong> On Linux, make sure Avahi is installed, and start the avahi-daemon service on the system running uxplay (your distribution will document how to do this). Some systems may instead use the mdnsd daemon as an alternative to provide DNS-SD service. <em>(FreeBSD offers both alternatives, but only Avahi was tested: one of the steps needed for getting Avahi running on a FreeBSD system is to edit <code>/usr/local/etc/avahi/avahi-daemon.conf</code> to uncomment a line for airplay support.</em>)</p>
<h3 id="uxplay-stalls-with-the-expected-server-name-showing-on-the-client-but-fails-to-connect-to-the-client-when-this-is-selected.">2. uxplay stalls, with the expected server name showing on the client, but fails to connect to the client when this is selected.</h3>
<h3 id="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.">2. uxplay starts, but stalls after “Initialized server socket(s)” appears, <em>with the server name showing on the client</em> (but the client fails to connect when the UxPlay server is selected).</h3>
<p>This shows that a <em>dns_sd</em> service is working, but a firewall on the server is probably blocking the connection request from the client. (One user who insisted that the firewall had been turned off turned out to have had <em>two</em> active firewalls (<em>firewalld</em> and <em>ufw</em>) <em>both</em> running on the server!) If possible, either turn off the firewall to see if that is the problem, or get three consecutive network ports, starting at port n, all three in the range 1024-65535, opened for both tcp and udp, and use “uxplay -p n” (or open UDP 6000, 6001, 6011 TCP 7000,7001,7100 and use “uxplay -p”).</p>
<h3 id="problems-after-the-client-server-connection-has-been-made">3. Problems <em>after</em> the client-server connection has been made:</h3>
<p>For such problems, use “uxplay -d” (debug log option) to see what is happening. <strong>Most such problems are due to a GStreamer plugin that doesn’t work on your system</strong>: (by default, GStreamer uses an algorithm to guess what is the “best” plugin to use on your system). A common case is that the GStreamer VAAPI plugin (for hardware-accelerated intel graphics) is being used on a system with nVidia graphics, If you use an nVidia graphics card, make sure that the gstreamer1.0-vaapi plugin for Intel graphics is <em>NOT</em> installed (<strong>uninstall it</strong> if it is installed!). (You can test for this by explicitly choosing the GStreamer videosink with option “-vs ximagesink” or “-vs xvimagesink”, to see if this fixes the problem, or “-vs vaapisink” to see if this reproduces the problem.)</p>
<p>For such problems, use “uxplay -d” (debug log option) to see what is happening: it will show how far the connection process gets before the failure occurs.</p>
<p><strong>Most such problems are due to a GStreamer plugin that doesn’t work on your system</strong>: (by default, GStreamer uses an algorithm to guess what is the “best” plugin to use on your system). A common case is that the GStreamer VAAPI plugin (for hardware-accelerated intel graphics) is being used on a system with nVidia graphics, If you use an nVidia graphics card, make sure that the gstreamer1.0-vaapi plugin for Intel graphics is <em>NOT</em> installed (<strong>uninstall it</strong> if it is installed!). (You can test for this by explicitly choosing the GStreamer videosink with option “-vs ximagesink” or “-vs xvimagesink”, to see if this fixes the problem, or “-vs vaapisink” to see if this reproduces the problem.)</p>
<p>There are some reports of other GStreamer problems with hardware-accelerated Intel graphics. One user (on Debian) solved this with “sudo apt install intel-media-va-driver-non-free”. This is a driver for 8’th (or later) generation "*-lake" Intel chips, that seems to be related to VAAPI accelerated graphics.</p>
<p>You can try to fix audio problems by using the “-as <em>audiosink</em>” option to choose the GStreamer audiosink , rather than have autoaudiosink pick one for you. The command “gst_inspect-1.0 | grep Sink | grep Audio” " will show you which audiosinks are available on your system. (Replace “Audio” by “Video” to see videosinks). Some possible audiosinks are pulsesink, alsasink, osssink, oss4sink, and osxaudiosink (macOS).</p>
<p>If you ran cmake with “-DZOOMFIX=ON”, check if the problem is still there without ZOOMFIX. ZOOMFIX is only applied to the default videosink choice (“autovideosink”) and the two X11 videosinks “ximagesink” and “xvimagesink”. ZOOMFIX is only designed for these last two; if autovideosink chooses a different videosink, ZOOMFIX is now ignored. If you are using the X11 windowing system (standard on Linux), and have trouble with screen-sharing on Zoom, use ZOOMFIX and “-vs xvimagesink” (or “-vs ximagesink” if the previous choice doesn’t work).</p>
@@ -63,7 +64,8 @@
<p>Some extra GStreamer packages for special plugins may need to be installed (or reinstalled: a user using a Wayland display system as an alternative to X11 reported that after reinstalling Lubuntu 18.4, UxPlay would not work until gstreamer1.0-x was installed, presumably for Wayland’s X11-compatibility mode). Different distributions may break up GStreamer 1.x into packages in different ways; the packages listed above in the build instructions should bring in other required GStreamer packages as dependencies, but will not install all possible plugins.</p>
<h3 id="failure-to-decrypt-all-video-and-audio-streams-from-a-particular-older-client">5. Failure to decrypt ALL video and audio streams from a particular (older) client:</h3>
<p>This triggers an error message, and will be due to use of an incorrect protocol for getting the AES decryption key from the client.</p>
<p>Modern Apple clients use a more-encrypted protocol than older ones. Which protocol is used by UxPlay depends on the client <em>User-Agent</em> string (reported by the client and now shown in the terminal output). Since UxPlay 1.45 (to support the third-party Windows AirPlay-client emulator <em>AirMyPC</em>, which uses the old protocol and reports itself as User-Agent: “AirMyPC/2.0”), a modified protocol is used for clients reporting a User-Agent string contained in <code>OLD_PROTOCOL_AUDIO_CLIENT_LIST</code> (for the audio AES key) and <code>OLD_PROTOCOL_VIDEO_CLIENT_LIST</code> (for the video AES key), defined in<code>lib/global.h</code>. If they fail one of the decryption tests, you might be able to get very old versions of iOS or iPadOS to work with UxPlay by adding their User_Agent strings to the appropriate list. <em>It has now been reported that iOS 9 and iOS 10 video work with UxPlay, but not the audio, and the suggested fix here did not fix the audio, and was not needed for video.</em></p>
<p>Modern Apple clients use a more-encrypted protocol than older ones. Which protocol is used by UxPlay depends on the client <em>User-Agent</em> string (reported by the client and now shown in the terminal output). iOS 9 and 10 clients only use iTunes FairPlay encryption on the AES decryption key they send to the server. Somewhere around iOS sourceVersion 330 (part of the User-Agent string) Apple started to further encrypt it by a sha-512 hash with a “shared secret” created during the Server-Client pairing process. The sourceVersion 330 above which the extra decryption step is carried out is set in lib/global.h if you need to change it. (This applies only to audio decryption; the AES key used for video decryption has had this extra encryption since iOS 9).</p>
<p>The third-party non-free Windows software <em>AirMyPC</em> (a commercial AirPlay emulator) uses an unhashed AES key for both audio and video encryption. <em>AirMyPC</em> has a distinctive <em>User-Agent</em> string, which is detected using two other settings in lib/global.h that can be adjusted if necessary. These settings might be useful if other AirPlay-emulators need support. Uxplay declares itself to be an AppleTV2,1 with sourceVersion 220.68; this can also be changed in global.h.</p>
<h1 id="usage"><strong>Usage:</strong></h1>
<p>Options:</p>
<p><strong>-n server_name</strong> (Default: UxPlay); server_name@_hostname_ will be the name that appears offering AirPlay services to your iPad, iPhone etc, where <em>hostname</em> is the name of the server running uxplay. This will also now be the name shown above the mirror display (X11) window.</p>

22
README.md
View File

@@ -205,7 +205,7 @@ as the device is rotated).
Note: ```uxplay``` is run from a terminal command line, and informational messages are written to the terminal.
### 1. uxplay starts, but stalls after "Initialized server socket(s)" appears, without any server name showing on the client.
### 1. uxplay starts, but stalls after "Initialized server socket(s)" appears, *without any server name showing on the client*.
Stalling this way, with _no_ server name showing _on the client_ as available,
probably means that your network **does not have a running Bonjour/zeroconf DNS-SD server.**
@@ -216,7 +216,7 @@ _(FreeBSD offers both alternatives, but only Avahi was tested: one of the steps
getting Avahi running on a FreeBSD system is to edit ```/usr/local/etc/avahi/avahi-daemon.conf``` to
uncomment a line for airplay support._)
### 2. uxplay stalls, with the expected server name showing on the client, but fails to connect to the client when this is selected.
### 2. uxplay starts, but stalls after "Initialized server socket(s)" appears, *with the server name showing on the client* (but the client fails to connect when the UxPlay server is selected).
This shows that a *dns_sd* service is working, but a firewall on the server is probably blocking the connection request from the client.
(One user who insisted that the firewall had been turned off turned out to have had _two_ active firewalls (*firewalld* and *ufw*)
@@ -227,7 +227,9 @@ starting at port n, all three in the range 1024-65535, opened for both tcp and
### 3. Problems _after_ the client-server connection has been made:
For such problems, use "uxplay -d " (debug log option) to see what is happening.
For such problems, use "uxplay -d " (debug log option) to see what is happening: it will show how far the connection process gets before
the failure occurs.
**Most such problems are due to a GStreamer plugin that doesn't work on your system**: (by default,
GStreamer uses an algorithm to guess what is the "best"
plugin to use on your system). A common case is that the GStreamer VAAPI plugin
@@ -281,11 +283,15 @@ other required GStreamer packages as dependencies, but will not install all poss
This triggers an error message, and will be due to use of an incorrect protocol for getting the AES decryption key from the client.
Modern Apple clients use a more-encrypted protocol than older ones.
Which protocol is used by UxPlay depends on the client _User-Agent_ string (reported by the client and now shown in the terminal output). Since UxPlay 1.45
(to support the third-party Windows AirPlay-client emulator _AirMyPC_, which uses the old protocol and reports itself as User-Agent: "AirMyPC/2.0"),
a modified protocol is used for clients reporting a User-Agent string contained in ```OLD_PROTOCOL_AUDIO_CLIENT_LIST``` (for the audio AES key) and
```OLD_PROTOCOL_VIDEO_CLIENT_LIST``` (for the video AES key), defined in```lib/global.h```. If they fail one of the decryption tests, you might be able to get very old
versions of iOS or iPadOS to work with UxPlay by adding their User_Agent strings to the appropriate list. _It has now been reported that iOS 9 and iOS 10 video work with UxPlay, but not the audio, and the suggested fix here did not fix the audio, and was not needed for video._
Which protocol is used by UxPlay depends on the client _User-Agent_ string (reported by the client and now shown in the terminal output).
iOS 9 and 10 clients only use iTunes FairPlay encryption on the AES decryption key they send to the server.
Somewhere around iOS sourceVersion 330 (part of the User-Agent string) Apple started to further encrypt it by a sha-512 hash with a "shared secret" created
during the Server-Client pairing process. The sourceVersion 330 above which the extra decryption step is carried out is set in lib/global.h if you need to
change it. (This applies only to audio decryption; the AES key used for video decryption has had this extra encryption since iOS 9).
The third-party non-free Windows software _AirMyPC_ (a commercial AirPlay emulator) uses an unhashed AES key for both audio and video encryption. _AirMyPC_ has a distinctive
_User-Agent_ string, which is detected using two other settings in lib/global.h that can be adjusted if necessary. These settings might be useful if
other AirPlay-emulators need support. Uxplay declares itself to be an AppleTV2,1 with sourceVersion 220.68; this can also be changed in global.h.
# **Usage:**

57
README.txt
View File

@@ -272,7 +272,7 @@ pkgconfig" ; MacPorts: "sudo port install pkgconfig" ).
Note: `uxplay` is run from a terminal command line, and informational
messages are written to the terminal.
### 1. uxplay starts, but stalls after "Initialized server socket(s)" appears, without any server name showing on the client.
### 1. uxplay starts, but stalls after "Initialized server socket(s)" appears, *without any server name showing on the client*.
Stalling this way, with *no* server name showing *on the client* as
available, probably means that your network **does not have a running
@@ -285,7 +285,7 @@ one of the steps needed for getting Avahi running on a FreeBSD system is
to edit `/usr/local/etc/avahi/avahi-daemon.conf` to uncomment a line for
airplay support.*)
### 2. uxplay stalls, with the expected server name showing on the client, but fails to connect to the client when this is selected.
### 2. uxplay starts, but stalls after "Initialized server socket(s)" appears, *with the server name showing on the client* (but the client fails to connect when the UxPlay server is selected).
This shows that a *dns\_sd* service is working, but a firewall on the
server is probably blocking the connection request from the client. (One
@@ -300,17 +300,19 @@ use "uxplay -p").
### 3. Problems *after* the client-server connection has been made:
For such problems, use "uxplay -d" (debug log option) to see what is
happening. **Most such problems are due to a GStreamer plugin that
doesn't work on your system**: (by default, GStreamer uses an algorithm
to guess what is the "best" plugin to use on your system). A common case
is that the GStreamer VAAPI plugin (for hardware-accelerated intel
graphics) is being used on a system with nVidia graphics, If you use an
nVidia graphics card, make sure that the gstreamer1.0-vaapi plugin for
Intel graphics is *NOT* installed (**uninstall it** if it is
installed!). (You can test for this by explicitly choosing the GStreamer
videosink with option "-vs ximagesink" or "-vs xvimagesink", to see if
this fixes the problem, or "-vs vaapisink" to see if this reproduces the
problem.)
happening: it will show how far the connection process gets before the
failure occurs.
**Most such problems are due to a GStreamer plugin that doesn't work on
your system**: (by default, GStreamer uses an algorithm to guess what is
the "best" plugin to use on your system). A common case is that the
GStreamer VAAPI plugin (for hardware-accelerated intel graphics) is
being used on a system with nVidia graphics, If you use an nVidia
graphics card, make sure that the gstreamer1.0-vaapi plugin for Intel
graphics is *NOT* installed (**uninstall it** if it is installed!). (You
can test for this by explicitly choosing the GStreamer videosink with
option "-vs ximagesink" or "-vs xvimagesink", to see if this fixes the
problem, or "-vs vaapisink" to see if this reproduces the problem.)
There are some reports of other GStreamer problems with
hardware-accelerated Intel graphics. One user (on Debian) solved this
@@ -371,18 +373,23 @@ protocol for getting the AES decryption key from the client.
Modern Apple clients use a more-encrypted protocol than older ones.
Which protocol is used by UxPlay depends on the client *User-Agent*
string (reported by the client and now shown in the terminal output).
Since UxPlay 1.45 (to support the third-party Windows AirPlay-client
emulator *AirMyPC*, which uses the old protocol and reports itself as
User-Agent: "AirMyPC/2.0"), a modified protocol is used for clients
reporting a User-Agent string contained in
`OLD_PROTOCOL_AUDIO_CLIENT_LIST` (for the audio AES key) and
`OLD_PROTOCOL_VIDEO_CLIENT_LIST` (for the video AES key), defined
in`lib/global.h`. If they fail one of the decryption tests, you might be
able to get very old versions of iOS or iPadOS to work with UxPlay by
adding their User\_Agent strings to the appropriate list. *It has now
been reported that iOS 9 and iOS 10 video work with UxPlay, but not the
audio, and the suggested fix here did not fix the audio, and was not
needed for video.*
iOS 9 and 10 clients only use iTunes FairPlay encryption on the AES
decryption key they send to the server. Somewhere around iOS
sourceVersion 330 (part of the User-Agent string) Apple started to
further encrypt it by a sha-512 hash with a "shared secret" created
during the Server-Client pairing process. The sourceVersion 330 above
which the extra decryption step is carried out is set in lib/global.h if
you need to change it. (This applies only to audio decryption; the AES
key used for video decryption has had this extra encryption since iOS
9).
The third-party non-free Windows software *AirMyPC* (a commercial
AirPlay emulator) uses an unhashed AES key for both audio and video
encryption. *AirMyPC* has a distinctive *User-Agent* string, which is
detected using two other settings in lib/global.h that can be adjusted
if necessary. These settings might be useful if other AirPlay-emulators
need support. Uxplay declares itself to be an AppleTV2,1 with
sourceVersion 220.68; this can also be changed in global.h.
**Usage:**
==========