注意:不支援 AirPlay2 多房間音訊串流:請使用 shairport-sync。
。
使用「 sudo apt install uxplay
」在基於 Debian 的 Linux 系統上安裝 uxplay;在 FreeBSD 上使用「 sudo pkg install uxplay
」。也可透過 AUR 在基於 Arch 的系統上使用。自 v. 1.66 起,uxplay 現在也由 Fedora 38 以 RPM 格式打包(「 sudo dnf install uxplay
」)。
對於尚未打包 UxPlay 的其他基於 RPM 的發行版,現在隨最新版本提供了 RPM「specfile」 uxplay.spec (請參閱其「資產」),也可以在 UxPlay 來源頂級目錄中找到。請參閱使用此規範檔案建置可安裝 RPM 套件的部分。
安裝後:
(在Linux 和*BSD 上):如果託管UxPlay 的伺服器上的防火牆處於活動狀態,請確保mDNS/DNS-SD 查詢的預設網路連接埠(UDP 5353) 已開啟(有關更多詳細信息,請參閱下面的故障排除);也為 Uxplay 打開三個 UDP 和三個 TCP 端口,並使用“uxplay -p”選項(請參閱“ man uxplay
”或“ uxplay -h
”)。
即使您安裝了發行版的預編譯 uxplay 二進位包,您可能需要閱讀以下執行 UxPlay 的說明,以了解您還應該安裝哪些發行版的GStreamer 插件包。
對於純音訊模式(Apple Music 等),可以透過選項「uxplay -async」獲得最佳質量,但 iOS 會產生 2 秒的延遲。
將您想要用作預設值的任何 UxPlay 選項新增至啟動檔案~/.uxplayrc
(有關格式和其他可能的位置,請參閱「 man uxplay
」或「 uxplay -h
」)。特別是,如果您的系統使用 PipeWire 音訊或 Wayland 視訊系統,您可能會想要將「as pipelinesink」或「vs waylandsink」新增為檔案的預設值。 (如果您的 Linux/BSD 系統使用終端命令“ps waux | greppulse”或“pactl info”的輸出將包含“pipewire”)。
在Raspberry Pi 上:如果您使用Ubuntu 22.10 或更早版本,則必須修補GStreamer 以使用Broadcom GPU 的硬體視訊解碼(也推薦,但對於Raspberry Pi OS (Bullseye) 是可選的:如果不使用,請使用選項“ uxplay -bt709
”補丁)。
若要(輕鬆)從原始程式碼編譯最新的 UxPlay,請參閱取得 UxPlay 部分。
該專案是適用於 Linux、macOS 和 *BSD 的 GPLv3 開源 unix AirPlay2 鏡像伺服器。它最初是由 antimof 使用基於 OpenMAX 的 RPiPlay 的程式碼開發的,而 RPiPlay 又源自 AirplayServer、shairplay 和 playfair。 (antimof 網站不再參與開發,但會定期發布從新的 UxPlay 主網站提取的更新)。
UxPlay 在許多系統上進行了測試,其中包括 Debian(10“Buster”、11“Bullseye”、12“Bookworm”)、Ubuntu(20.04 LTS、22.04 LTS、23.04(還有 Ubuntu 衍生品 Linux Mint、Pop! _OS )、Red Hat 和克隆(Fedora 38、Rocky Linux 9.2)、openSUSE Leap 15.5、Mageia 9、OpenMandriva“ROME”、PCLinuxOS、Arch Linux、Manjaro,並且應該在任何Linux 系統上運行也可以在macOS Catalina 和Ventura 上進行測試。
在 Raspberry Pi 4 B 型上,它在 Raspberry Pi OS(Bullseye 和 Bookworm)(32 位元和 64 位元)、Ubuntu 22.04 LTS 和 23.04、Manjaro RPi4 23.02 以及 openSUSE 15.5(無硬體視訊解碼)上進行了測試。也在 Raspberry Pi Zero 2 W、3 型號 B+ 和現在的 5 上進行了測試。
它的主要用途是像 AppleTV 一樣,在運行 Linux、macOS 或其他 UNIX 的主機的伺服器顯示器上對 iOS/iPadOS/macOS 用戶端(iPhone、iPod Touch、iPad、Mac 電腦)進行螢幕鏡像(帶音訊) (現在還有Microsoft Windows)。 UxPlay 使用「舊版協議」支援 Apple 的 AirPlay2 協議,但缺少一些功能。 (有關Apple AirPlay 2 協議的公開信息的詳細信息,請參閱此處、此處和此處;另請參閱pyatv,它可能是添加現代協議的資源。)雖然不能保證未來的iOS 版本將繼續支持“舊版協議” 》,iOS 17繼續支持。
UxPlay 伺服器及其用戶端必須位於同一區域網路上,且該區域網路上也運行Bonjour/Zeroconf mDNS/DNS-SD 伺服器(僅 DNS-SD「服務發現」服務是嚴格必要的,不需要本地網絡也可以是基於“.local”mDNS 的型別)。在 Linux 和 BSD Unix 伺服器上,這通常由 Avahi 透過 avahi-daemon 服務提供,並且包含在大多數 Linux 發行版中(此服務也可以由 macOS、iOS 或 Windows 伺服器提供)。
iOS/MacOS 用戶端與 UxPlay 伺服器的連接可以在AirPlay Mirror模式(在鏡像用戶端螢幕的同時傳輸有損壓縮的 AAC 音訊)或在替代的AirPlay Audio模式下啟動,該模式在不進行螢幕鏡像的情況下傳輸Apple Lossless (ALAC) 音訊在音訊模式下,如果使用 UxPlay 選項-ca
,則元資料會顯示在 uxplay 終端機中,隨附的封面也會輸出到定期更新的檔案
中,並且可以使用(重新加載)進行查看;您可以在活動連接期間在鏡像和音頻模式之間切換:在鏡像模式下,停止鏡像(或關閉鏡像窗口)並啟動音頻模式連接,透過啟動鏡像模式連接切換回來;當您離開/重新進入音訊模式時,藝術展示會停止/重新啟動。
請注意,Apple video-DRM(在客戶端上的「Apple TV 應用程式」內容中找到)無法透過UxPlay 解密,並且無法使用UxPlay 的AirPlay Mirror 模式觀看Apple TV 應用程式(僅會傳輸未受保護的音頻,採用AAC 格式)格式),但來自無 DRM 應用程式(例如「YouTube 應用程式」)的影片和音訊內容都將由 UxPlay 以鏡像模式進行串流傳輸。
由於 UxPlay 目前不支援非 Mirror AirPlay 視訊串流(其中客戶端控制 AirPlay 伺服器上的 Web 伺服器直接接收 HLS 內容,以避免被客戶端解碼和重新編碼),因此使用 AirPlay 視訊的圖標YouTube 應用程式等應用程式將僅發送音訊(無損ALAC 格式),而不發送隨附的視訊(計劃在UxPlay 的未來版本中支援HLS 視訊)
UxPlay 使用 GStreamer「插件」來渲染音訊和視訊。這意味著使用多種插件「開箱即用」支援視訊和音訊。 AirPlay 以 h264 格式傳輸影片:gstreamer 解碼與外掛程式無關,並使用加速 GPU 硬體 h264 解碼器(如果可用);如果不是,則使用軟體解碼。
適用於 Intel 和 AMD 整合顯示卡的 VAAPI,NVIDIA 隨附「Nouveau」開源驅動程式
對於 Intel 或 AMD GPU,最好使用開源 VAAPI gstreamer 外掛程式進行硬體解碼。原則上也支援 NVIDIA 顯示卡的開源「Nouveau」驅動程式:請參閱此處,但這需要 VAAPI 補充從專有 NVIDIA 驅動程式中提取的韌體。
具有專有驅動程式的 NVIDIA
安裝 NVIDIA 的 CUDA 驅動程式libcuda.so
後,可以使用nvh264dec
插件(自 GStreamer-1.18.0 起包含在 gstreamer1.0-plugins-bad 中)在 NVIDIA GPU 上加速視訊解碼。對於 GStreamer-1.16.3 或更早版本,該插件稱為nvdec
,並且必須由使用者建置。
Video4Linux2 支援 Raspberry Pi(Pi 4B 及更早版本)上的 h264 硬體解碼
Raspberry Pi (RPi) 電腦(在 Pi 4 Model B 上測試)現在可以使用軟體視訊解碼運行 UxPlay,但首選透過 Pi 的 Broadcom 2835 GPU 中的韌體進行硬體加速的 h264/h265 解碼。 UxPlay 使用 GStreamer-1.22 Video4Linux2 (v4l2) 外掛程式存取它;使用由 Raspberry Pi 維護的非主線 Linux 核心模組 bcm2835-codec,目前僅包含在 Raspberry Pi OS 中,以及 Raspberry Pi Imager 提供的其他兩個發行版(Ubuntu、Manjaro)。 (有關 GStreamer < 1.22,請參閱 UxPlay Wiki) 。
(新):支援 Raspberry Pi(Pi 4 model B 和 Pi 5)上的 h265 (HEVC) 硬體解碼
支持是存在的,但迄今為止尚未取得令人滿意的結果。 Pi model 5 僅提供 h265 視訊的硬體加速 (GPU) 解碼,但不提供 H264,因為其 CPU 足夠強大,可以滿足令人滿意的軟體 H264 解碼
UxPlay 的 GPLv3 授權沒有添加“GPL 例外”,明確允許在連結到v.3.0.0 之前的OpenSSL 版本時以編譯形式分發(舊版本的 OpenSSL 具有與 GPL 不相容的授權條款,除非 OpenSSL 可以被視為“系統庫”,它位於*BSD 中)。許多 Linux 發行版將 OpenSSL 視為“系統庫”,但有些發行版(例如 Debian)則不然:在這種情況下,透過連結 OpenSSL-3.0.0 或更高版本可以解決問題。
下載並解壓縮 UxPlay-master.zip,或(如果安裝了 git):「git clone https://github.com/FDH2/UxPlay」。您也可以下載版本中列出的最新或早期版本。
(針對非基於 Debian 的 Linux 或 *BSD 調整這些說明;對於 macOS,請參閱下面的具體說明)。請參閱下面的故障排除以獲取有關任何困難的協助。
您需要一個安裝了標準開發函式庫的 C/C++ 編譯器(例如 g++)。基於 Debian 的系統提供了一個「build-essential」套件用於編譯軟體。您還需要 pkg-config:如果「 which pkg-config
」沒有找到它,請安裝 pkg-config 或其類似的替代品 pkgconf。請同時確保安裝了 cmake>=3.5:「 sudo apt install cmake
」(如果需要,請新增build-essential
和pkg-config
(或pkgconf
))。
確保您的發行版提供 OpenSSL 1.1.1 或更高版本以及 libplist 2.0 或更高版本。 (這意味著基於 Debian 10「Buster」的系統(例如 Ubuntu 18.04)或更新版本;在 Debian 10 系統上「libplist」是舊版本,您需要「libplist3」。)如果沒有,您可能需要建置和安裝這些來自原始程式碼(請參閱本自述文件末尾的說明)。
如果您安裝的是非標準 OpenSSL,則可能需要設定環境變數 OPENSSL_ROOT_DIR(例如,“ export OPENSSL_ROOT_DIR=/usr/local/lib64
”,如果安裝位置在該位置)。同樣,對於非標準(或多個)GStreamer 安裝,請將環境變數 GSTREAMER_ROOT_DIR 設定為包含 UxPlay 應使用的 gstreamer 安裝的「.../gstreamer-1.0/」目錄的目錄(如果是例如「~ /my_gstreamer/ lib/gstreamer-1.0/”,使用“ export GSTREAMER_ROOT_DIR=$HOME/my_gstreamer/lib
”設定此位置)。
在終端機視窗中,將目錄變更為已下載原始碼的來源目錄(「UxPlay-*」、「*」=「master」或zip 檔案下載的發布標記,「UxPlay」用於「git clone」下載),然後請按照以下說明操作:
注意:預設情況下,UxPlay 將針對其所建置的電腦進行最佳化建置;如果不是這種情況,例如打包發行版時,請使用 cmake 選項-DNO_MARCH_NATIVE=ON
。
如果您在 Linux 或 *BSD 上使用 X11 Windows,並希望透過按鍵(F11 或 Alt_L+Enter)切換進入/退出全螢幕模式,則需要依賴 X11 來建立 UxPlay。從 UxPlay-1.59 開始,如果安裝並偵測到 X11 開發庫,則預設會執行此操作。使用“ sudo apt install libx11-dev
”安裝它們。如果偵測到 GStreamer < 1.20,也會進行螢幕分享應用程式(例如Zoom)所需的修復。
-DNO_X11_DEPS=ON
。sudo apt install libssl-dev libplist-dev
"。(除非您需要從原始碼建置 OpenSSL 和 libplist )。sudo apt install libavahi-compat-libdnssd-dev
sudo apt install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
。 (*如果您從原始碼建立 Gstreamer 則跳過)cmake .
(對於更清晰的構建,如果您修改原始程式碼,這會很有用,請將其替換為“ mkdir build; cd build; cmake ..
”:然後您可以根據需要刪除build
目錄的內容,而不會影響-D
。 -DNO_X11_DEPS=ON
-DNO_MARCH_NATIVE=ON
make
sudo make install
(之後您可以在執行此程式的相同目錄中使用sudo make uninstall
進行卸載)。這會將可執行檔「 uxplay
」安裝到/usr/local/bin
,(並將手冊頁安裝到標準位置,例如/usr/local/share/man/man1
並將自述文件安裝到/usr/local/share/doc/uxplay
)。 (如果「man uxplay」失敗,請檢查是否設定了$MANPATH:如果設定了,則需要將線上說明頁的路徑(通常是/usr/local/share/man/)新增至$MANPATH 中。)uxplay 可執行檔也可以是如果您希望在安裝之前進行測試(在這種情況下必須先安裝 GStreamer 外掛程式),則可以在建置過程後的建置目錄中找到。
**對於那些基於 RPM 的發行版,也可以使用 RPM 規格檔案 uxplay.spec:請參閱建置可安裝的 rpm 套件。
Red Hat,或像 CentOS 這樣的克隆(現在繼續作為 Rocky Linux 或 Alma Linux):( sudo dnf install 或sudo yum install) openssl-devel libplist-devel avahi-compat-libdns_sd-devel gstreamer1-devel gstreamer1-plugins-base - devel(+libX11-devel 用於全螢幕 X11) (其中一些可能位於「CodeReady」附加儲存庫中,被複製稱為「PowerTools」)
Mageia、PCLinuxOS、OpenMandriva:與 Red Hat 相同,但名稱變更:(Mageia)「gstreamer1.0-devel」、「gstreamer-plugins-base1.0-devel」; (OpenMandriva)「libopenssl-devel」、「gstreamer-devel」、「libgst-plugins-base1.0-devel」。 PCLinuxOS:與 Mageia 相同,但使用 synaptic(或 apt)作為其套件管理器。
openSUSE: (sudo zypper install) libopenssl-3-devel (以前的libopenssl-devel) libplist-2_0-devel (以前的libplist-devel) avahi-compat-mDNSResponder-devel gstreamer-devel gstreamer-pvel. libX11-開發全螢幕 X11)。
Arch Linux (也可以作為 AUR 中的軟體包提供):(sudo pacman -Syu) openssl libplist avahi gst-plugins-base。
FreeBSD: (sudo pkg install)libplist gstreamer1。也必須安裝 avahi-libdns 或 mDNSResponder 以提供 dns_sd 函式庫。 OpenSSL 已安裝為系統庫。
首次使用 RPM 建構者應先安裝 rpm-build 和 rpmdevtools 軟體包,然後使用「 rpmdev-setuptree
」建立 rpmbuild 樹。然後下載 uxplay.spec 並將其複製到~/rpmbuild/SPECS
中。在該目錄中,執行“ rpmdev-spectool -g -R uxplay.spec
”將對應的來源檔案uxplay-*.tar.gz
下載到~/rpmbuild/SOURCES
(“rpmdev-spectool”也可能簡稱為“spectool” ) );然後執行「 rpmbuild -ba uxplay.spec
」(您將需要安裝此報告所需的任何依賴項)。這應該在~/rpmbuild/RPMS
的子目錄中建立 uxplay RPM 套件。 ( uxplay.spec在 Fedora 38、Rocky Linux 9.2、openSUSE Leap 15.5、Mageia 9、OpenMandriva、PCLinuxOS 上進行了測試;可以輕鬆修改它以包含其他基於 RPM 的發行版的依賴項列表。)
接下來使用sudo apt install gstreamer1.0-
安裝所需的 GStreamer 插件。所需的
值為:
基於 Debian 的發行版將一些插件包分成更小的部分:可能還需要一些插件包,包括用於 OpenGL 支援的「 gl 」(這提供了「-vs glimagesink」videosink,它在許多系統(包括Raspberry Pi )中非常有用),並且在使用 NVIDIA GPU 進行 h264/h265 解碼時應始終使用)、“ gtk3 ”(提供“-vs gtksink”videosink)和“ x ”用於 X11 支持,儘管這些可能已經安裝; Intel 或 AMD 顯示卡的硬體加速 h264 視訊解碼需要「 vaapi 」(但不適用於使用專有驅動程式的 NVIDIA)。如果聲音無法正常運作,則可能需要安裝「 alsa 」、 「 Pulseaudio 」或「 Pipewire 」插件,具體取決於音訊的設定方式。
在某些情況下,由於專利問題,官方發行版中未提供以鏡像模式解碼 AAC 音訊所需的 libav 插件功能avdec_aac :從這些發行版的社群儲存庫中獲取它。
Red Hat 或像 CentOS 這樣的克隆(現在繼續作為 Rocky Linux 或 Alma Linux):安裝 gstreamer1-libav gstreamer1-plugins-bad-free(+ 用於 Intel/AMD 顯示卡的 gstreamer1-vaapi)。在最近的 Fedora 中,gstreamer1-libav 更名為 gstreamer1-plugin-libav。要取得 avdec_aac,請從 rpmfusion.org 安裝軟體包:(從 rpmfusion 取得 ffmpeg-libs;在 RHEL 或克隆版上,但不是最近的 Fedora,也從那裡取得 gstreamer1-libav)。
Mageia、PCLinuxOS、OpenMandriva:安裝 gstreamer1.0-libav gstreamer1.0-plugins-bad(+ 用於 Intel/AMD 顯示卡的 gstreamer1.0-vaapi)。在 Mageia 上,要取得 avdec_aac,請從「受污染的」儲存庫安裝 ffmpeg (它還提供了更完整的 gstreamer1.0-plugins-bad)。
openSUSE:安裝 gstreamer-plugins-libav gstreamer-plugins-bad(+ 用於 Intel/AMD 顯示卡的 gstreamer-plugins-vaapi)。若要取得 avdec_aac,請從 Packman「Essentials」安裝適用於 openSUSE 的 libav* 軟體包;建議:新增Packman儲存庫後,使用YaST軟體管理中的選項將多媒體的所有系統套件切換到Packman)。
Arch Linux安裝 gst-plugins-good gst-plugins-bad gst-libav (+ 用於 Intel/AMD 顯示卡的 gstreamer-vaapi)。
FreeBSD:安裝 gstreamer1-libav、gstreamer1-plugins、gstreamer1-plugins-*(* = core、good、bad、x、gtk、gl、vulkan、pulse、v4l2、...)、(+ gstreamer1-vaapi for Intel/ AMD 顯示卡)。
從 UxPlay-1.64 開始,UxPlay 可以使用從設定檔讀取的選項啟動,該設定檔將是第一個找到的 (1) 路徑由環境變數$UXPLAYRC
指定的文件,(2) 使用者家中的~/.uxplayrc
目錄(“~”),(3) ~/.config/uxplayrc
。格式為每行一個選項,省略命令列選項的開頭"-"
。在設定檔中以"#"
開頭的行將被視為註解並被忽略。
在終端機視窗中執行 uxplay 。在某些系統上,您可以使用-fs
選項指定全螢幕模式,或使用 F11 或(按住左 Alt)+Enter 鍵切換到或退出全螢幕模式。完成後使用 Ctrl-C(或關閉視窗)終止它。如果 iOS 用戶端的下拉「螢幕鏡像」面板看不到 UxPlay 伺服器,請檢查您的 DNS-SD 伺服器(通常是 avahi-daemon)是否正在運作:在終端機視窗中使用systemctl status avahi-daemon
執行此操作。如果這表明 avahi-daemon 沒有運行,請使用sudo systemctl [start,stop,enable,disable] avahi-daemon
控制它(在非 systemd 系統上,例如 *BSD,使用sudo service avahi-daemon [status, start, stop, restart, ...]
)。如果看到 UxPlay,但是客戶端選擇時無法連接,則可能是伺服器上存在防火牆,阻止 UxPlay 接收用戶端連接請求,除非開啟某些網路連接埠:如果防火牆處於活動狀態,也開啟 UDP 連接埠 5353 (用於mDNS 查詢)Avahi 需要。請參閱下面的故障排除以取得有關此問題或其他問題的協助。
與 Apple TV 不同,UxPlay 伺服器預設不要求用戶端使用伺服器顯示的 pin 碼進行初始「配對」(此後用戶端「信任」伺服器,且不需要重複此操作)。從 v1.67 開始,Uxplay 提供了這樣的「pin 驗證」作為選項:如果您想使用它,請參閱「用法」中的「 -pin
」和「 -reg
」以了解詳細資訊。一些具有 MDM(行動裝置管理,通常出現在雇主擁有的裝置上)的用戶端需要使用 PIN 驗證:即使在沒有 PIN 選項的情況下運行,UxPlay 也會提供此功能。
預設情況下,UxPlay 被鎖定到目前客戶端,直到該客戶端斷開連線;從 UxPlay-1.58 開始,選項-nohold
修改了此行為,以便當新用戶端要求連線時,它會刪除目前用戶端並接管。 UxPlay 1.66 引入了一種機制( -restrict
、 -allow
、 -block
)來控制允許哪些客戶端連接,使用它們的「deviceID」(在 Apple 裝置中似乎是不可變的)。
在鏡像模式下,GStreamer 有兩種方法來播放視訊及其伴隨的音訊:在 UxPlay-1.64 之前,視訊和音訊串流在到達後立即播放(GStreamer“ sync=false ”方法) ,使用GStreamer 內部時鐘來嘗試保持它們同步。從 UxPlay-1.64 開始,另一種方法(GStreamer 的「 sync=true 」模式)是新的預設方法,該方法使用用戶端發送的音訊和視訊串流中的時間戳。在低解碼功率 UxPlay 主機(例如 Raspberry Pi Zero W 或 3 B+ 型號)上,這將丟棄無法及時解碼以播放音訊的視訊幀,從而使視訊不穩定,但仍保持同步。
不丟棄後期視訊框架的舊方法在更強大的系統上運作良好,並且仍然可以透過 UxPlay 選項「 -vsync no
」使用;此方法適用於“實時流媒體”,例如,當使用 UxPlay 作為 Mac 計算機的第二個顯示器時可能會更好,而新的默認基於時間戳的方法最適合觀看視頻,以保持嘴唇運動和聲音同步。 (如果不使用時間戳,如果解碼速度不夠快,視訊最終將落後於音訊:硬體加速視訊解碼有助於防止以前在不使用時間戳時出現這種情況。)
-async
timestamp-為基礎的選項。 (例如,如果您想在用戶端上跟隨 Apple Music 歌詞,同時在 UxPlay 伺服器上收聽優質聲音)。這會延遲客戶端上的視頻以匹配伺服器上的音頻,因此在客戶端上啟動的暫停或音軌更改對伺服器播放的音頻生效之前會導致輕微的延遲。 AirPlay 音量控制可將音量(增益)衰減高達 -30dB:分貝範圍 -30:0 可使用選項-db
(“-db Low ”或“-db”從Low :0 或Low : High重新調整) Low : High "), Low必須為負數。重新縮放以分貝為單位呈線性。請注意,GStreamer 的音訊格式將「剪輯」任何高於 +20db 的音訊增益,因此請將「高」保持在該等級以下。選項-taper
提供了一些用戶可能喜歡的「錐形」AirPlay 音量控製設定檔。
-vsync 和 -async 選項還允許以毫秒為單位進行可選的正(或負)音訊延遲調整,以進行微調: -vsync 20.5
相對於視訊延遲音訊 0.0205 秒;負值會推動它。
您可能會發現透過設定 -fps 60 可以改進視頻,該設定允許某些視頻以每秒 60 幀的速度播放。 (您可以使用 -vs fpsdisplaysink 和/或 -FPSdata 查看實際串流傳輸的幀速率。)使用此選項時,您應該使用預設的基於時間戳的同步選項-vsync
。
從 UxPlay-1.54 開始,您可以在純音訊 (ALAC) 模式下顯示來自 Apple Music 等來源的隨附“封面藝術”:在後台運行“ uxplay -ca
”,然後運行具有自動重新加載功能的圖像檢視器功能:例如“feh”:在前台運行“ feh -R 1
”;終止 feh,然後使用「 ctrl-C fg ctrl-C
」終止 Uxplay。
預設情況下,GStreamer 使用演算法來搜尋要使用的最佳「videosink」(GStreamer 術語,表示用於顯示影像的圖形驅動程式)。您可以使用 uxplay 選項-vs
來覆蓋它。哪些視訊接收器可用取決於您的作業系統和圖形硬體:使用「 gst-inspect-1.0 | grep sink | grep -e video -e Video -e image
」來查看可用的內容。 Linux/*BSD 上的一些可能性是:
glimagesink (OpenGL)、 waylandsink
xvimagesink , ximagesink (X11)
kmssink 、 fbdevsink (不含 X11 的控制台圖形)
vaapisink (用於 Intel/AMD 硬體加速圖形);對於 NVIDIA 硬體圖形(帶有 CUDA),請使用glimagesink與“ -vd nvh264dec
”(或“nvh264sldec”,一種新變體,在 GStreamer-1.24 中將成為“nvh264dec”)結合使用。
如果伺服器是「無頭」(沒有連接監視器,僅渲染音訊),請使用-vs 0
。
GStreamer 也會搜尋最好的「音訊接收器」;使用-as
覆蓋其選擇。 Linux 上的選擇包括pulsesink、alsasink、pipewiresink、oss4sink;查看gst-inspect-1.0 | grep sink | grep -e audio -e Audio
.
一個常見問題涉及 GStreamer 嘗試使用配置不正確或缺少加速硬體 h264 視訊解碼(例如 VAAPI)。嘗試「 uxplay -avdec
」強制軟體影片解碼;如果這有效,您可以嘗試修復加速硬體視訊解碼(如果需要),或者只需卸載 GStreamer vaapi 插件。
有關更多運行時選項,請參閱用法。
對於幀緩衝視訊(對於Raspberry Pi OS“Lite”和其他非X11 發行版),請使用KMS 視訊接收器“-vs kmssink”(DirectFB 幀緩衝視訊接收器“dfbvideosink”在Pi 上損壞,並出現段錯誤)。在這種情況下,您應該明確使用“-vs kmssink”選項,因為沒有它,autovideosink 找不到正確的視訊接收器。
Raspberry Pi 5 不提供硬體 H264 解碼(也不需要)。
Pi Zero 2 W、3 Model B+和4 Model B應該使用Broadcom GPU的硬體H264解碼,但它需要Raspberry Pi核心樹中維護的非主流核心模組bcm2835_codec;已知提供它的發行版包括 Raspberry Pi OS、Ubuntu 和 Manjaro-RPi4。如果此模組不可用,請使用軟體解碼(選項 -avdec)。
如果使用硬體 H264 解碼,Uxplay 使用 GStreamer-1.22 及更高版本的 Video4Linux2 (v4l2) 外掛程式存取 GPU。這應該會自動發生。可以使用選項 -v4l2,但通常最好讓 GStreamer 自己找到最佳視訊管道。
在較舊的發行版 (GStreamer < 1.22) 上,v4l2 外掛程式需要補丁:請參閱 UxPlay Wiki。舊版 Raspberry Pi OS (Bullseye) 有一個部分修補的 GStreamer-1.18.4,它需要 uxplay 選項 -bt709(並且不要使用 -v4l2);在這種情況下,最好套用 UxPlay Wiki 中的完整補丁。
對於「雙遺產」Raspberry Pi OS (Buster),沒有適用於 GStreamer-1.14 的補丁。相反,在建置 UxPlay 之前,首先使用這些說明從原始程式碼建立一個完整的更新的 GStreamer-1.18.6。
運行 32 位元作業系統的 Raspberry Pi 3 Model B+ 也可以使用 GStreamer OMX 外掛程式存取 GPU(使用選項「 -vd omxh264dec
」),但這會被 Pi 4 Model B 韌體破壞。 OMX 支援已從 Raspberry Pi OS (Bullseye) 移除,但存在於 Buster 中。
Raspberry Pi 5 型號以及 Raspberry Pi 4 B 型號上的 Broadcom GPU 支援H265 (4K)視訊的硬體解碼。模型尚未實現。啟動 h265 支援需要選項「-h265」。在此模式下首選有線乙太網路連線(客戶端可能需要)。
即使使用 GPU 視訊解碼,低功耗型號也可能會丟棄一些幀,以使用時間戳保持音訊和視訊同步。在舊版 Raspberry Pi OS (Bullseye) 中,raspi-config“性能選項”允許指定分配給 GPU 的內存量,但 Bookworm 中似乎不存在此設置(但仍然可以通過添加一行將其設置為例如 128MB)/boot /config.txt 中的“gpu_mem=128”)。在 32 位元 Bullseye 或 Bookworm Lite 中測試時,Pi Zero 2 W(具有 512MB 記憶體)運作良好,GPU 分配有 128MB(預設值似乎是 64MB)。
R Pi 的基本 uxplay 選項是uxplay [-vs
。選擇
= glimagesink
有時很有用。對於 Wayland 視訊合成器,請使用
= waylandsink
。對於幀緩衝視頻,請使用
= kmssink
。
ssh user@remote_host
export DISPLAY=:0
nohup uxplay [options] > FILE &
聲音和視訊將在遠端主機上播放;如果 ssh 會話關閉,「nohup」將使 uxplay 保持運作。終端輸出保存到 FILE(可以是 /dev/null 來丟棄它)
注意:macOS 12 Monterey 包含本機 AirPlay 伺服器功能,但僅限於最新的硬體。 UxPlay 可以在無法運行 Monterey 的舊版 macOS 系統上運行,或者可以運行 Monterey 但不能運行 AirPlay。
這些適用於 macOS 的說明假定已安裝 Xcode 命令列開發人員工具(如果已安裝 Xcode,請開啟終端,鍵入「sudo xcode-select --install」並接受條件)。
也假設安裝了 CMake >= 3.13:這可以使用套件管理器 MacPorts ( sudo port install cmake
)、Homebrew ( brew install cmake
) 或從 https://cmake.org/download/ 下載來完成。如果您要使用 git 來取得 UxPlay,也請安裝git
。
接下來安裝 libplist 和 openssl-3.x。請注意,這些庫的靜態版本將在 macOS 建置中使用,因此如果您願意,可以在建置 uxplay 後卸載它們。
如果您使用 Homebrew: brew install libplist openssl@3
如果您使用 MacPorts: sudo port install libplist-devel openssl3
否則,從原始程式碼建立 libplist 和 openssl:請參閱本自述文件末尾附近的說明;需安裝開發工具(autoconf、automake、libtool等)。
接下來取得最新的 macOS 版本的 GStreamer-1.0。
使用「官方」GStreamer(推薦 MacPorts 和 Homebrew 用戶) :從 https://gstreamer.freedesktop.org/download/ 安裝適用於 macOS 的 GStreamer 版本。 (此版本包含自己的 pkg-config,因此您無需安裝。)安裝 gstreamer-1.0 和 gstreamer-1.0-devel 軟體包。下載後,按住 Shift 鍵並點擊它們進行安裝(它們安裝到 /Library/FrameWorks/GStreamer.framework)。如果 Homebrew 或 MacPorts 使用者使用「官方」版本,則不應安裝(或不應卸載)其套件管理器提供的 GStreamer。
使用 Homebrew 的 GStreamer :需要 pkg-config:(「brew install pkg-config gstreamer」)。這會導致 Homebrew 安裝大量額外的軟體包作為依賴項。 Homebrew gstreamer 安裝最近已重新設計為名為gstreamer
單一“公式”,現在無需在環境中設定 GST_PLUGIN_PATH 即可運行。 Homebrew 將 gstreamer 安裝到(HOMEBREW)/lib/gstreamer-1.0
,其中(HOMEBREW)/*
在 Apple Silicon Mac 上是/opt/homebrew/*
,在 Intel Mac 上是/usr/local/*
;不要在那裡放置任何額外的非 Homebrew 插件(您自己建造的),而是將 GST_PLUGIN_PATH 設定為指向它們的位置(Homebrew 不提供完整的 GStreamer,但似乎擁有 UxPlay 所需的一切)。
使用從 MacPorts 安裝的 GStreamer :不建議這樣做,因為目前 MacPorts GStreamer 很舊(v1.16.2),未維護,並且建置為使用 X11:
(如果您確實希望使用 MacPorts GStreamer-1.16.2,請安裝 pkgconf(“sudo port install pkgconf”),然後“sudo port install gstreamer1-gst-plugins-base gstreamer1-gst-plugins-good gstreamer1-gst-plugins - bad gstreamer1-gst-libav"。要在macOS 上支援X11,請使用特殊的cmake 選項-DUSE_X11=ON
編譯UxPlay,並使用-vs ximagesink 從XQuartz 終端運行它;較舊的非視網膜Mac 在使用時需要較低的解析度X11: uxplay -s 800x600
。
安裝GStreamer 後,建置並安裝uxplay:開啟終端並切換到UxPlay 來源目錄(「UxPlay-master」用於zip 檔案下載,「UxPlay」用於「git clone」下載)並使用「cmake . ; make ; 建置/安裝” sudo make install "(與 Linux 相同)。
在檢查GStreamer 警告時運行UxPlay(在運行UxPlay 之前使用「export GST_DEBUG=2」執行此操作)顯示,預設(自UxPlay 1.64 起)使用時間戳進行視訊同步,許多視訊幀被丟棄(僅在macOS 上) ,可能是由於 GStreamer 警告中顯示的另一個錯誤(關於 videometa)。建議:使用新的UxPlay「無時間戳記」選項「 -vsync no
」 (您可以在uxplayrc設定檔中新增一行「vsync no」)。
在安裝了 GStreamer 的 macOS 上,唯一可用的 videosink 似乎是 glimagesink(autovideosink 的預設選擇)和 osxvideosink。視窗標題不顯示Airplay 伺服器名稱,但該視窗對螢幕共用應用程式(例如Zoom)可見。唯一可用的音訊接收器似乎是 osxaudiosink。
無論是否選擇,請始終使用選項 -nc。這是針對 macOS 上 GStreamer 視訊接收器問題的解決方法:如果在鏡像視窗仍開啟時 GStreamer 管道被破壞,則會發生段錯誤。
對於 glimagesink,解析度設定「-s wxh」不會影響(小)初始 OpenGL 鏡像視窗大小,但可以使用滑鼠或觸控板擴展該視窗。相反,使用“-vs osxvideosink”創建的視窗最初很大,但寬高比錯誤(拉伸圖像);在這種情況下,當透過拖曳視窗的一側來變更視窗寬度時,縱橫比會發生變化;選項-vs "osxvideosink force-aspect-ratio=true"
可用於使視窗在首次開啟時具有正確的寬高比。
下載並安裝Bonjour SDK for Windows v3.0 。您可以在 softpedia.com 上下載 SDK,無需任何註冊,或從 Apple 官方網站 https://developer.apple.com/download 獲取(Apple 讓您註冊為開發人員,以便從他們的網站訪問它)。這應該會將 Bonjour SDK 安裝為C:Program FilesBonjour SDK
。
(這是針對 64 位元 Windows 的;32 位元 Windows 的建置應該是可能的,但尚未測試。)將使用類似 UNIX 的 MSYS2 建置環境:從官方網站 https://www 下載並安裝 MSYS2 .msys2.org/ 。接受預設安裝位置C:mysys64
。
MSYS2 軟體套件與 Arch Linux 使用的「pacman」軟體套件管理器的變體一起安裝。從 Windows 開始功能表中的 MSYS2 標籤開啟「MSYS2 MINGW64」終端,並使用「pacman -Syu」更新新的 MSYS2 安裝。然後安裝MinGW-64編譯器和cmake
pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc
具有所有必要依賴項的編譯器將安裝在 msys64 目錄中,預設路徑為C:/msys64/mingw64
。在這裡,我們將簡單地從 MSYS2 環境中的命令列建置 UxPlay(對於建置系統,使用“ ninja
”代替“ make
”)。
從 github 下載最新的 UxPlay (要使用git
,請使用pacman -S git
安裝它,然後「 git clone https://github.com/FDH2/UxPlay
」) ,然後安裝UxPlay 依賴項(openssl 已隨MSYS2 安裝) :
pacman -S mingw-w64-x86_64-libplist mingw-w64-x86_64-gstreamer mingw-w64-x86_64-gst-plugins-base
如果您正在嘗試不同的 Windows 建置系統,可以從官方 GStreamer 網站取得適用於 Windows 的 GStreamer 的 MSVC 版本,但僅對 MSYS2 上的 MinGW 64 位元建置進行了測試。
cd 到 UxPlay 來源目錄,然後「 mkdir build
」和「 cd build
」。建造過程假設 Bonjour SDK 安裝在C:Program FilesBonjour SDK
。如果在其他地方,請設定環境變數 BONJOUR_SDK_HOME 指向其位置。然後建構 UxPlay
cmake ..
ninja
假設其中任何一個都沒有錯誤,您將在目前(“build”)目錄中建立 uxplay 可執行檔uxplay.exe 。其他版本中提供的「sudo make install」和「sudo make uninstall」功能在 Windows 上不可用;相反,MSYS2 環境具有/mingw64/...
可用,您可以在C:/msys64/mingw64/bin
中安裝 uxplay.exe 可執行檔(以及C:/msys64/mingw64/share/...
中的線上說明頁和文件) ) 和
cmake --install . --prefix /mingw64
為了能夠查看線上說明頁,您需要使用「 pacman -S man
」安裝線上說明頁檢視器。
要執行uxplay.exe,您需要使用pacman -S mingw-w64-x86_64-gst-
安裝一些 gstreamer 插件包,其中所需的具有由以下給出的
您可能使用的其他可能的 MSYS2 gstreamer 外掛程式包列在 MSYS2 包中。
您還需要向 uxplay 可執行檔 uxplay.exe 授予透過 Windows 防火牆存取資料的權限。當您第一次執行 uxplay 時,系統可能會自動向您提供執行此操作的選擇,或者您可能需要使用Windows 設定-> 更新和安全性-> Windows 安全性-> 防火牆和網路保護-> 允許應用程式通過防火牆來執行此操作。如果您的病毒防護將 uxplay.exe 標記為「可疑」(但沒有真正的惡意軟體簽章),您可能需要給它一個例外。
現在透過執行「 uxplay
」(在 MSYS2 終端機視窗中)進行測試。如果您需要指定音訊接收器,Windows 上有兩個主要選擇:較舊的 DirectSound 插件“ -as directsoundsink
”,以及更現代的 Windows 音訊會話 API (wasapi) 插件“ -as wasapisink
”,它支援其他選項,例如
uxplay -as 'wasapisink device=""'
其中
透過其 GUID 指定可用的音訊設備,可以使用「 gst-device-monitor-1.0 Audio
」找到該設備:
形式類似於{0.0.0.00000000}.{98e35b2b-8eba-412e-b840-fd2c2492cf44}
.如果未指定“ device
”,則使用預設音訊裝置。
如果您希望使用-vs
選項指定視訊接收器,則
的一些選擇是d3d11videosink
、 d3dvideosink
、 glimagesink
、 gtksink
。
-vs "d3d11videosink fullscreen-toggle-mode=property fullscreen=true"
始終處於全螢幕模式,或者能夠使用 Alt-Enter 鍵切換到或退出全螢幕模式與選項-vs "d3d11videosink fullscreen-toggle-mode=alt-enter"
組合。為了方便起見,如果僅使用-vs d3d11videosink
(帶或不帶全螢幕選項“-fs”),則會新增這些選項。 (Windows 使用者可能希望將「 vs d3d11videosink
」(無首字母「 -
」)新增至 UxPlay 啟動選項檔案;請參閱「man uxplay」或「uxplay -h」。)可執行檔 uxplay.exe 也可以在沒有 MSYS2 環境的情況下在 Windows 終端機中使用C:msys64mingw64binuxplay
運行。
選項:
-
」字元)(由環境變數$UXPLAYRC
或~/.uxplayrc
或~/.config/uxplayrc
給出);以「 #
」開頭的行被視為註解並被忽略。命令列選項取代啟動檔案中的選項。-n 伺服器名稱(預設:UxPlay); server_name@ hostname將是為您的 iPad、iPhone 等提供 AirPlay 服務的名稱,其中hostname是執行 uxplay 的伺服器的名稱。現在,這也將是鏡像顯示 (X11) 視窗上方顯示的名稱。
-nh不要在 AirPlay 伺服器名稱末尾附加「@主機名稱」。
-h265啟動「ScreenMultiCodec」支援(AirPlay「功能」位元 42),以便在螢幕鏡像模式下除了 h264 視訊 (1080p) 之外還接受 h265 (4K/HEVC) 視訊。使用此選項時,將建立兩個「視訊管道」(一個用於 h264,一個用於 h265)。如果管道中的任何 GStreamer 插件特定於 h264 或 h265,則每個管道中將使用正確的版本。對於 4K 視頻,有線客戶端-伺服器乙太網路連接優於 Wifi,並且客戶端可能需要這種連接。如果請求解析度「-s wxh」且 h > 1080,則只有最新的 Apple 裝置(M1/M2 Mac 或 iPad 以及某些 iPhone)可以傳送 h265 影片。 「-h265」選項將預設解析度(「-s」選項)從 1920x1080 變更為 3840x2160,並將預設最大幀速率(「-fps」選項)保留為 30fps。
-pin [nnnn] :(自 v1.67 起)當新用戶端第一次連線時使用 Apple 風格(一次性)「pin」驗證:終端機上顯示四位數的 pin 程式碼,且用戶端螢幕顯示登入提示,需要輸入此資訊。當「-pin」單獨使用時,每次認證都會選擇一個新的隨機pin碼;如果使用“-pin nnnn”(例如“-pin 3939”),這將設定一個不變的固定代碼。身份驗證將伺服器新增至客戶端的「受信任伺服器」清單中,並且只要用戶端和伺服器公鑰保持不變,用戶端就不需要重新進行身份驗證。 (預設情況下,從 v1.68 開始,伺服器公鑰是從 MAC 位址產生的,可以使用 -m 選項變更該位址;請參閱 -key 選項以取得金鑰產生的替代方法)。 (如果您希望 UxPlay 伺服器使用 pin 驗證協議,請在 UxPlay 啟動檔案中新增一行「pin」)。
-reg [檔名] :(自 v1.68 起)。如果使用“-pin”,則此選項在 $HOME/.uxplay.register (或可選地,在filename中)維護經過 pin 驗證的“受信任客戶端”的暫存器。如果沒有此選項,跳過 PIN 驗證的返回用戶端將受到信任且不會被檢查。如果 UxPlay 用於更公開的環境中,此選項可能會很有用,以記錄用戶端詳細資訊;暫存器是文本,每個客戶端一行,包含客戶端的公鑰(base-64 格式)、裝置 ID 和裝置名稱;註解掉(使用「#」)或刪除行會取消註冊對應的用戶端(請參閱選項 -restrict、-block、-allow 以了解更多控制客戶端存取的方法)。 (如果您想使用此功能,請在啟動檔案中新增一行「reg」。)
-vsync [x] (在鏡像模式下:)此選項(現在是預設值)使用時間戳將伺服器上的音訊與視訊同步,可選音訊延遲(十進位)毫秒( x =“20.5”表示0.0205 秒延遲:允許小於一秒的正延遲或負延遲。
-vsync no (在鏡像模式下:)這會關閉基於時間戳的音訊視訊同步,恢復 UxPlay-1.64 之前的預設行為。標準桌面系統似乎在不使用時間戳的情況下運作良好:此模式適合“即時串流”,例如使用 UxPlay 作為 mac 電腦的第二個顯示器,或監控網路攝影機;有了它,視頻幀不會丟失。
-async [x] (在純音訊 (ALAC) 模式下:)此選項使用時間戳將伺服器上的音訊與客戶端上的視訊同步,並具有可選的音訊延遲(十進位)毫秒( x =“20.5 」表示0.0205秒延遲:允許小於一秒的正或負延遲。)因為客戶端添加了視頻延遲來考慮延遲,所以異步模式下的伺服器添加了等效的音頻延遲,這意味著音頻發生變化,例如暫停或軌道變更不會立即生效。原則上,可以透過使用-al
音訊延遲設定來更改伺服器向客戶端報告的延遲(預設為 0.25 秒)來緩解此問題,但目前更改此設定似乎沒有任何效果。
-異步沒有。這仍然是純音訊模式下的預設行為,但此選項可用作關閉「uxplayrc」設定檔中設定的-async
選項的命令列選項。
-db low [: high ]將 AirPlay 音量控制衰減(增益)從 -30dB:0dB 重新調整為low :0dB 或low : high 。下限low必須為負值(衰減);上限高點可以是任一符號。 (GStreamer 將音量增強限制為高,使其不能超過 +20dB)。重新縮放是「平坦」的,因此對於 -db -50:10,Airplay 衰減 -7dB 的變化會轉換為 -7 x (60/30) = -14dB 衰減,並且最大音量 (AirPlay 0dB)是10dB 增強, Airplay -30dB 將變成-50dB。請注意,最小 AirPlay 值(準確地說是 -30dB)被轉換為「靜音」。
-taper提供「錐形」Airplay 音量控制設定檔(與shairport-sync 中稱為「dasl-tapering」的設定檔相符):每次音量滑桿的長度(或靜音上方的步數,其中16 步=完整)音量)減少 50%,感知音量減半(衰減 10dB)。 (這是在低音量時修改的,如果聲音較大,則使用“非錐形”音量。)
-s wxh例如 -s 1920x1080 (= "1080p"),h264 視訊的預設寬度和高度解析度(以像素為單位)。 (使用 -h265 選項時,預設解析度變為 3840x2160(=“4K”)。)這只是向 AirPlay 用戶端發出的請求,可能不是您獲得的最終解析度。 w和h是四位或更少的整數。請注意,高度像素大小是客戶端用於確定流格式的控制像素;寬度會根據影像的形狀動態調整(縱向或橫向格式,例如取決於 iPad 的握持方式)。
-s wxh@r如上所述,但也通知 AirPlay 用戶端有關顯示器的螢幕更新率。預設值為 r=60 (60 Hz); r 必須是小於 256 的整數。
-o開啟顯示視窗的「過掃描」選項。這透過使用選項 -s wxh 請求的一些像素(或其預設值 1920x1080),透過添加未使用像素的空邊界框(在過掃描的全螢幕顯示中會遺失,並且不會丟失)來降低影像解析度。由gstreamer 顯示)。建議:除非有特殊原因,否則不要使用此選項。
-fs使用全螢幕模式,但僅適用於 X11、Wayland、VAAPI 和 D3D11 (Windows)。
-p可讓您選擇 UxPlay 使用的網路連接埠(如果伺服器位於防火牆後面,則需要開啟這些連接埠)。 -p 本身設定「舊」埠 TCP 7100、7000、7001、UDP 6000、6001、7011。 -p n1,n2,n3(逗號分隔值)分別設定每個連接埠; -p n1,n2 設定連接埠 n1,n2,n2+1。 -p tcp n 或 -p udp n 僅設定 TCP 或 UDP 連接埠。連接埠必須在 [1024-65535] 範圍內。
如果不使用 -p 選項,則會動態(隨機)選擇端口,如果防火牆正在運行,則該端口將不起作用。
-avdec強制使用 Gstreamer 元素 avdec_h264(libav h264 解碼器)進行軟體 h264 解碼。此選項應防止 autovideosink 選擇硬體加速的 videosink 插件,例如 vaapisink。
-vp解析器選擇 GStreamer 管道的 h264 解析器元素,預設為 h264parse。使用引號“...”可以新增選項。
-vd解碼器選擇 GStreamer 管道的 h264 解碼器元素,而不是為您選擇的預設值「decodebin」。軟體解碼由avdec_h264完成;各種硬體解碼器包括:vaapih264dec、nvdec、nvh264dec、v4l2h264dec(這些需要有適當的硬體可用)。使用引號“...”允許將某些參數包含在解碼器名稱中。
-vc轉換器選擇GStreamer管道的videoconverter元素,而不是預設值「videoconvert」。當使用 GPU 進行 Video4Linux2 硬體解碼時, -vc v4l2convert
也將使用 GPU 進行視訊轉換。使用引號“...”允許轉換器名稱包含一些參數。
-vs videosink選擇 GStreamer 視訊接收器,而不是為您選擇的預設值「autovideosink」。一些videosink 選項包括:ximagesink、xvimagesink、vaapisink(適用於英特爾顯示卡)、gtksink、glimagesink、waylandsink、osxvideosink(適用於macOS)、kmssink(適用於沒有X11 的系統,如Raspberry Pi OS lite)或顯示串流媒體幀速率)幀率)。使用引號“...”允許視訊接收器名稱中包含一些參數。例如,vaapisink外掛程式支援全螢幕模式,透過-vs "vaapisink fullscreen=true"
取得;這也適用於waylandsink
。此類選項的語法特定於給定插件(請參閱 GStreamer 文件),並且某些 videosink 選擇可能不適用於您的系統。
-vs 0抑制串流影片的顯示。在鏡像模式下,客戶端的螢幕仍以每秒 1 幀的降低速率進行鏡像,但不進行渲染或顯示。如果伺服器是「無頭」(沒有連接螢幕來顯示視訊),並且僅用於渲染音頻,則應始終使用此選項,這將是鏡像模式下的AAC 有損壓縮音頻,具有未渲染的視訊和優質ALAC僅為 Airplay 音訊模式的 Apple 無損音訊。
-v4l2 Video4Linux2 在 GPU 中進行硬體 h264 視訊解碼的視訊設定。相當於-vd v4l2h264dec -vc v4l2convert
。
-bt709解決舊版 Video4Linux2 外掛無法識別 Apple 使用數位電視 bt709 顏色標準的不常見(但允許)「全範圍顏色」變體的解決方法。 GStreamer-1.20.4 及其向後移植不再需要它。
-rpi相當於「-v4l2 」(對 Raspberry Pi 型號 5 無效,並在 UxPlay 1.67 中刪除)
-rpigl相當於「-rpi -vs glimagesink」。 (自 UxPlay 1.67 起已刪除)
-rpifb相當於「-rpi -vs kmssink」(自 UxPlay 1.67 起已刪除)
-rpiwl相當於「-rpi -vs waylandsink」。 (自 UxPlay 1.67 起已刪除)
-asaudiosink選擇 GStreameraudiosink,而不是讓 autoaudiosink 為您選擇它。一些音訊接收器選擇包括:pulsesink、alsasink、pipewiresink、osssink、oss4sink、jackaudiosink、osxaudiosink(適用於 macOS)、wasapisink、directsoundsink(適用於 Windows)。使用引號“...”可能允許一些可選參數(例如-as "alsasink device=..."
來指定非預設輸出裝置)。此類選項的語法特定於給定插件(請參閱 GStreamer 文件),並且某些音訊接收器選擇可能不適用於您的系統。
-as 0 (或只是-a )禁止播放串流音頻,但顯示串流視訊。
-al x指定純音訊 (ALAC) 中的音訊延遲x (十進位)秒,報告給客戶端。允許使用 [0.0, 10.0] 秒範圍內的值,並將轉換為整數微秒。預設值為 0.25 秒 (250000 usec)。 (但是,客戶端似乎忽略了報告的延遲,因此此選項似乎不起作用。)
-ca filename提供一個檔案(其中檔案名稱可以包含完整路徑),用於在純音訊 ALAC 模式下輸出「封面藝術」(來自 Apple Music等)。該文件在到達時會被最新的封面藝術覆蓋。如果不使用此選項,封面藝術(jpeg 格式)將被丟棄。與圖像檢視器一起使用,如果圖像發生變化,則該圖像檢視器會重新載入圖像,或定期(例如每秒一次)。要實現此目的,請在背景執行“ uxplay -ca [path/to/]filename &
”,然後在前台執行映像檢視器。例如,使用feh
作為檢視器:執行「 feh -R 1 [path/to/]filename
」(在 uxplay 置於後台的相同終端視窗中)。要退出,請使用ctrl-C fg ctrl-C
終止影像檢視器,將uxplay
置於前台,然後也終止它。
-reset n設定客戶端回應來自伺服器的 ntp 請求的連續n次逾時失敗的限制(每 3 秒發送一次,以檢查客戶端是否仍然存在,並與其同步)。在n 次失敗後,客戶端將假定為離線,並且連線將被重置以允許新的連線。 n的預設值為5;值n = 0 表示超時「無限制」。
-nofreeze在因 ntp 逾時而重置後關閉視訊視窗(預設情況下將視窗保持開啟以允許更順利地重新連接到相同客戶端)。此選項在全螢幕模式下可能很有用。
-nc保持先前的 UxPlay < 1.45 行為,即當客戶端發送「停止鏡像」訊號時不會關閉視訊視窗。目前,macOS 中預設使用此選項,因為如果 GStreamer 管道關閉時視窗仍處於開啟狀態,則 GStreamer 在 macOS 中建立的視窗將無法正確終止(會導致段錯誤)。
-nohold當新客戶端嘗試連線時中斷目前連線。如果沒有此選項,目前用戶端將保持 UxPlay 的獨佔所有權,直到斷開連線為止。
-restrict限制允許連線到-allow
指定的客戶端。 deviceID 具有 MAC 位址的形式,當用戶端嘗試連線時,UxPlay 將顯示該位址,而該裝置 ID 似乎是不可變的。它的格式為XX:XX:XX:XX:XX:XX
,X = 0-9,AF,並且可能是裝置的「真實」硬體 MAC 位址。請注意,iOS 用戶端通常會將不同的隨機「私有Wi_Fi 位址」(「假」MAC 位址)暴露給不同的網路(出於隱私原因,以防止追蹤),這些位址可能會發生變化,並且與deviceID不對應。
-restrict no刪除限制(預設)。這作為命令列參數非常有用,可以覆蓋啟動檔案中設定的限制。
-allow id當強制實施客戶端限制時,將 deviceID = id加入到允許的客戶端清單中。通常這將是 uxplayrc 啟動檔案中的一個條目。
-block id始終阻止 deviceID = id的客戶端,即使通常不強制執行客戶端限制。通常這將是 uxplayrc 啟動檔案中的一個條目。
-FPSdata開啟對客戶端發送的有關視訊串流效能的定期報告的監控。如果使用此選項,這些將顯示在終端機視窗中。資料由客戶端以 1 秒的間隔更新。
-fps n設定 AirPlay 用戶端串流影片的最大幀率(以每秒幀數為單位); n 必須是小於 256 的整數。) 60 fps 的設定可能會改善視訊質量,但不建議在 Raspberry Pi 上使用。如果您同時執行多個 uxplay 實例,低於 30 fps 的設定可能有助於減少延遲。此設定只是對客戶端裝置的建議,因此設定高值不會強制採用高幀速率。 (您可以使用「-vs fpsdisplaysink」進行測試以查看正在接收的幀速率,或使用選項 -FPSdata 顯示用戶端在視訊串流期間連續發送的視訊串流效能資料。)
-f {H|V|I}實現「視訊翻轉」影像變換:H = 水平翻轉(左右翻轉,或鏡像); V = 垂直翻轉; I = 180 度旋轉或反轉(它是 H 與 V 的組合)。
-r {R|L}右(順時針)或左(逆時針)旋轉 90 度;這些影像變換是在任何-f變換之後執行的。
-m [mac]更改UxPlay使用的MAC位址(裝置ID)(預設是使用主機網路卡報告的真實硬體MAC位址)。 (如果您嘗試在同一台電腦上執行多個uxplay 實例,則每個執行的uxplay 都需要不同的伺服器名稱、MAC 位址和網路連接埠。)如果[mac](格式為xx:xx:xx:xx: xx: xx,6 個十六進位八位元組)未給出,則會產生隨機 MAC 位址。如果 UxPlay 無法找到網路卡的真實 MAC 位址(更具體地說,偵測到的第一個活動網路介面所使用的 MAC 位址),即使未指定選項-m ,也會使用隨機 MAC 位址。 (請注意,每次啟動 UxPlay 時,隨機 MAC 位址都會不同)。
-key [ filename ] :預設情況下,用於產生和儲存持久公鑰(-pin 選項所需)的(更安全)選項已被替換為(不太安全)方法,該方法從伺服器的「裝置ID 」產生金鑰「(MAC位址,可以使用-m選項更改,方便地作為啟動檔案選項)。使用 -key 選項時,將產生安全產生的金鑰對並將其儲存在$HOME/.uxplay.pem
中(如果該檔案不存在),或從該檔案讀取(如果存在)。 (可選地,金鑰可以儲存在filename中。)此方法比新的預設方法更安全(因為裝置 ID 在 DNS_SD 公告中廣播),但仍然將私鑰暴露給任何可以存取 pem 檔案的人。此選項應在 UxPlay 啟動檔案中設定為行“key”或“key filename ”(無首字母“-”),其中檔案名稱是完整路徑,應用引號括起來( "...."
),如果它包含任何空格。由於預設方法比較簡單,且客戶端存取 uxplay 的安全性不太可能成為重要問題,因此不再建議使用 -key 選項。
-dacp [ filename ] :將目前用戶端 DACP-ID 和 Active-Remote 金鑰匯出到檔案:預設為 $HOME/.uxplay.dacp。 (可以選擇更改為filename )。可供遠端控制應用程式使用。文件是暫時的:僅在客戶端連線時存在。
-vdmp將 h264 影片轉儲到檔案 videodump.h264。 -vdmp n 將不超過 n 個 NAL 單元轉儲到 videodump.x.h264; x= 1,2,... 每次 SPS/PPS NAL 單元到達時都會增加。若要變更名稱videodump ,請使用 -vdmp [n] filename 。
-admp將音訊轉儲到檔案audiodump.x.aac(AAC-ELD 格式音訊)、audiodump.x.alac(ALAC 格式音訊)或audiodump.x.aud(其他格式音訊),其中x = 1,2, 3 ...每次音訊格式改變時都會增加。 -admp n將轉儲到檔案的資料包數量限制為n或更少。若要變更名稱audiodump ,請使用 -admp [n] filename 。請注意,(與轉儲的視訊不同)轉儲的音訊目前僅用於調試,因為它沒有被容器化以使其可以使用標準音訊播放器播放。
-d啟用調試輸出。注意:這不會顯示 GStreamer 錯誤或偵錯訊息。若要查看 GStreamer 錯誤和警告訊息,請在執行 uxplay 之前將環境變數 GST_DEBUG 設定為「export GST_DEBUG=2」。若要查看 GStreamer 資訊訊息,請設定 GST_DEBUG=4;對於 DEBUG 訊息,GST_DEBUG=5;增加此值可以查看更多 GStreamer 內部工作原理。
注意: uxplay
從終端命令列運行,資訊性訊息將寫入終端。
一位使用者(在 Ubuntu 上)發現編譯失敗,並顯示有關連結到「usr/local/lib/libcrypto.a」和「zlib」的訊息。這是因為(除了 libssl-dev 的標準 ubuntu 安裝之外),使用者沒有意識到 /usr/local 中存在第二個帶有 libcrypto 的安裝。解決方案:當存在多個 OpenSSL 安裝時,將環境變數 OPEN_SSL_ROOT_DIR 設定為指向正確的一個;在 64 位元 Ubuntu 上,這是透過在執行 cmake 之前執行export OPENSSL_ROOT_DIR=/usr/lib/X86_64-linux-gnu/
來完成的。
UxPlay 需要 DNS_SD 服務發現(「Bonjour」或「Zeroconf」)服務才能正常運作。在 Linux 上,它通常由 Avahi 提供,要解決此問題,您應該使用工具avahi-browse
。 (您可能需要安裝一個名稱如avahi-utils
的單獨軟體包才能獲得此功能。)
在 Linux 上,請確保安裝了 Avahi,並在執行 uxplay 的系統上啟動 avahi-daemon 服務(您的發行版將記錄如何執行此操作,例如: sudo systemctl
或sudo service avahi-daemon
,使用
啟用、停用、啟動、停止、狀態之一 您可能需要編輯 avahi-daemon.conf 檔案(通常位於 /etc/avahi/ 中,使用「 sudo find /etc -name avahi-daemon.conf
"):確保未選擇「停用發布」選項)。某些系統可能會使用 mdnsd 守護程序作為提供 DNS-SD 服務的替代方案。 (FreeBSD 提供了兩種選擇,但僅測試了 Avahi;請參閱此處。)
如果 UxPlay 停止並顯示「未找到 DNS-SD 伺服器」訊息,這表示您的網路沒有正在執行的 Bonjour/zeroconf DNS-SD 伺服器。在 v1.60 之前,如果 DNS-SD 服務註冊失敗,UxPlay 會靜靜地停止,但現在如果沒有找到 DNS-SD 伺服器,則會停止並顯示 DNSServiceRegister 函數傳回的錯誤訊息:kDNSServiceErr_Unknown :(一位NixOS 用戶發現在NixOS 中,如果 avahi-daemon 服務在啟用發布的情況下運行,但報告“通過將 services.avahi.openFirewall 設置為 true,該錯誤在 NixOS 上消失”,也可能會發生此錯誤。錯誤代碼的範圍為FFFE FF00 (-65792)到 FFFE FFFF (-65537),並列在 dnssd.h 檔案中。可以在這裡找到該版本的舊版本(avahi 使用的版本)。 Apple 的更高版本中定義了一些額外的錯誤代碼。
如果 UxPlay 停止運作且沒有錯誤訊息且用戶端上沒有顯示伺服器名稱,則這是網路問題(如果您的 UxPlay 版本早於 1.60,這也是未找到 DNS-SD 伺服器時的行為。)
從用戶端檢查此類網路問題的一個有用工具是 Apple App Store 中提供的(免費)Discovery DNS-SD 瀏覽器,適用於 iOS(也適用於 iPadOS)和 macOS。
如果您的路由器有此問題,報告的「修復」是(至少在 5GHz 上)使用固定頻道和/或固定(非動態)頻道寬度。
這通常是因為 Avahi 僅使用「環回」網路接口,並且沒有從 UxPlay 啟動時未偵聽的新客戶端接收 mDNS 查詢。
要檢查這一點,啟動 uxplay 後,在伺服器上的不同終端視窗中使用實用程式avahi-browse -a -t
來驗證 UxPlay AirTunes 和 AirPlay 服務是否已正確註冊(「Legacy」中僅使用 AirTunes 服務) UxPlay使用的AirPlay Mirror模式,但初次接觸時使用AirPlay服務)。
avahi-browse 傳回的結果應該會顯示 uxplay 的條目,例如
+ eno1 IPv6 UxPlay AirPlay Remote Video local
+ eno1 IPv4 UxPlay AirPlay Remote Video local
+ lo IPv4 UxPlay AirPlay Remote Video local
+ eno1 IPv6 863EA27598FE@UxPlay AirTunes Remote Audio local
+ eno1 IPv4 863EA27598FE@UxPlay AirTunes Remote Audio local
+ lo IPv4 863EA27598FE@UxPlay AirTunes Remote Audio local
如果僅顯示環回(「lo」)項目,則 UxPlay 主機上的防火牆可能會阻止完整的 DNS-SD 服務,並且您需要為 mDNS 請求開啟預設 UDP 連接埠 5353,作為基於環回的 DNS-SD 服務是不可靠的。
如果 avahi-browse 列出了 UxPlay 服務,但用戶端看不到,則問題很可能是本機網路問題。
這表示DNS-SD服務正在工作,客戶端聽到 UxPlay 可用,但 UxPlay 伺服器未收到客戶端的回應。這通常是因為伺服器上的防火牆阻止了來自客戶端的連線請求。 (一位堅持認為防火牆已關閉的用戶結果有兩個活動防火牆( firewalld和ufw )都在伺服器上運行!)如果可能,請關閉防火牆以查看是否存在問題,或者獲取三個連續的網路端口,從連接埠n 開始,所有三個連接埠都在1024-65535 範圍內,為tcp 和udp 打開,並使用“uxplay -pn”(或打開UDP 7011,6001,6000 TCP 7100,7000,7001 並使用“uxplay -p ”)。
如果您確實確定沒有防火牆,您可能需要使用 netstat 等工具來調查您的網路傳輸,但這幾乎總是防火牆問題。
如果您沒有看到訊息raop_rtp_mirror starting mirroring
,則在客戶端-伺服器協商完成之前出現了問題。對於此類問題,請使用“uxplay -d”(偵錯日誌選項)查看發生了什麼:它將顯示在發生故障之前連接過程進行了多遠。您可以在 UxPlay Wiki 中將偵錯輸出與 UxPlay 成功啟動的輸出進行比較。
如果 UxPlay 報告鏡像已啟動,但您沒有收到視頻或音頻,則問題可能來自於您的系統上無法運行的 GStreamer 插件(默認情況下,GStreamer 使用“autovideosink”和“autoaudiosink”演算法來猜測是什麼)在您的系統上使用的“最佳”插件)。當有防火牆的使用者只開啟兩個 udp 網路連接埠時,會出現沒有音訊的另一個原因:需要三個(第三個接收音訊資料)。
Raspberry Pi裝置( Pi 4B+ 及更早版本:這不適用於 Pi 5,它不提供硬體 h264 解碼,也不需要它)如果 GStreamer v1.20 中的 Video4Linux2 插件最適合使用硬體 GPU h264 視訊解碼。更早版本已修補(有關修補程序,請參閱UxPlay Wiki)。此問題已在 GStreamer-1.22 中修復,並透過在 Raspberry Pi OS (Bullseye) 等發行版中向後移植補丁來修復:將選項-bt709
與 Raspberry Pi OS 中的 GStreamer-1.18.4 一起使用。這也需要標準 Linux 核心中沒有的 bcm2835-codec 核心模組(它在 Raspberry Pi OS、Ubuntu 和 Manjaro 中可用)。
-avdec
進行軟體 h264 解碼。有時“autovideosink”可能會選擇 OpenGL 渲染器“glimagesink”,該渲染器可能無法在您的系統上正常運作。嘗試使用選項“-vs ximagesink”或“-vs xvimagesink”,看看使用其中一個是否可以解決問題。
其他報告的問題與 GStreamer VAAPI 外掛程式有關(適用於硬體加速 Intel 顯示卡,但不適用於 NVIDIA 顯示卡)。使用選項“-avdec”強制軟體 h264 視訊解碼:這應該可以阻止 autovideosink 選擇 vaapisink 視訊接收器。或者,找出是否安裝了 gstreamer1.0-vaapi 插件,如果安裝了,請將其解除安裝。 (如果這不能解決問題,您可以重新安裝。)
有一些關於硬體加速英特爾高清顯示卡的其他 GStreamer 問題的報告。一位用戶(在 Debian 上)透過「sudo apt install intel-media-va-driver-non-free」解決了這個問題。這是第 8 代(或更高版本)“*-lake”Intel 晶片的驅動程序,似乎與 VAAPI 加速圖形相關。
如果您確實有 Intel HD 顯示卡,並且已安裝 vaapi 插件,但-vs vaapisink
不起作用,請檢查 vaapi 是否在 GStreamer 安裝中「列入黑名單」:執行gst-inspect-1.0 vaapi
,如果報告0 features
,您需要在執行uxplay之前export GST_VAAPI_ALL_DRIVERS=1
,或在預設環境中設定此值。
您可以嘗試使用“ -as
”或“ -vs
”選項來選擇 GStreamer 音訊接收器或視訊接收器,而不是讓 GStreamer 為您選擇一個來修復音訊或視訊問題。 (請參閱上文啟動和執行 UxPlay 中的
或
選項。)
在 Linux 上透過「-vs glimagesink」建立的「OpenGL 渲染器」視窗有時在按一下其「關閉」按鈕時無法正確關閉。 (這是 GStreamer 問題)。您可能需要使用 Ctrl-C 終止 uxplay 以關閉「殭屍」OpenGl 視窗。如果客戶端發送“停止鏡像”訊號時出現類似問題,請嘗試不關閉選項“-nc”,以使視訊視窗保持開啟。
rm -rf ~/.cache/gstreamer-1.0/*
清除使用者的 GStreamer 快取可能可以解決 gst-inspect-1.0 未顯示您認為已安裝的插件的問題。下次啟動 GStreamer 時將重新產生快取。這是因快取損壞而產生的令人費解的問題的解決方案,應該首先嘗試。如果 UxPlay 無法啟動,並顯示未找到所需 GStreamer 外掛程式(例如「libav」)的訊息,請先使用 GStreamer 工具 gst-inspect-1.0 檢查 GStreamer 所知道的可用內容。 (您可能需要安裝一些額外的 GStreamer「工具」套件才能取得 gst-inspect-1.0)。例如,對於 libav 問題,請使用「 gst-inspect-1.0 libav
」進行檢查。如果它未顯示為可供 GStreamer 使用,但您的軟體包管理器顯示已安裝相關軟體包(正如一位用戶所發現的那樣),請嘗試完全刪除並重新安裝該軟體包。該用戶發現,針對不斷重複出現的「未找到所需的 gstreamer 插件『libav』」訊息的解決方案是清除用戶的 gstreamer 快取。
如果它無法啟動並出現類似「 no element "avdec_aac"
」的錯誤,這是因為即使安裝了 gstreamer-libav。它不完整,因為缺少一些插件功能:「 gst-inspect-1.0 | grep avdec_aac
」將顯示 avdec_aac 是否可用。與其他 GStreamer 插件不同,libav 插件是提供 avdec_* 的 FFmpeg 編解碼器的前端。
由於某些插件使用的編解碼器的專利問題,某些發行版(RedHat、SUSE 等)提供不完整版本的 FFmpeg。在這些情況下,會有一些「額外的套件」提供程序,例如RPM fusion (RedHat)、packman (SUSE),您可以在其中獲得完整的套件(您的發行版通常會提供這方面的說明,Mageia將它們放在可選的“受污染”存儲庫中) 。所需的套件可能是“ffmpeg*”或“libav*”套件:GStreamer libav 插件包本身不包含任何編解碼器,它只是為GStreamer 提供了一種使用必須單獨安裝的ffmpeg/libav 編解碼器庫的方法。出於類似的原因,發行版可能會提供不完整的 GStreamer 套件「plugins-bad」。 Fedora 上的使用者認為他們是從 rpmfusion 安裝的,但係統沒有遵守: “Adding --allowerasing to the dnf command fix it after a restart” 。
從 UxPlay-1.65.3 版本開始,如果缺少 avdec_aac,UxPlay 將繼續運行,但在鏡像模式下沒有音訊。
若要對 GStreamer 進行故障排除,請執行「export GST_DEBUG=2」以在將執行 uxplay 的終端機中設定 GStreamer 偵錯等級環境變量,以便您看到警告和錯誤訊息;請參閱 GStreamer 偵錯工具,以了解如何查看 GStreamer 內部發生的更多情況。執行“gst-inspect-1.0”以查看系統上安裝了哪些 GStreamer 插件。
可能需要安裝(或重新安裝)一些用於特殊插件的額外GStreamer 軟體包:一位使用Wayland 顯示系統作為X11 替代方案的用戶報告說,在重新安裝Lubuntu 18.4 後,UxPlay 將無法工作,直到安裝了gstreamer1 .0-x,大概是為了Wayland 的 X11 相容模式)。不同的發行版可能會以不同的方式將 GStreamer 1.x 分解為套件;建置說明中上面列出的套件應引入其他所需的 GStreamer 套件作為依賴項,但不會安裝所有可能的插件。
GStreamer 視訊管道(顯示在uxplay -d
的初始輸出中)具有預設形式
appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! autovideosink name=video_sink sync=false
管道是完全可配置的:如果有需要,可以分別使用 uxplay 選項-vp
、 -vd
、 -vc
和-vs
替換預設元素“h264parse”、“decodebin”、“videoconvert”和“autovideosink”修改它(條目可以用引號“...”給出以包含選項)。
如果來自客戶端的 TCP 視訊串流停止到達伺服器,可能會發生這種情況,這可能是由於網路問題(UDP 音訊串流可能會繼續到達)。以 3 秒的間隔,UxPlay 透過向客戶端發送 NTP 時間訊號請求來檢查用戶端是否仍處於連線狀態。如果在 0.3 秒時間視窗內未收到用戶端的回复,則會註冊「ntp 逾時」。如果連續發生一定次數(目前為 5 次)的 ntp 逾時,UxPlay 會假定客戶端已“死亡”,並重置連接,使其可用於連接到新客戶端,或重新連接到前一個客戶端。有時,連接可能會在達到超時限制之前恢復,如果預設限制不適合您的網絡,可以使用選項“-reset n ”進行修改,其中n是所需的超時限制值( n = 0意思是“沒有限制”)。如果連線在 ntp 逾時後開始恢復,則逾時前損壞的視訊資料包可能會觸發「連線由對等方重設」錯誤,這也會導致 UxPlay 重設連線。
協定故障可能會觸發無休止的錯誤訊息流,並且意味著未從客戶端發送的資料中正確提取音訊解密金鑰(也用於視訊解密)。
在發現可以透過停用「支援傳統配對」(位元 27)來避免客戶端-伺服器「配對」步驟(導致連線設定更快,沒有 5 秒延遲)後,該協定在 UxPlay-1.65 中進行了修改在UxPlay在DNS-SD 服務發現上宣傳的「功能」代碼中。大多數客戶端在配對時不會嘗試設定“共享金鑰”,AppleTV 使用該金鑰同時處理多個客戶端(UxPlay 一次僅支援一個客戶端)。此變更現已充分測試,但如果它導致任何協定失敗,UxPlay 可以透過取消註解 lib/dnssdint.h 中先前的「FEATURES_1」設定(並註解新設定)來恢復到先前的行為,然後重建UxPlay 。 (當使用 UxPlay 1.67 中引入的“-pin”選項運行 UxPlay 來啟動新的 Apple 風格的一次性“pin”身份驗證時,“配對”將重新啟用。)
iOS 9.3 或更高版本的用戶端不應發生協定故障。但是,如果用戶端使用與基於 Windows 的 AirPlay 用戶端模擬器AirMyPC所使用的相同舊版協議,則可以透過UxPlay/lib/global.h
中的OLD_PROTOCOL_CLIENT_USER_AGENT_LIST
設定將協議切換到舊版本。 UxPlay 在連線時會回報用戶端的「用戶代理」字串。如果其他一些客戶端也無法解密所有音頻和視頻,請嘗試添加其“User Agent”字串來代替 global.h 中“AirMyPC/2.0;xxx”條目中的“xxx”並重建 uxplay。
請注意,對於 DNS-SD 服務發現,Uxplay 聲明自己是 AppleTV3,2(32 位元裝置),來源版本為 220.68;這也可以在 global.h 中更改。如果 UxPlay 將自己聲明為來源版本 380.20.1 的 AppleTV6,2(AppleTV 4K 第一代,2017 年推出,運行 tvOS 12.2.1),那麼 UxPlay 也可以工作,因此 UxPlay 聲稱的版本似乎並不重要。
1.70 2024-10-04 增加對 4K (h265) 影片(解析度 3840 x 2160)的支援。修復了客戶端睡眠然後喚醒時 GStreamer >= 1.24 的問題。
1.69 2024-08-09 預期未來 HLS 視訊支援的內部改進(例如,在 -nohold 選項中、識別由 autovideosink 選擇的 GStreamer videosink、查找 X11 顯示)。新的 -nofreeze 選項可在重置網路連線時不保留凍結的影片。修復了 GStreamer-1.24.x 更改。
1.68 2023-12-31 用於從伺服器 MAC 位址(現在可以使用 -m 選項設定)產生持久公鑰的新的更簡單(預設)方法。 (以前的方法仍然可以使用 -key 選項)。新選項 -reg 用於維護經過 PIN 驗證的用戶端的註冊。修正的音量控制:現在將 AirPlay 音量範圍 -30dB:0dB 解釋為分貝增益衰減,並使用新選項 -db low[:high] 來「平整」重新調整 dB 範圍。為「錐形」AirPlay 音量控製設定檔新增 -taper 選項。
1.67 2023-11-30 使用選項「-pin」新增對 Apple 風格的一次性 PIN 驗證的用戶端支援:(使用 SRP6a 驗證協定和公鑰持久性)。透過有線乙太網路請求高解析度時,偵測(目前)不支援的 H265 影片的錯誤訊息。刪除了 rpi* 選項(對於新的 Raspberry Pi 型號 5 無效,可以用其他選項的組合替換)。在“-m”選項中新增了選用參數“mac”,以指定取代 MAC 位址/裝置 ID。將 llhttp 更新至 v. 9.1.3。新增 -dacp 選項用於匯出目前客戶端 DACP 資訊(用於遠端設備)。
1.66 2023-09-05 修復 IPV6 支援。新增選項以將用戶端限制為允許的 deviceID 清單中的用戶端,或封鎖來自封鎖的 deviceID 清單中的用戶端的連線。修復來自 @thicaxe 的 #207(客戶端從睡眠狀態喚醒後,垂直同步模式下的螢幕延遲)。
1.65.3 2023-07-23 新增 RPM 規格文件;如果缺少所需的gstreamer libav 功能“avdec_aac”,請添加警告:(這種情況發生在基於RPM 的發行版中,這些發行版由於專利或許可原因提供了不完整的FFmpeg,並且依賴用戶安裝外部提供的完整FFmpeg)。如果缺少 avdec_aac,鏡像模式播放現在將在沒有音訊的情況下運行。
1.65 2023-06-03 消除連接協定的pair_setup部分,以允許更快地與客戶端連接(感謝@shuax#176的發現);若要恢復,請取消註解 lib/dnssdint.h 中的一行。連接關閉時斷開與音訊設備的連接,以便在 uxplay 正在運行但未連接時阻止其他應用程式使用它。修正了 AirMyPC 用戶端(自 1.60 起損壞),因此其較舊的非 NTP 時間戳協定可與 -vsync 配合使用。更正了引號中的設定檔條目的解析。
1.64 2023-04-23 基於時間戳記的音訊和視訊同步現在是鏡像模式下的預設設定。 (使用“-vsync no”恢復先前的行為。)設定檔現在可用於啟動選項。還有一些內部清理和修復#192 的小錯誤修復。
1.63 2023-02-12 重新設計了音訊視訊同步,新增了新選項 -vsync(用於鏡像模式)和 -async(用於純音訊模式,與客戶端視訊同步)。選項 -vsync 使使用選項 -avdec 的串流視訊軟體 h264 解碼在某些最新的 Raspberry Pi 型號上可行。內部變化:所有時間現在都以奈秒為單位處理。刪除了 1.62 中引入的 -ao 選項。
1.62 2023-01-18 新增了純音訊模式時間偏移 -ao x,以允許用戶同步伺服器上播放的 ALAC 音訊與用戶端上播放的視訊、歌詞等。在許多情況下 x = 5.0 似乎是最佳的。品質修復:清理卷更改、時間戳記、一些錯誤修復。
1.61 2022-12-30 刪除了 -t 選項(Avahi 問題的解決方法,透過在防火牆中開啟網路連接埠 UDP 5353 正確解決)。從 CMAKE_CFLAGS 中刪除 -g 調試標誌。將建構環境 CFLAGS 後置(而不是前置)到 CMAKE_CFLAGS。重構 uxplay.cpp 部分
1.60 2022-12-15 如果 DNSServiceRegister 失敗(而不是僅僅停止),則新增了錯誤訊息的退出。測試用戶端是否嘗試使用不支援的 AirPlay 2「遠端控制」協定(無定時通道),如果發生這種情況則退出。重新設計元資料處理以正確解析 DMAP 標頭(先前的版本適用於目前收到的 DMAP 訊息,但不正確)。
1.59 2022-12-12 刪除「ZOOMFIX」編譯選項,如果偵測到 X11 開發庫,則預設使用 X11 依賴項進行編譯(現在也提供使用 F11 或 Alt+Enter 鍵切換的全螢幕模式); ZOOMFIX 現在自動應用於 GStreamer < 1.20。新的 cmake 選項 -DNO_X11_DEPS 編譯 uxplay 時無需依賴 X11。重新設計了內部元資料處理。使用“-vs 0”修復段錯誤。
1.58 2022-10-29 新增選項“-nohold”,當新客戶端連線時,該選項將刪除現有連線。將 llhttp 更新至 v8.1.0。
1.57 2022-10-09 小修復:(在使用 AUR CFLAGS -DFORTIFY_SOURCE 編譯時修復 AUR 上「停止鏡像」時的 coredump);當缺少所需插件時優雅退出;改進了對 Windows 上建置的支援。在 GStreamer 音訊管道中包含 audioresample。
1.56 2022-09-01 新增了在 Windows 上建置和執行 UxPlay-1.56 的支援(對 Unix(Linux、*BSD、macOS)程式碼庫沒有變更。)
1.56 2022-07-30 從 -rpi、-rpiwl、-rpifb 中刪除 -bt709,因為 GStreamer 現已修復。
1.55 2022-07-04 從 -v4l2 中刪除 bt709 修復並建立新的 -bt709 選項(先前的“-v4l2”現在是“-v4l2 -bt709”)。這允許當前所需的 -bt709 選項在沒有 -v4l2 的 RPi 上單獨使用(有時這會產生更好的結果)。
1.54 2022-06-25 增加對純音訊 (ALAC) 模式下「封面藝術」顯示的支援。恢復了導致 VAAPI 在 AMD POLARIS 顯示卡上崩潰的變更。對 plist 程式碼和 uxplay 選項解析進行了細微的內部變更。
1.53 2022-06-13 音訊同步程式碼的內部變更、修訂文件、小錯誤修復(修復重新傳送音訊資料包為空時斷言會崩潰)。
1.52 2022-05-05 清理了初始音訊同步程式碼,並重新格式化了串流偵錯輸出(以秒為單位的帶小數點的可讀對齊時間戳)。消除記憶體洩漏(由 valgrind 發現)。支援在 uxplay 終端機中顯示 ALAC(純音訊)元資料(原聲帶藝人姓名、標題等)。
1.51 2022-04-24 重新設計了 Video4Linux2 支援選項(新選項 -v4l2)和短選項 -rpi、-rpifb、-rpiwl 作為 -v4l2、-v4l2 -vs kmssink 和 -v4l2 -vs waylandsink 的同義詞。恢復了 1.48 中的一項更改,該更改在客戶端發送「停止鏡像」後中斷了重新連線。
1.50 2022-04-22 新增了-fs 全螢幕選項(僅適用於Wayland 或VAAPI 插件),將-rpi 更改為適用於幀緩衝(“lite”)RPi 系統,並為RPi 添加了-rpigl (OpenGL) 和-rpiwl (Wayland) 選項桌面系統。也修改了時間戳從“DTS”到“PTS”以改善延遲,以及內部清理。
1.49 2022-03-28 新增了用於將視訊和/或音訊轉儲到檔案、用於偵錯等的選項。修復了 M1 Mac 用戶端視訊無法正常運作的問題。
1.48 2022-03-11 使 GStreamer 視訊管道完全可配置,以便與硬體 h264 解碼一起使用。支持樹莓派。
1.47 2022-02-05 新增了 -FPSdata 選項以顯示(在終端機中)客戶端發送的有關視訊串流效能的定期報告。對從客戶端接收的視訊資料包進行內部清理處理。新增了 -reset n 選項,用於在 n ntp 逾時後重置連接(也在視訊串流中的「連接由對等方重置」錯誤後重置)。
1.46 2022-01-20 恢復 1.44 之前的行為(1.44 可能已損壞硬體加速):再次在視訊管道中使用decodebin;如果需要,請引入新選項「-avdec」以強制 libav h264 進行軟體 h264 解碼(以防止 autovideosink 選擇 vaapisink)。將 llhttp 更新至 v6.0.6。 UxPlay 現在將自己報告為 AppleTV3,2。一次限制與一個客戶端的連線(第二個客戶端現在必須等待第一個客戶端斷開連線)。
1.45 2022-01-10 新行為:當客戶端要求「停止鏡像」時關閉視訊視窗。 (為希望保留先前不關閉視訊視窗行為的用戶新增了新的「不關閉」選項「-nc」)。
1.44 2021-12-13 對於 AirMyPC 用戶端,省略帶有 ecdh_secret 的 aeskey 雜湊;對完成此哈希的位置進行內部重新排列。在 -d 調試模式下完整報告客戶端和伺服器之間的所有初始通訊。以特定於 h264 的元素取代 GStreamer 視訊管道中的decodebin。
1.43 2021-12-07 各種內部更改,例如成功解密的測試、資訊/偵錯訊息的統一處理等,更新了 README。
1.42 2021-11-20 修復 MAC 偵測以與現代 Linux 介面命名實務、MacOS 和 *BSD 搭配使用。
1.41 2021-11-11 進一步清理多種音訊格式支援(內部變更、分離 RAOP 和 GStreamer 音訊/視訊啟動)
1.40 2021-11-09 清理 ALAC 支援中的段錯誤、修正線上說明頁位置、在偵錯模式下顯示請求 Plist。
1.39 2021-11-06 增加了對 Apple Lossless (ALAC) 音訊串流的支援。
1.38 2021-10-8 新增 -as audiosink選項以允許使用者選擇 GStreamer audiosink。
1.37 2021-09-29 將「@hostname」附加到 AirPlay 伺服器名稱,其中「hostname」是執行 uxplay 的伺服器的名稱(1.36 中重新設計的變更)。
1.36 2021-09-29 實作建議(由 @mrbesen 和 @PetrusZ)使用執行 uxplay 的電腦的主機名稱作為預設伺服器名稱
1.35.1 2021-09-28 新增了 -vs 0 選項用於串流音頻,但不顯示視訊。
1.35 2021-09-10 現在使用 GLib MainLoop,並在 macOS 上建置(在 Intel Mac 10.15 上測試)。新選項 -t timeout用於在先前的超時秒數內沒有活動連線的情況下重新啟動伺服器(以更新 Bonjour 註冊)。
1.341 2021-09-04 已修正:渲染記錄器沒有被 stop_server() 銷毀
1.34 2021-08-27 修正了「ZOOMFIX」:X11 視窗名稱修復僅在 uxplay 第一次建立 GStreamer 視窗時進行,如果在 GStreamer 視窗關閉後重新啟動伺服器且 uxplay 仍在運行,則不會進行修復。在第 1.34 節中更正
如果您需要執行此操作,請注意您也許可以使用較新的版本(已知 OpenSSL-3.0.1 可以工作)。您將需要標準開發工具集(autoconf、automake、libtool)。從 https://www.openssl.org/source/ 下載原始碼。透過在下載目錄中開啟終端機並解壓縮來源發行版來安裝下載的 openssl:(「tar -xvzf openssl-3.0.1.tar.gz ; cd openssl-3.0.1」)。然後使用“./config ; make ; sudo make install_dev”建置/安裝。這通常會在 /usr/local/lib 或 /usr/local/lib64 中安裝所需的函式庫libcrypto.*
。
(在 MacOS 上建置時請忽略以下內容:)在 Debian 或 Ubuntu 等某些系統上,您可能還需要在 /etc/ld.so.conf 中新增缺少的條目/usr/local/lib64
(或放置一個包含“/ usr/local/lib64/libcrypto.so”(位於 /etc/ld.so.conf.d),然後執行“sudo ldconfig”。
(注意:在 Debian 9「Stretch」或 Ubuntu 16.04 LTS 版本上,您可以透過從 Debian 10 或 Ubuntu 18.04 安裝 libplist-dev 和 libplist3 來避免此步驟。)以及常用的建置工具(autoconf、automake、libtool),您可能還需要安裝一些libpython*-dev 軟體包。使用 git 從 https://github.com/libimobiledevice/libplist 下載最新原始程式碼,或從版本部分取得原始程式碼(使用 *.tar.bz2 版本,而不是*.zip 或 *.tar.gz 版本) :下載libplist-2.3.0,然後解壓縮它(“tar -xvjf libplist-2.3.0.tar.bz2 ; cd libplist-2.3.0”),然後建置/安裝它:(“./configure ; make ; sudo進行安裝”)。這可能會在 /usr/local/lib 中安裝 libplist-2.0.*。新的 libplist-2.3.0 版本應該與 UxPlay 相容;如果有任何問題,libplist-2.2.0 也可用。
(在 MacOS 上建置時請忽略以下內容:)在 Debian 或 Ubuntu 等某些系統上,您可能還需要在 /etc/ld.so.conf 中新增缺少的條目/usr/local/lib
(或放置一個包含“/ /etc/ld.so.conf.d 中的 usr/local/lib/libplist-2.0.so”),然後執行“sudo ldconfig”。
此儲存庫中的所有資源均僅使用網路上免費提供的資訊編寫。該代碼和相關資源僅用於教育目的。使用者有責任確保遵守所有當地法律。
該專案使用第三方 GPL 庫來處理 FairPlay。該圖書館的法律地位尚不清楚。如果您是 Apple 的代表,並對庫的合法性及其在本項目中的使用有任何異議,請聯絡開發人員,我們將採取適當的措施。
鑑於有大量第三方 AirPlay 接收器(大部分是閉源)可供購買,我們認為相同功能的開源實作也不會侵犯 Apple 的任何權利。
[改編自 fdraschbacher 關於 RPiPlay 前身的筆記]
此儲存庫中的程式碼隨著時間的推移從各種來源累積。以下是列出各個作者和他們創建的組件的嘗試:
UxPlay 最初是由 RPiPlay 的antimof創建的,透過將其適用於 Raspberry-Pi 的 OpenMAX 視訊和音訊渲染系統替換為適用於桌面 Linux 系統的 GStreamer 渲染系統; antimof 在renderers/
中的程式碼工作後來被向後移植到 RPiPlay,並且 antimof 專案陷入休眠狀態,但後來在當前的 GitHub 網站上恢復以服務更廣泛的用戶社群。
透過繼承 RPiPlay 包含在 UxPlay 中的程式碼的先前作者包括:
lib/playfair
資料夾中。授權: GNU GPLlib/
中的大部分程式碼最初源自於該專案。授權:GNU LGPLv2.1+lib/
中有關鏡像的所有程式碼都是 dsafa22 的工作。授權:GNU LGPLv2.1+獨立於 UxPlay,但被它使用並與其捆綁在一起:
lib/llhttp/
。許可證:麻省理工學院