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

remove -rpi option (it was premature to add it)

Browse Source
This commit is contained in:
fduncanh
2022-03-02 19:47:59 -05:00
parent 23addca4e1
commit c0b4dc4e73
5 changed files with 71 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
README.html
View File

@@ -19,7 +19,7 @@
<p>For systems with Intel integrated graphics, hardware GPU decoding with the gstreamer VAAPI plugin is preferable. VAAPI is open-source, and in addition to Intel, can support some AMD GPU’s (the open-source “Nouveau” drivers for NVIDIA graphics are also in principle supported when VAAPI is supplemented with firmware extracted from the proprietary NVIDIA drivers).</p>
<p>For NVIDIA graphics with the proprietary drivers, the nvdec plugin (recently renamed nvh264dec) can be used for accelerated video decoding on the NVIDIA GPU with CUDA. The nvdec plugin is part of gstreamer1.0-plugins-bad, but is generally not included in binary packages, as NVIDIA’s proprietary <a href="https://docs.nvidia.com/video-technologies/video-codec-sdk/nvdec-video-decoder-api-prog-guide/">Video Codec SDK</a> must be downloaded, and three header files from it must be added to the gstreamer source before the plugin can be compiled. Users must do this themselves: see <a href="https://gist.github.com/corenel/a615b6f7eb5b5425aa49343a7b409200">these instructions</a>, and adapt them as necessary for your GStreamer installation. This plugin should be used with the <code>-vd nvdec</code> (or nvh264dec) and <code>-vs glimagesink</code> uxplay options.</p>
<ul>
<li><strong>support for Raspberry Pi</strong> (<em>work in progress</em>): the R Pi platform has long been supported by <a href="http://github.com/FD-/RPiPlay">RPiPlay</a> using the deprecated 32-bit-only omx (OpenMAX) decoder, now removed from latest Raspberry Pi OS (Bullseye), leading to user interest in getting UxPlay to work on the R Pi (at least on model 4). UxPlay can work with software h264 video decoding (option <code>-avdec</code>), but without hardware decoding has unacceptable latency on the Pi. The Video4Linux2 GStreamer plugin v4l2h264dec (from gstreamer1.0-plugins-good) is now the appropriate choice for accelerated hardware video decoding by the Broadcom GPU on the Pi. UxPlay options can be used to create GStreamer video pipelines to use non-VAAPI hardware decoders, and a new UxPlay option <code>-rpi</code> creates a pipeline that should be appropriate for the Raspberry Pi, and when it has worked, it has worked well. However, it usually does not work because of a “caps” mismatch between source and sink, which could be fixable with GStreamer “know-how” (perhaps involving using the “capssetter” element). The GStreamer video pipeline is “<code>(decrypted h264 stream from iOS)! queue ! h264parse ! decodebin ! videoconvert ! autovideosink sync=false</code>” and the uxplay options <code>-vp , -vd, -vc ,-vs</code> can be used to replace <code>h264parse, decodebin, videoconvert, autovideosink</code> by the user’s choices. (<code>-rpi</code> is equivalent to <code>-vd v4l2h264dec -vc v4l2convert</code>). The first frame in the h264 video stream sends the “caps” details (SPS, PPS) to h264parse. UxPlay users with the R Pi (model 4 recommended) are invited to experiment and report any successes. (The uxplay <code>-d</code> option will display the actual video pipeline being used, <code>export GST_DEBUG=2</code> before running uxplay will display GStreamer errors and warnings.)</li>
<li><strong>possible support for Raspberry Pi</strong> (<em>not working</em>): the CPU of the Raspberry Pi is not powerful enough for GStreamer to decode the h264 video stream using software decoding (option <code>-avdec</code> ) without unacceptable latency. The Pi has a Broadcom GPU for accelerated hardware h264 decoding, and in the past this has been supported by <a href="https://github.com/FD-/RPiPlay">RPiPlay</a> using the deprecated 32-bit omx (OpenMax) driver. Unfortunately, with the move to a 64-bit OS, this has been removed from recent Raspberry Pi OS (Bullseye), and there has been user interest in making UxPlay work on the Pi. The designated replacement for OpenMAX is Video4linux2, and the options that <em>should</em> work with UxPlay are <code>-vd v4l2h264dec -vc v4l2convert</code>, which are from gstreamer1.0-plugins-good. This has occasionally worked, and when it did, it worked well, with no appreciable latency. Unfortunately, the v4l2h264dec GStreamer plugin usually fails to match the “caps” (capacities) of the h264 source to the videosink, and h264 hardware decoding fails. It is not clear whether there is any workaround before an updated v4l2h264dec plugin becomes available. GStreamer-knowledgeable users who wish to experiment can see if any video pipeline modifications can provide a workaround: the pipeline is <code>(video stream from appsrc) ... ! h264parse ! decodebin ! videoconvert ! autovideosink ...</code>; the elements h264parse, decodebin, videoconvert, and autovideosink can respectively be modified with options -vp, -vd, -vc, and -vs. Please report any successes! (See <a href="https://github.com/raspberrypi/firmware/issues/1673">this</a>, which suggests some workaround involving “capssetter” might be possible; <code>export GST_DEBUG=GST_CAPS:5</code> may be useful in debugging the pipeline.</li>
</ul>
<h3 id="note-to-packagers-openssl-3.0.0-solves-gpl-v3-license-issues.">Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.</h3>
<p>Some Linux distributions such as Debian do not allow distribution of compiled GPL code linked to OpenSSL-1.1.1 because its “dual OpenSSL/SSLeay” license has some incompatibilities with GPL, unless all code authors have explicitly given an “exception” to allow such linking (the historical origins of UxPlay make this impossible to obtain). Other distributions treat OpenSSL as a “System Library” which the GPL allows linking to.</p>
@@ -86,8 +86,9 @@
<p>Also: image transforms that had been added to RPiPlay have been ported to UxPlay:</p>
<p><strong>-f {H|V|I}</strong> implements “videoflip” image transforms: H = horizontal flip (right-left flip, or mirror image); V = vertical flip ; I = 180 degree rotation or inversion (which is the combination of H with V).</p>
<p><strong>-r {R|L}</strong> 90 degree Right (clockwise) or Left (counter-clockwise) rotations; these are carried out after any <strong>-f</strong> transforms.</p>
<p><strong>-vd <em>decoder</em></strong> chooses the GStreamer pipeline’s h264 decoder, instead of letting decodebin pick it for you. Software decoding is done by avdec_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes “…” allows some parameters to be included with the decoder name.</p>
<p><strong>-vc <em>converter</em></strong> chooses the GStreamer pipeline’s videoconverter, instead of the default value “videoconvert”. When using video4linux hardware decoding by a GPU,<code>-vc v4l2convert</code> will also use the GPU for video conversion. Using quotes “…” allows some parameters to be included with the converter name.</p>
<p><strong>-vp <em>parser</em></strong> choses the GStreamer pipeline’s h264 parser element, default is h264parse. Using quotes “…” allows options to be added.</p>
<p><strong>-vd <em>decoder</em></strong> chooses the GStreamer pipeline’s h264 decoder element, instead of letting decodebin pick it for you. Software decoding is done by avdec_h264; various hardware decoders include: vaapi264dec, nvdec, nvh264dec, v4l2h264dec (these require that the appropriate hardware is available). Using quotes “…” allows some parameters to be included with the decoder name.</p>
<p><strong>-vc <em>converter</em></strong> chooses the GStreamer pipeline’s videoconverter element, instead of the default value “videoconvert”. When using video4linux hardware decoding by a GPU,<code>-vc v4l2convert</code> will also use the GPU for video conversion. Using quotes “…” allows some parameters to be included with the converter name.</p>
<p><strong>-vs <em>videosink</em></strong> chooses the GStreamer videosink, instead of letting autovideosink pick it for you. Some videosink choices are: ximagesink, xvimagesink, vaapisink (for intel graphics), gtksink, glimagesink, waylandsink, osximagesink (for macOS), or fpsdisplaysink (which shows the streaming framerate in fps). Using quotes “…” allows some parameters to be included with the videosink name. For example, <strong>fullscreen</strong> mode is supported by the vaapisink plugin, and is obtained using <code>-vs "vaapisink fullscreen=true"</code>; this also works with <code>waylandsink</code>. The syntax of such options is specific to a given plugin, and some choices of videosink might not work on your system.</p>
<p><strong>-vs 0</strong> suppresses display of streamed video, but plays streamed audio. (The client’s screen is still mirrored at a reduced rate of 1 frame per second, but is not rendered or displayed.) This feature (which streams audio in AAC audio format) is now probably unneeded, as UxPlay can now stream superior-quality Apple Lossless audio without video in Airplay non-mirror mode.</p>
<p><strong>-avdec</strong> forces use of software h264 decoding using Gstreamer element avdec_h264 (libav h264 decoder). This option should prevent autovideosink choosing a hardware-accelerated videosink plugin such as vaapisink.</p>