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).
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 Video Codec SDK 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 these instructions, and adapt them as necessary for your GStreamer installation. This plugin should be used with the -vd nvdec (or nvh264dec) and -vs glimagesink uxplay options.
-avdec), 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 -rpi 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”. The GStreamer video pipeline is “(decrypted h264 stream from iOS)! queue ! h264parse ! decodebin ! videoconvert ! autovideosink sync=false” and the uxplay options -vp , -vd, -vc ,-vs can be used to replace h264parse, decodebin, videoconvert, autovideosink by the user’s choices. (-rpi is equivalent to ’-vd v4l2h264dec -vc v4l2convert). 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-d` option will display the actual video pipeline being used.)-avdec), 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 -rpi 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”. The GStreamer video pipeline is “(decrypted h264 stream from iOS)! queue ! h264parse ! decodebin ! videoconvert ! autovideosink sync=false” and the uxplay options -vp , -vd, -vc ,-vs can be used to replace h264parse, decodebin, videoconvert, autovideosink by the user’s choices. (-rpi is equivalent to -vd v4l2h264dec -vc v4l2convert). 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 -d option will display the actual video pipeline being used.)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.
diff --git a/README.md b/README.md index 1c2e313..4b78884 100644 --- a/README.md +++ b/README.md @@ -90,7 +90,7 @@ This plugin should be used with the `-vd nvdec` (or nvh264dec) and `-vs glimages and the uxplay options `-vp , -vd, -vc ,-vs` can be used to replace `h264parse, decodebin, videoconvert, autovideosink` by the user's choices. (`-rpi` is equivalent - to '-vd v4l2h264dec -vc v4l2convert`). The first frame in the h264 video stream sends the "caps" + to `-vd v4l2h264dec -vc v4l2convert`). 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 `-d` option will display the actual video pipeline being used.) diff --git a/README.txt b/README.txt index 94351ae..3fe3c00 100644 --- a/README.txt +++ b/README.txt @@ -120,9 +120,12 @@ uxplay options. "`(decrypted h264 stream from iOS)! queue ! h264parse ! decodebin ! videoconvert ! autovideosink sync=false`" and the uxplay options `-vp , -vd, -vc ,-vs` can be used to replace `h264parse, decodebin, videoconvert, autovideosink` by the user's - choices. (`-rpi` is equivalent to '-vd v4l2h264dec -vc - v4l2convert`). 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`-d\` - option will display the actual video pipeline being used.) + choices. (`-rpi` is equivalent to + `-vd v4l2h264dec -vc v4l2convert`). 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 `-d` option will + display the actual video pipeline being used.) ### Note to packagers: OpenSSL-3.0.0 solves GPL v3 license issues.