From b5deb302a2e92f72b12e48d3ba67b96725d232d1 Mon Sep 17 00:00:00 2001 From: fduncanh Date: Mon, 28 Mar 2022 13:44:08 -0400 Subject: [PATCH] Edit README (cosmetic) --- README.html | 2 +- README.md | 2 +- README.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.html b/README.html index 43b8a70..a093bb1 100644 --- a/README.html +++ b/README.html @@ -116,7 +116,7 @@

3. Problems after the client-server connection has been made:

If you do not see the message raop_rtp_mirror starting mirroring, something went wrong before the client-server negotiations were finished. 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. You can compare your debug output to that from a successful start of UxPlay in the UxPlay Wiki.

If UxPlay reports that mirroring started, but you get no video or audio, the problem is probably from a GStreamer plugin that doesn’t work on your system (by default, GStreamer uses the “autovideosink” and “autoaudiosink” algorithms to guess what are the “best” plugins to use on your system).

-

M1 (Apple Silicon) Macs stream video with h264 profile High at level 4.2, as opposed to High at level 4.1 (streamed by Intel Macs). Currently, this is not being correctly recognized by GStreamer, and a video window fails to open when the client is a M1 Mac. Audio streaming is unaffected. See here for efforts to fix this.

+

M1 (Apple Silicon) Macs stream video with h264 profile High at level 4.2, as opposed to High at level 4.1 (streamed by Intel Macs). Currently, this is not being correctly recognized by GStreamer, and a video window fails to open when the client is a M1 Mac. Audio streaming is unaffected. See here for efforts to fix this.

Raspberry Pi devices (-rpi option) only work with hardware GPU decoding if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has been patched (see the UxPlay Wiki for patches). This may be fixed in the future when GStreamer-1.22 is released, or by backport patches in distributions such as Raspberry Pi OS (Bullseye).

Sometimes “autovideosink” may select the OpenGL renderer “glimagesink” which may not work correctly on your system. Try the options “-vs ximagesink” or “-vs xvimagesink” to see if using one of these fixes the problem.

Other reported problems are connected to the GStreamer VAAPI plugin (for hardware-accelerated Intel graphics, but not NVIDIA graphics). Use the option “-avdec” to force software h264 video decoding: this should prevent autovideosink from selecting the vaapisink videosink. Alternatively, find out if the gstreamer1.0-vaapi plugin is installed, and if so, uninstall it. (If this does not fix the problem, you can reinstall it.)

diff --git a/README.md b/README.md index 6533d1c..344f292 100644 --- a/README.md +++ b/README.md @@ -482,7 +482,7 @@ to guess what are the "best" plugins to use on your system). **M1 (Apple Silicon) Macs stream video with h264 profile High at level 4.2, as opposed to High at level 4.1 (streamed by Intel Macs). Currently, this is not being correctly recognized by GStreamer, and a video window fails to open when the client is a M1 Mac. -Audio streaming is unaffected. ** +Audio streaming is unaffected.** See [here]( https://github.com/FDH2/UxPlay/issues/73) for efforts to fix this. **Raspberry Pi** devices (-rpi option) only work with hardware GPU decoding if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has been patched diff --git a/README.txt b/README.txt index 82023b6..5e38390 100644 --- a/README.txt +++ b/README.txt @@ -631,7 +631,7 @@ on your system). 4.2, as opposed to High at level 4.1 (streamed by Intel Macs). Currently, this is not being correctly recognized by GStreamer, and a video window fails to open when the client is a M1 Mac. Audio streaming -is unaffected. ** See [here](https://github.com/FDH2/UxPlay/issues/73) +is unaffected.** See [here](https://github.com/FDH2/UxPlay/issues/73) for efforts to fix this. **Raspberry Pi** devices (-rpi option) only work with hardware GPU