Observação: o streaming de áudio em várias salas AirPlay2 não é compatível: use shairport-sync para isso.
.
Instale o uxplay em sistemas Linux baseados em Debian com " sudo apt install uxplay "; no FreeBSD com " sudo pkg install uxplay ". Também disponível em sistemas baseados em Arch através do AUR. Desde a versão 1.66, o uxplay agora também é empacotado no formato RPM pelo Fedora 38 (" sudo dnf install uxplay ").
Para outras distribuições baseadas em RPM que ainda não empacotaram o UxPlay, um "specfile" uxplay.spec do RPM agora é fornecido com lançamentos recentes (veja seus "Ativos") e também pode ser encontrado no diretório superior de origem do UxPlay. Consulte a seção sobre como usar este arquivo específico para construir um pacote RPM instalável.
Após a instalação:
(No Linux e *BSD): se um firewall estiver ativo no servidor que hospeda o UxPlay, certifique-se de que a porta de rede padrão (UDP 5353) para consultas mDNS/DNS-SD esteja aberta (veja Solução de problemas abaixo para mais detalhes); abra também três portas UDP e três TCP para Uxplay e use a opção "uxplay -p" (veja " man uxplay " ou " uxplay -h ").
Mesmo se você instalar o pacote binário uxplay pré-compilado da sua distribuição, pode ser necessário ler as instruções abaixo para executar o UxPlay para ver quais pacotes de plug-ins GStreamer da sua distribuição você também deve instalar.
Para o modo somente áudio (Apple Music, etc.) a melhor qualidade é obtida com a opção "uxplay -async", mas há uma latência de 2 segundos imposta pelo iOS.
Adicione quaisquer opções de UxPlay que você deseja usar como padrão a um arquivo de inicialização ~/.uxplayrc (veja " man uxplay " ou " uxplay -h " para formato e outros locais possíveis). Em particular, se o seu sistema usa sistemas de áudio PipeWire ou vídeo Wayland, você pode adicionar "as pipewiresink" ou "vs waylandsink" como padrão ao arquivo. (A saída dos comandos do terminal "ps waux | grep pulse" ou "pactl info" conterá "pipewire" se o seu sistema Linux/BSD o utilizar).
No Raspberry Pi: Se você usa Ubuntu 22.10 ou anterior, o GStreamer deve ser corrigido para usar a decodificação de vídeo de hardware pela GPU Broadcom (também recomendado, mas opcional para Raspberry Pi OS (Bullseye): use a opção " uxplay -bt709 " se você não usar o patch).
Para (facilmente) compilar o UxPlay mais recente a partir do código-fonte, consulte a seção Obtendo o UxPlay.
Este projeto é um servidor Unix AirPlay2 Mirror de código aberto GPLv3 para Linux, macOS e *BSD. Foi inicialmente desenvolvido pela antimof usando código do RPiPlay baseado em OpenMAX, que por sua vez deriva de AirplayServer, shairplay e playfair. (O site antimof não está mais envolvido no desenvolvimento, mas publica periodicamente atualizações retiradas do novo site principal do UxPlay).
UxPlay é testado em vários sistemas, incluindo (entre outros) Debian (10 "Buster", 11 "Bullseye", 12 "Bookworm"), Ubuntu (20.04 LTS, 22.04 LTS, 23.04 (também derivados do Ubuntu Linux Mint, Pop! _OS), Red Hat e clones (Fedora 38, Rocky Linux 9.2), openSUSE Leap 15.5, Mageia 9, OpenMandriva "ROME", PCLinuxOS, Arch Linux, Manjaro, e deve rodar em qualquer sistema Linux. Também testado em macOS Catalina e Ventura (Intel) e Sonoma (M2), FreeBSD 14.0, Windows 10 e 11 (64 bits).
No Raspberry Pi 4 modelo B, ele é testado no Raspberry Pi OS (Bullseye e Bookworm) (32 e 64 bits), Ubuntu 22.04 LTS e 23.04, Manjaro RPi4 23.02 e (sem decodificação de vídeo de hardware) no openSUSE 15.5. Também testado em Raspberry Pi Zero 2 W, 3 modelo B+ e agora 5.
Seu principal uso é atuar como um AppleTV para espelhamento de tela (com áudio) de clientes iOS/iPadOS/macOS (iPhone, iPod Touch, iPad, computadores Mac) na exibição do servidor de um host executando Linux, macOS ou outro unix. (e agora também Microsoft Windows). UxPlay suporta o protocolo AirPlay2 da Apple usando "Protocolo Legado", mas alguns recursos estão faltando. (Detalhes do que é publicamente conhecido sobre o protocolo AirPlay 2 da Apple podem ser encontrados aqui, aqui e aqui; veja também pyatv, que pode ser um recurso para adicionar protocolos modernos.) Embora não haja garantia de que futuras versões do iOS continuarão a oferecer suporte ao "Protocolo Legado ", iOS 17 continua com suporte.
O servidor UxPlay e seu cliente devem estar na mesma rede local, na qual também esteja rodando um servidor Bonjour/Zeroconf mDNS/DNS-SD (apenas o serviço DNS-SD "Service Discovery" é estritamente necessário, não é necessário que o rede local também seja do tipo ".local" baseado em mDNS). Em servidores Linux e BSD Unix, isso geralmente é fornecido pelo Avahi, através do serviço avahi-daemon, e está incluído na maioria das distribuições Linux (este serviço também pode ser fornecido por servidores macOS, iOS ou Windows).
As conexões com o servidor UxPlay por clientes iOS/MacOS podem ser iniciadas no modo AirPlay Mirror (que transmite áudio AAC compactado com perdas enquanto espelha a tela do cliente ou no modo AirPlay Audio alternativo que transmite áudio Apple Lossless (ALAC) sem espelhamento de tela . No modo Áudio , os metadados são exibidos no terminal uxplay; se a opção UxPlay -ca <name> for usada, a arte da capa que acompanha também será enviada para um arquivo <name> atualizado periodicamente. ser visualizado com um visualizador gráfico (recarregando) de sua escolha É possível alternar entre os modos Espelho e Áudio durante uma conexão ativa: no modo Espelho , pare o espelhamento (ou feche a janela de espelho) e inicie uma conexão no modo Áudio , alterne novamente iniciando. uma conexão no modo Espelho ; a exibição da arte da capa para/reinicia quando você sai/entra no modo Áudio .
Observe que o vídeo DRM da Apple (conforme encontrado no conteúdo do "aplicativo Apple TV" no cliente) não pode ser descriptografado pelo UxPlay, e o aplicativo Apple TV não pode ser assistido usando o modo AirPlay Mirror do UxPlay (apenas o áudio desprotegido será transmitido, em AAC formato), mas o conteúdo de vídeo e áudio de aplicativos sem DRM, como "aplicativo YouTube", será transmitido pelo UxPlay no modo Mirror.
Como o UxPlay atualmente não suporta streaming de vídeo AirPlay não-Mirror (onde o cliente controla um servidor web no servidor AirPlay que recebe diretamente o conteúdo HLS para evitar que ele seja decodificado e recodificado pelo cliente), usando o ícone para vídeo AirPlay em aplicativos como o aplicativo do YouTube enviarão apenas áudio (no formato ALAC sem perdas) sem o vídeo que o acompanha (há planos para oferecer suporte a vídeo HLS em versões futuras do UxPlay)
UxPlay usa "plugins" GStreamer para renderizar áudio e vídeo. Isso significa que vídeo e áudio são suportados "prontos para uso", usando uma variedade de plug-ins. AirPlay transmite vídeo no formato h264: a decodificação gstreamer é independente de plug-in e usa decodificadores h264 de hardware de GPU acelerados, se disponíveis; caso contrário, a decodificação de software é usada.
VAAPI para gráficos integrados Intel e AMD, NVIDIA com driver de código aberto "Nouveau"
Com uma GPU Intel ou AMD, é preferível a decodificação de hardware com o plug-in VAAPI gstreamer de código aberto. Os drivers "Nouveau" de código aberto para gráficos NVIDIA também são, em princípio, suportados: veja aqui, mas isso requer que o VAAPI seja complementado com firmware extraído dos drivers proprietários da NVIDIA.
NVIDIA com drivers proprietários
O plugin nvh264dec (incluído em gstreamer1.0-plugins-bad desde GStreamer-1.18.0) pode ser usado para decodificação acelerada de vídeo na GPU NVIDIA após a instalação do driver CUDA da NVIDIA libcuda.so . Para GStreamer-1.16.3 ou anterior, o plugin é chamado nvdec e deve ser construído pelo usuário.
Suporte Video4Linux2 para decodificação de hardware h264 no Raspberry Pi (Pi 4B e mais antigo)
Os computadores Raspberry Pi (RPi) (testados no Pi 4 Modelo B) agora podem executar o UxPlay usando decodificação de vídeo por software, mas a decodificação h264/h265 acelerada por hardware por firmware na GPU Broadcom 2835 do Pi é preferida. UxPlay acessa isso usando o plugin GStreamer-1.22 Video4Linux2 (v4l2); Usa o módulo de kernel Linux fora da linha principal bcm2835-codec mantido pelo Raspberry Pi, até agora incluído apenas no Raspberry Pi OS, e duas outras distribuições (Ubuntu, Manjaro) disponíveis com Raspberry Pi Imager. (Para GStreamer <1.22, consulte o UxPlay Wiki) .
(Novo): Suporte para decodificação de hardware h265 (HEVC) no Raspberry Pi (Pi 4 modelo B e Pi 5)
O apoio está presente, mas até agora não foram obtidos resultados satisfatórios. O Pi modelo 5 fornece apenas decodificação acelerada por hardware (GPU) para vídeo h265, mas não H264, pois sua CPU é poderosa o suficiente para decodificação de software H264 satisfatória
A licença GPLv3 do UxPlay não tem uma "exceção GPL" adicionada, permitindo explicitamente que seja distribuída em formato compilado quando vinculada a versões OpenSSL anteriores à v. 3.0.0 (versões mais antigas do OpenSSL têm uma cláusula de licença incompatível com a GPL, a menos que o OpenSSL possa ser considerada como uma "Biblioteca do Sistema", que está no *BSD). Muitas distribuições Linux tratam o OpenSSL como uma "Biblioteca do Sistema", mas algumas (por exemplo, Debian) não o fazem: neste caso, o problema é resolvido vinculando-se ao OpenSSL-3.0.0 ou posterior.
Baixe e descompacte UxPlay-master.zip ou (se o git estiver instalado): "git clone https://github.com/FDH2/UxPlay". Você também pode baixar uma versão recente ou anterior listada em Versões.
(Adapte estas instruções para Linux não baseados em Debian ou *BSD; para macOS, veja as instruções específicas abaixo). Consulte Solução de problemas abaixo para obter ajuda com quaisquer dificuldades.
Você precisa de um compilador C/C++ (por exemplo, g++) com as bibliotecas de desenvolvimento padrão instaladas. Os sistemas baseados em Debian fornecem um pacote "essencial para construção" para uso na compilação de software. Você também precisa do pkg-config: se ele não for encontrado por " which pkg-config ", instale o pkg-config ou seu substituto semelhante, o pkgconf. Certifique-se também de que cmake>=3.5 esteja instalado: " sudo apt install cmake " (adicione build-essential e pkg-config (ou pkgconf ) a isso, se necessário).
Certifique-se de que sua distribuição forneça OpenSSL 1.1.1 ou posterior e libplist 2.0 ou posterior. (Isso significa sistemas baseados em Debian 10 "Buster" (por exemplo, Ubuntu 18.04) ou mais recentes; em sistemas Debian 10 "libplist" é uma versão mais antiga, você precisa de "libplist3".) Caso contrário, pode ser necessário compilar e instalar estes da fonte (veja as instruções no final deste README).
Se você tiver uma instalação OpenSSL não padrão, pode ser necessário definir a variável de ambiente OPENSSL_ROOT_DIR ( por exemplo , " export OPENSSL_ROOT_DIR=/usr/local/lib64 " se for onde está instalado). Da mesma forma, para instalações não padrão (ou múltiplas) do GStreamer, defina a variável de ambiente GSTREAMER_ROOT_DIR para o diretório que contém o diretório ".../gstreamer-1.0/" da instalação do gstreamer que o UxPlay deve usar (se for, por exemplo, "~ /my_gstreamer/lib/gstreamer-1.0/", defina este local com " export GSTREAMER_ROOT_DIR=$HOME/my_gstreamer/lib ").
Em uma janela de terminal, altere os diretórios para o diretório fonte do código-fonte baixado ("UxPlay-*", "*" = "master" ou a tag de lançamento para downloads de arquivo zip, "UxPlay" para downloads de "git clone") e, em seguida, siga as instruções abaixo:
Nota: Por padrão, o UxPlay será construído com otimização para o computador em que foi construído; quando este não for o caso, como quando você está empacotando para uma distribuição, use a opção cmake -DNO_MARCH_NATIVE=ON .
Se você usa o X11 Windows no Linux ou *BSD e deseja ativar/desativar o modo de tela cheia pressionando uma tecla (F11 ou Alt_L+Enter), o UxPlay precisa ser construído com dependência do X11. A partir do UxPlay-1.59, isso será feito por padrão SE as bibliotecas de desenvolvimento do X11 estiverem instaladas e detectadas. Instale-os com " sudo apt install libx11-dev ". Se o GStreamer < 1.20 for detectado, uma correção necessária para aplicativos de compartilhamento de tela ( por exemplo , Zoom) também será feita.
-DNO_X11_DEPS=ON .sudo apt install libssl-dev libplist-dev ". ( a menos que você precise construir OpenSSL e libplist a partir do código-fonte ).sudo apt install libavahi-compat-libdnssd-devsudo apt install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev . (* Pule se você construiu o Gstreamer a partir do código-fonte )cmake . ( Para uma compilação mais limpa, que é útil se você modificar a fonte, substitua por " mkdir build; cd build; cmake .. ": você pode então excluir o conteúdo do diretório build se necessário, sem afetar a fonte. ) Além disso adicione quaisquer opções cmake " -D " aqui conforme necessário (por exemplo, -DNO_X11_DEPS=ON ou -DNO_MARCH_NATIVE=ON ).makesudo make install (você pode desinstalar posteriormente com sudo make uninstall no mesmo diretório em que foi executado). Isso instala o arquivo executável " uxplay " em /usr/local/bin , (e instala uma página de manual em algum lugar padrão como /usr/local/share/man/man1 e arquivos README em algum lugar como /usr/local/share/doc/uxplay ). (Se "man uxplay" falhar, verifique se $MANPATH está definido: se estiver, o caminho para a página de manual (geralmente /usr/local/share/man/) precisa ser adicionado a $MANPATH .) O executável uxplay também pode ser encontrado no diretório de construção após o processo de construção, se você deseja testar antes de instalar (nesse caso, os plugins do GStreamer devem ser instalados primeiro).
**Para aqueles com distribuições baseadas em RPM, um arquivo de especificação RPM uxplay.spec também está disponível: consulte Construindo um pacote rpm instalável.
Red Hat ou clones como CentOS (agora continuado como Rocky Linux ou Alma Linux): (sudo dnf install ou sudo yum install) openssl-devel libplist-devel avahi-compat-libdns_sd-devel gstreamer1-devel gstreamer1-plugins-base- devel (+libX11-devel para X11 em tela cheia) (alguns deles podem estar no complemento "CodeReady" repositório, chamado "PowerTools" pelos clones)
Mageia, PCLinuxOS, OpenMandriva: Igual ao Red Hat, exceto pelas mudanças de nome: (Mageia) "gstreamer1.0-devel", "gstreamer-plugins-base1.0-devel"; (OpenMandriva) "libopenssl-devel", "gstreamer-devel", "libgst-plugins-base1.0-devel". PCLinuxOS: igual ao Mageia, mas usa synaptic (ou apt) como gerenciador de pacotes.
openSUSE: (sudo zypper install) libopenssl-3-devel (anteriormente libopenssl-devel) libplist-2_0-devel (anteriormente libplist-devel) avahi-compat-mDNSResponder-devel gstreamer-devel gstreamer-plugins-base-devel (+ libX11- desenvolvimento para tela cheia X11).
Arch Linux ( também disponível como um pacote no AUR ): (sudo pacman -Syu) openssl libplist avahi gst-plugins-base.
FreeBSD: (sudo pkg install) libplist gstreamer1. Avahi-libdns ou mDNSResponder também devem ser instalados para fornecer a biblioteca dns_sd. OpenSSL já está instalado como uma biblioteca do sistema.
Os construtores RPM iniciantes devem primeiro instalar os pacotes rpm-build e rpmdevtools e, em seguida, criar a árvore rpmbuild com " rpmdev-setuptree ". Em seguida, baixe e copie uxplay.spec para ~/rpmbuild/SPECS . Nesse diretório, execute " rpmdev-spectool -g -R uxplay.spec " para baixar o arquivo fonte correspondente uxplay-*.tar.gz em ~/rpmbuild/SOURCES ("rpmdev-spectool" também pode ser chamado apenas de "spectool" ); em seguida, execute " rpmbuild -ba uxplay.spec " (você precisará instalar todas as dependências necessárias relatadas). Isso deve criar o pacote RPM uxplay em um subdiretório de ~/rpmbuild/RPMS . ( uxplay.spec é testado no Fedora 38, Rocky Linux 9.2, openSUSE Leap 15.5, Mageia 9, OpenMandriva, PCLinuxOS; pode ser facilmente modificado para incluir listas de dependências para outras distribuições baseadas em RPM.)
Em seguida, instale os plug-ins GStreamer necessários com sudo apt install gstreamer1.0-<plugin> . Os valores de <plugin> necessários são:
As distribuições baseadas no Debian dividem alguns dos pacotes de plugins em pedaços menores: alguns que também podem ser necessários incluem " gl " para suporte OpenGL (isso fornece o videosink "-vs gliimagesink", que pode ser muito útil em muitos sistemas (incluindo Raspberry Pi ), e sempre deve ser usado ao usar a decodificação h264/h265 por uma GPU NVIDIA), " gtk3 " (que fornece o videosink "-vs gtksink") e " x " para suporte X11, embora estes podem já estar instalados; " vaapi " é necessário para decodificação de vídeo h264 acelerada por hardware por gráficos Intel ou AMD (mas não para uso com NVIDIA usando drivers proprietários). Se o som não estiver funcionando, os plug-ins " alsa ", " pulseaudio " ou " pipewire " podem precisar ser instalados, dependendo de como o áudio está configurado.
Em alguns casos, devido a questões de patente, o recurso do plugin libav avdec_aac necessário para decodificar áudio AAC no modo espelho não é fornecido na distribuição oficial: obtenha-o nos repositórios da comunidade para essas distribuições.
Red Hat ou clones como CentOS (agora continuado como Rocky Linux ou Alma Linux): Instale gstreamer1-libav gstreamer1-plugins-bad-free (+ gstreamer1-vaapi para gráficos Intel/AMD). No Fedora recente, gstreamer1-libav foi renomeado como gstreamer1-plugin-libav. Para obter avdec_aac, instale pacotes de rpmfusion.org : (obtenha ffmpeg-libs de rpmfusion; no RHEL ou clones, mas não no Fedora recente, obtenha também gstreamer1-libav de lá).
Mageia, PCLinuxOS, OpenMandriva: Instale gstreamer1.0-libav gstreamer1.0-plugins-bad (+ gstreamer1.0-vaapi para gráficos Intel/AMD). Na Mageia, para obter o avdec_aac, instale o ffmpeg do repositório "tainted" (que também fornece um gstreamer1.0-plugins-bad mais completo).
openSUSE: Instale gstreamer-plugins-libav gstreamer-plugins-bad (+ gstreamer-plugins-vaapi para gráficos Intel/AMD). Para obter o avdec_aac, instale os pacotes libav* para openSUSE do Packman "Essentials" ; recomendação: após adicionar o repositório Packman, use a opção no gerenciamento do software YaST para mudar todos os pacotes do sistema de multimídia para Packman).
Arch Linux Instale gst-plugins-good gst-plugins-bad gst-libav (+ gstreamer-vaapi para gráficos Intel/AMD).
FreeBSD: Instale gstreamer1-libav, gstreamer1-plugins, gstreamer1-plugins-* (* = core, good, bad, x, gtk, gl, vulkan, pulse, v4l2, ...), (+ gstreamer1-vaapi para Intel/ Gráficos AMD).
Desde o UxPlay-1.64, o UxPlay pode ser iniciado com opções lidas de um arquivo de configuração, que será o primeiro encontrado de (1) um arquivo com caminho dado pela variável de ambiente $UXPLAYRC , (2) ~/.uxplayrc na casa do usuário diretório ("~"), (3) ~/.config/uxplayrc . O formato é uma opção por linha, omitindo o "-" inicial da opção de linha de comando. As linhas no arquivo de configuração que começam com "#" são tratadas como comentários e ignoradas.
Execute o uxplay em uma janela de terminal . Em alguns sistemas, você pode especificar o modo de tela cheia com a opção -fs ou alternar para dentro e fora do modo de tela cheia com F11 ou (mantenha pressionada a tecla Alt esquerda) + Enter. Use Ctrl-C (ou feche a janela) para encerrá-lo quando terminar. Se o servidor UxPlay não for visto pelo painel suspenso "Screen Mirroring" do cliente iOS, verifique se o seu servidor DNS-SD (geralmente avahi-daemon) está em execução: faça isso em uma janela de terminal com systemctl status avahi-daemon . Se isso mostrar que o avahi-daemon não está em execução, controle-o com sudo systemctl [start,stop,enable,disable] avahi-daemon (em sistemas não-systemd, como *BSD, use sudo service avahi-daemon [status, start, stop, restart, ...] ). Se o UxPlay for visto, mas o cliente não conseguir se conectar quando for selecionado, pode haver um firewall no servidor que impede o UxPlay de receber solicitações de conexão do cliente, a menos que algumas portas de rede estejam abertas: se um firewall estiver ativo, abra também a porta UDP 5353 (para consultas mDNS) necessário para Avahi . Consulte Solução de problemas abaixo para obter ajuda com este ou outros problemas.
Ao contrário de um Apple TV, o servidor UxPlay, por padrão, não exige que os clientes inicialmente "emparelhem" com ele usando um código PIN exibido pelo servidor (após o qual o cliente "confia" no servidor e não precisa repetir isso). Desde a versão 1.67, o Uxplay oferece essa "autenticação de pin" como uma opção: consulte " -pin " e " -reg " em Uso para obter detalhes, se desejar usá-lo. Alguns clientes com MDM (Mobile Device Management, frequentemente presente em dispositivos de propriedade do empregador) são obrigados a usar autenticação de pin: o UxPlay fornecerá isso mesmo quando executado sem a opção de pin.
Por padrão, o UxPlay fica bloqueado para seu cliente atual até que esse cliente interrompa a conexão; desde UxPlay-1.58, a opção -nohold modifica esse comportamento para que quando um novo cliente solicitar uma conexão, ele remova o cliente atual e assuma o controle. UxPlay 1.66 introduz um mecanismo ( -restrict , -allow <id> , -block <id> ) para controlar quais clientes têm permissão para se conectar, usando seu "deviceID" (que em dispositivos Apple parece ser imutável).
No modo Mirror, o GStreamer pode escolher entre dois métodos para reproduzir vídeo com o áudio que o acompanha: antes do UxPlay-1.64, os fluxos de vídeo e áudio eram reproduzidos o mais rápido possível após chegarem (o método " sync=false " do GStreamer). , com um relógio interno do GStreamer usado para tentar mantê-los sincronizados. A partir do UxPlay-1.64, o outro método (modo " sync=true " do GStreamer), que usa carimbos de data e hora nos fluxos de áudio e vídeo enviados pelo cliente, é o novo padrão . Em hosts UxPlay de baixo poder de decodificação (como modelos Raspberry Pi Zero W ou 3 B+), isso eliminará quadros de vídeo que não podem ser decodificados a tempo de reproduzir o áudio, tornando o vídeo irregular, mas ainda sincronizado.
O método mais antigo, que não elimina quadros de vídeo atrasados, funcionou bem em sistemas mais poderosos e ainda está disponível com a opção UxPlay " -vsync no "; este método é adaptado para "transmissão ao vivo" e pode ser melhor ao usar o UxPlay como um segundo monitor para um computador Mac, por exemplo, enquanto o novo método padrão baseado em carimbo de data / hora é melhor para assistir a um vídeo, para manter movimentos labiais e vozes sincronizado. (Sem o uso de carimbos de data e hora, o vídeo acabará ficando atrás do áudio se não puder ser decodificado com rapidez suficiente: a decodificação de vídeo acelerada por hardware ajudou a evitar isso anteriormente, quando os carimbos de data e hora não estavam sendo usados.)
-async timestamp- opção baseada. (Um exemplo pode ser se você quiser seguir as letras do Apple Music no cliente enquanto ouve um som superior no servidor UxPlay). Isso atrasa o vídeo no cliente para corresponder ao áudio no servidor, resultando em um pequeno atraso antes que uma pausa ou alteração de faixa iniciada no cliente tenha efeito no áudio reproduzido pelo servidor. O controle de volume do AirPlay atenua o volume (ganho) em até -30dB: a faixa de decibéis -30:0 pode ser redimensionada de Low :0 ou Low : High , usando a opção -db ("-db Low " ou "-db Baixo : Alto "), Baixo deve ser negativo. O redimensionamento é linear em decibéis. Observe que o formato de áudio do GStreamer irá "cortar" qualquer ganho de áudio acima de +20db, então mantenha Alto abaixo desse nível. A opção -taper fornece um perfil de controle de volume AirPlay "cônico" que alguns usuários podem preferir.
As opções -vsync e -async também permitem um ajuste opcional de atraso de áudio positivo (ou negativo) em milissegundos para ajuste fino: -vsync 20.5 atrasa o áudio em relação ao vídeo em 0,0205 segundos; um valor negativo avança.)
você pode descobrir que o vídeo é melhorado pela configuração -fps 60, que permite que alguns vídeos sejam reproduzidos a 60 quadros por segundo. (Você pode ver qual taxa de quadros está realmente sendo transmitida usando -vs fpsdisplaysink e/ou -FPSdata.) Ao usar isso, você deve usar a opção de sincronização padrão baseada em carimbo de data/hora -vsync .
Desde o UxPlay-1.54, você pode exibir a "Arte da capa" de fontes como Apple Music no modo somente áudio (ALAC): execute " uxplay -ca <name> & " em segundo plano e, em seguida, execute um visualizador de imagens com um carregamento automático recurso: um exemplo é "feh": execute " feh -R 1 <name> " em primeiro plano; encerre feh e depois Uxplay com " ctrl-C fg ctrl-C ".
Por padrão, o GStreamer usa um algoritmo para procurar o melhor "videosink" (termo do GStreamer para um driver gráfico para exibir imagens) a ser usado. Você pode substituir isso com a opção uxplay -vs <videosink> . Quais videosinks estão disponíveis depende do seu sistema operacional e hardware gráfico: use " gst-inspect-1.0 | grep sink | grep -e video -e Video -e image " para ver o que está disponível. Algumas possibilidades no Linux/*BSD são:
gliimagesink (OpenGL), waylandsink
xvimagesink , ximagesink (X11)
kmssink , fbdevsink (gráficos de console sem X11)
vaapisink (para gráficos acelerados por hardware Intel/AMD); para gráficos de hardware NVIDIA (com CUDA) use gliimagesink combinado com " -vd nvh264dec " (ou "nvh264sldec", uma nova variante que se tornará "nvh264dec" no GStreamer-1.24).
Se o servidor estiver "sem cabeça" (sem monitor conectado, renderiza apenas áudio), use -vs 0 .
O GStreamer também procura o melhor “audiosink”; substitua sua escolha por -as <audiosink> . As opções no Linux incluem pulsesink, alsasink, pipewiresink, oss4sink; veja o que está disponível com gst-inspect-1.0 | grep sink | grep -e audio -e Audio .
Um problema comum envolve a tentativa do GStreamer de usar decodificação de vídeo h264 acelerada por hardware configurada incorretamente ou ausente (por exemplo, VAAPI). Tente " uxplay -avdec " para forçar a decodificação de vídeo por software; se funcionar, você pode tentar consertar a decodificação acelerada de vídeo por hardware, se precisar, ou apenas desinstalar o plugin GStreamer vaapi.
Consulte Uso para obter mais opções de tempo de execução.
Para vídeo Framebuffer (para Raspberry Pi OS "Lite" e outras distribuições não X11) use o KMS videosink "-vs kmssink" (o DirectFB framebuffer videosink "dfbvideosink" está quebrado no Pi e segfaults). Neste caso você deve usar explicitamente a opção "-vs kmssink", pois sem ela o autovideosink não encontra o videosink correto.
Raspberry Pi 5 não fornece decodificação H264 de hardware (e não precisa dela).
Pi Zero 2 W, 3 Modelo B+ e 4 Modelo B devem usar decodificação de hardware H264 pela GPU Broadcom, mas requer um módulo de kernel fora do mainstream bcm2835_codec mantido na árvore do kernel Raspberry Pi; as distribuições conhecidas por fornecê-lo incluem Raspberry Pi OS, Ubuntu e Manjaro-RPi4. Use decodificação de software (opção -avdec) se este módulo não estiver disponível.
Uxplay usa o plugin Video4Linux2 (v4l2) do GStreamer-1.22 e posterior para acessar a GPU, se a decodificação de hardware H264 for usada. Isso deve acontecer automaticamente. A opção -v4l2 pode ser usada, mas geralmente é melhor deixar o GStreamer encontrar sozinho o melhor pipeline de vídeo.
Em distribuições mais antigas (GStreamer < 1.22), o plugin v4l2 precisa de um patch: veja o UxPlay Wiki. O Legacy Raspberry Pi OS (Bullseye) possui um GStreamer-1.18.4 parcialmente corrigido que precisa da opção uxplay -bt709 (e não usa -v4l2); ainda é melhor aplicar o patch completo do UxPlay Wiki neste caso.
Para Raspberry Pi OS (Buster) "legado duplo", não há patch para GStreamer-1.14. Em vez disso, primeiro construa um GStreamer-1.18.6 mais recente completo a partir do código-fonte usando estas instruções antes de construir o UxPlay.
Raspberry Pi 3 Modelo B+ executando um sistema operacional de 32 bits também pode acessar a GPU com o plugin GStreamer OMX (use a opção " -vd omxh264dec "), mas isso é quebrado pelo firmware Pi 4 Modelo B. O suporte OMX foi removido do Raspberry Pi OS (Bullseye), mas está presente no Buster.
O vídeo H265 (4K) é compatível com decodificação de hardware pela GPU Broadcom nos modelos Raspberry Pi 5, bem como no Raspberry Pi 4 modelo B. Embora o GStreamer pareça fazer uso dessa decodificação de hardware, velocidade de renderização satisfatória de vídeo 4K por UxPlay em esses modelos Raspberry Pi ainda não foram alcançados. A opção "-h265" é necessária para ativar o suporte h265. Uma conexão Ethernet com fio é preferida neste modo (e pode ser exigida pelo cliente).
Mesmo com a decodificação de vídeo da GPU, alguns quadros podem ser eliminados pelos modelos de menor consumo de energia para manter o áudio e o vídeo sincronizados usando carimbos de data/hora. No Legacy Raspberry Pi OS (Bullseye), raspi-config "Opções de desempenho" permite especificar quanta memória alocar para a GPU, mas esta configuração parece estar ausente no Bookworm (mas ainda pode ser definida para, por exemplo, 128 MB adicionando uma linha "gpu_mem=128" em /boot/config.txt). Um Pi Zero 2 W (que tem 512 MB de memória) funcionou bem quando testado em Bullseye ou Bookworm Lite de 32 bits com 128 MB alocados para a GPU (o padrão parece ser 64 MB).
As opções básicas de uxplay para R Pi são uxplay [-vs <videosink>] . A escolha <videosink> = glimagesink às vezes é útil. Com o compositor de vídeo Wayland, use <videosink> = waylandsink . Com vídeo framebuffer, use <videosink> = kmssink .
ssh user@remote_host
export DISPLAY=:0
nohup uxplay [options] > FILE &
O som e o vídeo serão reproduzidos no host remoto; "nohup" manterá o uxplay rodando se a sessão ssh for fechada. A saída do terminal é salva em FILE (que pode ser /dev/null para descartá-la)
NOTA: Um recurso de servidor de AirPlay nativo está incluído no MacOS 12 Monterey, mas é restrito ao hardware recente. O UXPlay pode ser executado em sistemas MacOS mais antigos que não poderão executar o Monterey, ou podem executar o Monterey, mas não o AirPlay.
Essas instruções para o MacOS assumem que as ferramentas de desenvolvedor da linha de comandos Xcode estão instaladas (se o Xcode estiver instalado, abra o terminal, digite "sudo xcode-select--Install" e aceitam as condições).
Também se supõe que o cmake> = 3.13 esteja instalado: isso pode ser feito com os gerentes de pacotes Macports ( sudo port install cmake ), homebrew ( brew install cmake ) ou por um download de https://cmake.org/download/. Instale também git se você o usar para buscar o uxplay.
Em seguida, instale o LibPlist e OpenSSL-3.x. Observe que as versões estáticas dessas bibliotecas serão usadas nas compilações do MacOS, para que elas possam ser desinstaladas após a construção do UXPlay, se desejar.
Se você usa HomeBrew: brew install libplist openssl@3
Se você usar Macports: sudo port install libplist-devel openssl3
Caso contrário, construa libplista e openssl a partir da fonte: consulte as instruções próximas ao final deste ReadMe; Requer ferramentas de desenvolvimento (AutoConf, Autorake, Libtool, etc. ) a serem instaladas.
Em seguida, obtenha a versão mais recente do MacOS do GStreamer-1.0.
Usando o GSTreamer "oficial" (recomendado para usuários de Macports e Homebrew) : Instale a liberação do GStreamer para MacOS em https://gstreamer.freedesktop.org/download/. (Esta versão contém seu próprio PKG-Config, para que você não precise instalar um.) Instale os pacotes GStreamer-1.0 e GStreamer-1.0-devel. Após o download, clique com ele para instalar (eles instalam em /library/frameworks/gstreamer.framework). Os usuários Homebrew ou Macports não devem instalar (ou desinstalarem) o GStreamer fornecido pelo gerenciador de pacotes, se eles usarem o lançamento "oficial".
Usando o GSTreamer do Homebrew : PKG-Config é necessário: ("Brew Install PKG-Config gStreamer"). Isso faz com que um grande número de pacotes extras seja instalado pelo Homebrew como dependências. A instalação do Homebrew GStreamer foi recentemente reformulada em uma única "fórmula" chamada gstreamer , que agora funciona sem precisar que GST_PLUGIN_PATH seja definido no ambiente. O homebrew instala GStreamer em (HOMEBREW)/lib/gstreamer-1.0 onde (HOMEBREW)/* is /opt/homebrew/* nos macs de silício Apple e /usr/local/* no Intel Macs; Não coloque nenhum plug-ins extra não homusco (que você se constrói) e, em vez disso, defina GST_PLUGIN_PATH para apontar para a localização deles (o Homebrew não fornece um GSTreamer completo, mas parece ter tudo o que é necessário para o UXPlay).
Usando o GStreamer instalado na Macports : isso não é recomendado, pois atualmente o Macports GStreamer é antigo (v1.16.2), sem manutenção e construído para usar o X11:
(Se você realmente deseja usar o Macports gStreamer-1.16.2, instale PkgConf ("Porta sudo Install pkgConf"), então "Sudo Port Instalar GSTREAMER1-GST-PLUGINS-BASE GSTREAMER1-GST-PLUGINS-GOOD GSTREMER1-GST-PLUGINS-PLUGINS -bad gStreamer1-GST-Libav ". Para suporte x11 no macOS, compile uxplay usando uma opção especial de cmake -DUSE_X11=ON e execute -o de um terminal xquartz com -vs ximagesink uxplay -s 800x600
Depois de instalar o GStreamer, construa e instale o UXPlay: abra um terminal e mude para o diretório de origem do UXPlay ("uxplay-mestre" para downloads do ZipFile, "uxplay" para "clone git") e construir/instalar com "cmake"; make; Make; sudo faça instalar "(o mesmo que para Linux).
Executando o uxplay enquanto verifica os avisos do GStreamer (faça isso com "exportar gst_debug = 2" antes do runnng uxplay) revela que, com o padrão (como o UXPlay 1.64) de uso de registros de data e hora para a sinconização de vídeo, muitos quadros de vídeo estão sendo lançados (apenas no macOS), Talvez devido a outro erro (sobre videometa) que aparece nos avisos do GSTREAMER. Recomendação: Use a nova opção UXPlay "No Timestamp" " -vsync no " (você pode adicionar uma linha "VSYNC no" no arquivo de configuração do UXPlayRC).
No MacOS com esta instalação do GStreamer, os únicos videosinks disponíveis parecem ser glimagesLIN (Escolha padrão feita pelo Autovideosink) e osxvideosink. O título da janela não mostra o nome do servidor do AirPlay, mas a janela é visível para aplicativos de compartilhamento de tela (por exemplo, zoom). O único AudiSink disponível parece ser Osxaudiosink.
A opção -NC é sempre usada, seja ou não selecionada. Esta é uma solução alternativa para um problema com os videoSinks GStreamer no macOS: se o oleoduto GStreamer for destruído enquanto a janela do espelho ainda estiver aberta, ocorre um segfault.
No caso do Glimagesink, as configurações de resolução "-s wxh" não afetam o tamanho da janela do espelho inicial (pequeno) do OpenGL, mas a janela pode ser expandida usando o mouse ou o trackpad. Por outro lado, uma janela criada com "-vs osxvideosink" é inicialmente grande, mas possui a proporção errada (imagem esticada); Nesse caso, a proporção muda quando a largura da janela é alterada arrastando seu lado; A opção -vs "osxvideosink force-aspect-ratio=true" pode ser usada para fazer com que a janela tenha a proporção correta quando ela é aberta pela primeira vez.
Faça o download e instale o Bonjour SDK para o Windows v3.0 . Você pode fazer o download do SDK sem nenhum registro em Softpedia.com ou obtê -lo no site oficial da Apple https://developer.apple.com/download (a Apple faz com que você se registre como desenvolvedor para acessá -lo no site deles). Isso deve instalar o Bonjour SDK como C:Program FilesBonjour SDK .
(Isso é para janelas de 64 bits; uma construção para janelas de 32 bits deve ser possível, mas não é testada.) Será usado o ambiente de construção MSYS2 do tipo UNIX: baixar e instalar msys2 no site oficial https: // www .msys2.org/. Aceite o local de instalação padrão C:mysys64 .
Os pacotes MSYS2 são instalados com uma variante do gerenciador de pacotes "Pacman" usado pelo Arch Linux. Abra um terminal "MSYS2 MINGW64" da guia MSYS2 no menu Iniciar do Windows e atualize a nova instalação do MSYS2 com "Pacman -Syu". Em seguida, instale o compilador Mingw-64 e cmake
pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc
O compilador com todas as dependências necessárias será instalado no diretório MSYS64, com o caminho padrão C:/msys64/mingw64 . Aqui, simplesmente criaremos o UXPlay a partir da linha de comando no ambiente MSYS2 (isso usa " ninja " no lugar de " make " para o sistema de construção).
Faça o download do uxplay mais recente do Github (para usar git , instalá -lo com pacman -S git e, em seguida, " git clone https://github.com/FDH2/UxPlay ") e instale as dependências do UXPlay (OpenSSL já está instalado com MSYS2):
pacman -S mingw-w64-x86_64-libplist mingw-w64-x86_64-gstreamer mingw-w64-x86_64-gst-plugins-base
Se você estiver tentando um sistema de construção Windows diferente, as versões MSVC do GStreamer para Windows estarão disponíveis no site oficial do GSTreamer, mas apenas a construção de 64 bits do Mingw no MSYS2 foi testada.
CD para o diretório de origem UXPlay, depois " mkdir build " e " cd build ". O processo de construção pressupõe que o Bonjour SDK esteja instalado em C:Program FilesBonjour SDK . Se estiver em outro lugar, defina a variável enxerto Bonjour_sdk_home para apontar para sua localização. Em seguida, construa uxplay com
cmake ..
ninja
Assumindo nenhum erro em nenhum deles, você terá criado o UxPlay Executável uxplay.exe no diretório atual ("Build"). Os recursos "Sudo Make Install" e "Sudo Make Uninstall" oferecidos nas outras construções não estão disponíveis no Windows; Em vez disso, o ambiente MSYS2 possui /mingw64/... disponível, e você pode instalar o uxplay.exe executável em C:/msys64/mingw64/bin (mais manpágina e documentação em C:/msys64/mingw64/share/... ) com
cmake --install . --prefix /mingw64
Para poder visualizar a Manpage, você precisa instalar o visualizador de manpra com " pacman -S man ".
Para executar uxplay.exe, você precisa instalar alguns pacotes de plug-in GStreamer com pacman -S mingw-w64-x86_64-gst-<plugin> , onde os necessários <plugin> fornecidos por
Outros pacotes possíveis do plug -in MSYS2 GSTREAMER que você pode usar estão listados nos pacotes MSYS2.
Você também precisará conceder permissão ao UXPlay Executável uxplay.exe para acessar dados através do Windows Firewall. Você pode ser oferecido automaticamente a opção de fazer isso quando executa o UXPlay pela primeira vez, ou pode precisar fazê-lo usando o Windows Settings-> Atualização e segurança-> Windows Security-> Firewall & Network Protection-> Permitir um aplicativo através do firewall . Se o seu vírus sinaliza o uxplay.exe como "suspeito" (mas sem uma verdadeira assinatura de malware), pode ser necessário dar uma exceção.
Agora teste executando o " uxplay " (em uma janela do terminal MSYS2). Se você precisar especificar o AudiSink, há duas opções principais no Windows: o plug -in DirectSound mais antigo " -as directsoundsink " e o plug -in mais moderno da API de sessão de áudio do Windows (WASAPI) " -as wasapisink ", que suporta opções adicionais, como
uxplay -as 'wasapisink device="<guid>"'
Onde <guid> Especifica um dispositivo de áudio disponível por seu GUID, que pode ser encontrado usando o " gst-device-monitor-1.0 Audio ": <guid> tem um formulário como {0.0.0.00000000}.{98e35b2b-8eba-412e-b840-fd2c2492cf44} . Se " device " não for especificado, o dispositivo de áudio padrão será usado.
Se você deseja especificar o videoSink usando a opção -vs <videosink> , algumas opções para <videosink> são d3d11videosink , d3dvideosink , glimagesink , gtksink .
-vs "d3d11videosink fullscreen-toggle-mode=property fullscreen=true" Combinação com opção -vs "d3d11videosink fullscreen-toggle-mode=alt-enter" . Por conveniência, essas opções serão adicionadas se apenas -vs d3d11videosink com ou sem a opção de tela completa "-fs" for usada. (Os usuários do Windows podem querer adicionar " vs d3d11videosink " (sem inicial " - ") ao arquivo de opções de inicialização do uxplay; consulte "man uxplay" ou "uxplay -h".).) O uxplay.exe executável também pode ser executado sem o ambiente MSYS2, no terminal do Windows, com C:msys64mingw64binuxplay .
Opções:
- " inicial) no arquivo de inicialização do UXPlay (fornecido pela variável de ambiente $UXPLAYRC ou ~/.uxplayrc ou ~/.config/uxplayrc ); Linhas começando com " # " são tratadas como comentários e ignoradas. As opções de linha de comando substituem as opções no arquivo de inicialização.-n server_name (padrão: uxplay); Server_name@ HostName será o nome que aparece oferecendo serviços de AirPlay para o seu iPad, iPhone etc, onde o nome do host é o nome do servidor que executa o UXPlay. Este também será o nome mostrado acima da janela Mirror Display (x11).
-NH Não anexa "@ hostName " no final do nome do servidor do AirPlay.
-H265 Ative o suporte "ScreenMulticodec" (AirPlay "apresenta" Bit 42) para aceitar o vídeo H265 (4K/HEVC), além do vídeo H264 (1080p) no modo de tela de tela. Quando esta opção é usada, dois "pipelines de vídeo" (um para H264, um para H265) são criados. Se algum plug -ins Gstreamer no pipeline for específico para H264 ou H265, a versão correta será usada em cada tubulação. Uma conexão Ethernet cliente-servidor com fio é preferida no WiFi para o vídeo em 4K e pode ser exigido pelo cliente. Somente os dispositivos Apple recentes (M1/M2 Macs ou iPads e alguns iPhones) podem enviar vídeo H265 se um resolução "-s wxh" com h> 1080 for solicitado. A opção "-h265" altera a opção de resolução padrão ("-s") de 1920x1080 para 3840x2160 e deixa a opção máxima padrão padrão ("-fps") a 30fps.
-pin [nnnn] : (como v1.67) use a autenticação de "pino" no estilo da Apple (uma vez) quando um novo cliente se conecta pela primeira vez: um código de pino de quatro dígitos é exibido no terminal e o cliente A tela mostra um prompt de login para que isso seja inserido. Quando "-pin" é usado por si só, um novo código de pino aleatório é escolhido para cada autenticação; Se "-pin nnnn" (por exemplo, "-pin 3939") for usado, isso definirá um código fixo imutável. A autenticação adiciona o servidor à lista de "servidores confiáveis" do cliente e o cliente não precisará reautenticar, desde que as chaves públicas do cliente e do servidor permaneçam inalteradas. (Por padrão, desde a v1.68, a chave pública do servidor é gerada a partir do endereço MAC, que pode ser alterado com a opção -m; consulte a opção -Key para um método alternativo de geração de chave). (Adicione uma linha "PIN" no arquivo de inicialização do UXPlay, se desejar que o servidor uxplay use o protocolo de autenticação PIN).
-reg [ nome do arquivo ] : (desde v1.68). Se "-pin" for usado, esta opção manterá um registro de "clientes confiáveis" autenticados por pinos em $ home/.uxplay.register (ou opcionalmente, no nome do arquivo ). Sem essa opção, devolvendo os clientes que a autenticação de pin pin é confiável e não é verificada. Esta opção pode ser útil se o UXPlay for usado em um ambiente mais público, para gravar detalhes do cliente; O registro é o texto, uma linha por cliente, com a chave pública do cliente (formato base-64), ID do dispositivo e nome do dispositivo; Comentando (com "#") ou excluindo uma linha desregira o cliente correspondente (consulte Opções -Restrit, -block, -low para obter mais maneiras de controlar o acesso ao cliente). (Adicione uma linha "reg" no arquivo de inicialização, se desejar usar esse recurso.)
-vsync [x] (no modo espelhado :) Esta opção ( agora o padrão ) usa registro de data e hora para sincronizar o áudio com o vídeo no servidor, com um atraso opcional de áudio no (decimal) milissegundos ( x = "20.5" significa 0,0205 segundos atraso: atrasos positivos ou negativos menos de um segundo são permitidos.) É necessário em sistemas de baixa potência, como o Raspberry Pi, sem decodificação de vídeo de hardware.
-vsync Não (no modo espelhado :) Isso desliga a sincronização de áudio-vídeo baseada em registro de registro de registro de registro de registro, restaurando o comportamento padrão antes do uxplay-1.64. Os sistemas de desktop padrão parecem funcionar bem sem o uso de registros de data e hora: este modo é apropriado para "transmissão ao vivo", como o uso do UXPlay como um segundo monitor para um computador Mac ou monitorar uma webcam; Com ele, nenhum quadros de vídeo são descartados.
-Async [x] (no modo somente de áudio (ALAC) :) Esta opção usa registros de data e hora para sincronizar o áudio no servidor com o vídeo no cliente, com um atraso opcional de áudio em milissegundos (decimais) ( x = "20,5" significa 0,0205 Atraso de segundos: atrasos positivos ou negativos menos de um segundo são permitidos.) Como o cliente adiciona um atraso em vídeo para explicar a latência, o servidor no modo -Sync adiciona um atraso de áudio equivalente, o que significa que as alterações de áudio tais tais Como uma pausa ou uma trilha, não entrará em vigor imediatamente. Isso pode, em princípio, ser atenuado usando a configuração de latência de áudio -al para alterar a latência (padrão de 0,25 s) que o servidor se reporta ao cliente, mas atualmente alterando isso não parece ter nenhum efeito .
-Async no . Esse ainda é o comportamento padrão no modo somente de áudio, mas essa opção pode ser útil como uma opção de linha de comando para desligar uma opção -async definida em um arquivo de configuração "uxplayrc".
-DB baixo [: alto ] redimensionar a atenuação do controle de volume do airplay (ganho) de -30dB: 0dB a baixo : 0dB ou baixo : alto . O limite inferior baixo deve ser negativo (atenuação); O limite superior alto pode ser um sinal. (O GStreamer restringe a agvação de volume por alta , para que não possa exceder +20dB). O redimensionamento é "plano", de modo que, para -db -50: 10, uma mudança na atenuação do airplay em -7db é traduzida para A -7 x (60/30) = -14db Atenuação e o volume máximo (AirPlay 0DB) é um aumento de 10dB e o AirPlay -30dB se tornaria -50db. Observe que o valor mínimo do AirPlay (-30dB exatamente) é traduzido para "mudo".
-Taper fornece um perfil de controle de volume de ar "cônico" (correspondente ao chamado "Dasl-Tappering" em Shairport-Sync): cada vez que o comprimento do controle deslizante de volume (ou o número de etapas acima do mudo, onde 16 etapas = completo volume) é reduzido em 50%, o volume percebido é reduzido pela metade (uma atenuação de 10dB). (Isso é modificado em volumes baixos, para usar o volume "não cano", se for mais alto.)
-S WXH EG -S 1920X1080 (= "1080p"), as resoluções de largura e altura padrão em pixels para o vídeo H264. (O padrão se torna 3840x2160 (= "4K") quando a opção -h265 é usada.) Essa é apenas uma solicitação feita ao cliente do AirPlay e talvez não seja a resolução final que você obtém. W e H são números inteiros com quatro dígitos ou menos. Observe que o tamanho do pixel de altura é o controlador usado pelo cliente para determinar o formato de streaming; A largura é ajustada dinamicamente à forma da imagem (formato de retrato ou paisagem, dependendo de como um iPad é mantido, por exemplo).
-s wxh@r como acima, mas também informa o cliente do AirPlay sobre a taxa de atualização da tela da tela. O padrão é r = 60 (60 Hz); r deve ser um número inteiro menor que 256.
-O ative uma opção "super -escaneada" para a janela de exibição. Isso reduz a resolução da imagem usando alguns dos pixels solicitados pela opção -s wxh (ou seus valores padrão 1920x1080), adicionando uma estrutura de limite vazia de pixels não utilizados (que seriam perdidos em uma tela de tela completa que overcans e não é exibido por gstreamer). Recomendação: Não use esta opção , a menos que haja algum motivo especial para usá -la.
-FS usa o modo de tela cheia, mas funciona apenas com X11, Wayland, VAAPI e D3D11 (Windows).
-P permite selecionar as portas de rede usadas pelo UXPlay (elas precisam ser abertas se o servidor estiver atrás de um firewall). Por si só, -P define as portas "Legacy" TCP 7100, 7000, 7001, UDP 6000, 6001, 7011. -Pn (por exemplo -P 35000) Define as portas TCP e UDP n, n+1, n+2. -p n1, n2, n3 (valores separados por vírgula) define cada porta separadamente; -p n1, n2 define as portas n1, n2, n2+1. -p tcp n ou -p udp n define apenas as portas TCP ou UDP. As portas devem estar no intervalo [1024-65535].
Se a opção -p não for usada, as portas serão escolhidas dinamicamente (aleatoriamente), que não funcionarão se um firewall estiver em execução.
-AVDEC Forças Uso do software H264 Decodificação usando o elemento GStreamer AVDEC_H264 (decodificador Libav H264). Esta opção deve impedir que o Autovideosink escolha um plug-in de VideoSink acelerado de hardware, como o Vaapisink.
-VP Parsers escolhe o elemento analsário H264 do GSTREAMER, o padrão é o H264Parse. Usar aspas "..." permite que as opções sejam adicionadas.
-VD O decodificador escolhe o elemento decodificador H264 do GStreamer Pipeline, em vez do valor padrão "Decodebin", que o escolhe para você. A decodificação de software é feita por AVDEC_H264; Vários decodificadores de hardware incluem: VAAPIH264DEC, NVDEC, NVH264DEC, V4L2H264DEC (eles exigem que o hardware apropriado esteja disponível). Usar aspas "..." permite que alguns parâmetros sejam incluídos no nome do decodificador.
-VC Converter escolhe o elemento videoconverter do GStreamer Pipeline, em vez do valor padrão "Videoconvert". Ao usar o hardware do vídeo4Linux2 por uma gpu, -vc v4l2convert também usará a GPU para conversão de vídeo. Usar aspas "..." permite que alguns parâmetros sejam incluídos no nome do conversor.
-vs O VideoSink escolhe o VideoSink GStreamer, em vez do valor padrão "AutovideOsink", que o escolhe para você. Algumas opções de videoSink são: ximagesink, xvimagesink, Vaapisink (para gráficos Intel), GTKSink, Glimagesink, WaylandSink, Osxvideosink (para MacOS), KmsSlink (para sistemas sem X11, como Raspberry Pi Lite) ou FPSDIsPlinSink (que mostra o streamreador no fretamento no fretamento no fretamento no fretamento no fretamento, como o frenamento de Raspberry Pi Lite) ou FPSDIsPlinSink (que mostra o streamreador no fretamento no fretamento, como o Framring, como o Framring, o Framrer, como o Framring, o Framrrety, como o Framring, o Framer no Framrador no Framrre fps). O uso de citações "..." permite que alguns parâmetros sejam incluídos no nome do videoSink. Por exemplo, o modo de tela cheia é suportada pelo plug -in Vaapisink e é obtida usando -vs "vaapisink fullscreen=true" ; Isso também funciona com waylandsink . A sintaxe de tais opções é específica para um determinado plug -in (consulte a documentação do GStreamer), e algumas opções de videosink podem não funcionar no seu sistema.
-vs 0 suprime a exibição do vídeo transmitido. No modo Mirror, a tela do cliente ainda é espelhada a uma taxa reduzida de 1 quadro por segundo, mas não é renderizada ou exibida. Essa opção sempre deve ser usada se o servidor estiver "sem cabeça" (sem tela anexada para exibir vídeo) e usada apenas para renderizar áudio, que será AAC com áudio com perda de perda no modo espelhado com vídeo não renderizado e Alac com qualidade superior Apple sem perda de áudio no modo apenas de áudio do AirPlay.
-v4l2 Configurações de vídeo para decodificação de vídeo H264 Hardware na GPU por vídeo4Linux2. Equivalente a -vd v4l2h264dec -vc v4l2convert .
-BT709 Uma solução alternativa para a falha do plug-in mais antigo do Video4Linux2 para reconhecer o uso da Apple de uma variante incomum (mas permitida) "cor completa" do padrão BT709 para a TV digital. Isso não é mais necessário para o GStreamer-1.20.4 e o Backports dele.
-RPI equivalente a "-v4l2" (não é válido para o Raspberry Pi Modelo 5 e removido no UXPlay 1.67)
-rpigl equivalente a "-rpi -vs glimagesink". (Removido desde o uxplay 1.67)
-rpifb equivalente a "-rpi -vs kmsSink" (removido desde o uxplay 1.67)
-rpiwl equivalente a "-rpi -vs waylandsink". (Removido desde o uxplay 1.67)
-Sa O AudiosLink escolhe o GSTREAMER AudiosLink, em vez de deixar o AutoaudiosLink escolher para você. Algumas opções de AudiSink são: PulseSink, Alsasink, Pipewiresink, OssSink, OSS4Sink, JackaudiosLink, Osxaudiosink (para MacOS), Wasapisink, DirectSoundSink (para Windows). O uso de aspas "..." pode permitir alguns parâmetros opcionais (por exemplo -as "alsasink device=..." para especificar um dispositivo de saída não -defensor). A sintaxe de tais opções é específica para um determinado plug -in (consulte a documentação do GStreamer), e algumas opções do AudiosLink podem não funcionar no seu sistema.
-As 0 (ou apenas -a ) suprime a reprodução de áudio transmitido, mas exibe vídeo transmitido.
-al x especifica uma latência de áudio x em (decimal) segundos em somente áudio (ALAC), que é relatado ao cliente. Os valores no intervalo [0,0, 10,0] são permitidos e serão convertidos em um número inteiro de microssegundos. O padrão é de 0,25 s (250000 USEC). (No entanto, o cliente parece ignorar essa latência relatada; portanto, essa opção parece não funcional.)
-ca nome do arquivo fornece um arquivo (onde o nome do arquivo pode incluir um caminho completo) usado para a saída de "cover art" (da Apple Music, etc. ) no modo ALAC somente em áudio. Este arquivo é substituído com a mais recente arte da capa à medida que chega. A arte da capa (formato JPEG) é descartada se esta opção não for usada. Use com um visualizador de imagem que recarregue a imagem se ela mudar ou regularmente ( por exemplo, uma vez por segundo.). Para conseguir isso, execute " uxplay -ca [path/to/]filename & " em segundo plano e execute o visualizador de imagem em primeiro plano. Exemplo, usando feh como o visualizador: execute " feh -R 1 [path/to/]filename " (na mesma janela de terminal na qual o uxplay foi colocado em segundo plano). Para sair, use ctrl-C fg ctrl-C para encerrar o visualizador de imagem, traga
