Edit README (cosmetic)

README.html

@@ -116,7 +116,7 @@
 <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>If you do <em>not</em> see the message <code>raop_rtp_mirror starting mirroring</code>, 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 <a href="https://github.com/FDH2/UxPlay/wiki">UxPlay Wiki</a>.</p>
 <p><strong>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</strong> (by default, GStreamer uses the “autovideosink” and “autoaudiosink” algorithms to guess what are the “best” plugins to use on your system).</p>
-<p><strong>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. </strong> See <a href="https://github.com/FDH2/UxPlay/issues/73">here</a> for efforts to fix this.</p>
+<p><strong>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.</strong> See <a href="https://github.com/FDH2/UxPlay/issues/73">here</a> for efforts to fix this.</p>
 <p><strong>Raspberry Pi</strong> 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 <a href="https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches">Wiki</a> 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).</p>
 <p>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.</p>
 <p>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.)</p>

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

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