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 for usada, a arte da capa que acompanha também será enviada para um arquivo
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 repositório complementar "CodeReady", 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- . Os valores de
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 deve sempre 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 possam 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 , -block ) 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 " em segundo plano e, em seguida, execute um visualizador de imagens com um carregamento automático recurso: um exemplo é "feh": execute " feh -R 1 " 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 . 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 . 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 . A escolha glimagesink às vezes é útil. Com o compositor de vídeo Wayland, use waylandsink . Com vídeo framebuffer, use 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 ao X11 no macOS, compile uxplay usando uma opção cmake especial -DUSE_X11=ON e execute-o de um terminal Xquartz com -vs ximagesink; macs não-retina mais antigos requerem uma resolução mais baixa ao usar o uso X11: 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- , onde os necessários
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=""'
Onde gst-device-monitor-1.0 Audio ": {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 , algumas opções para 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: esse 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 menores 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 como uma pausa ou um A trilha-mudança 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, leve uxplay para o primeiro plano e também o encerre.
-reset n define um limite de n falhas de tempo limite consecutivas do cliente para responder às solicitações NTP do servidor (elas são enviadas a cada 3 segundos para verificar se o cliente ainda está presente e sincronize com ele). Após N falhas, presume -se que o cliente esteja offline e a conexão será redefinida para permitir uma nova conexão. O valor padrão de n é 5; O valor n = 0 significa "sem limite" nos tempos limite.
-Nofreeze fecha a janela de vídeo após uma redefinição devido ao tempo limite do NTP (o padrão é deixar a janela aberta para permitir uma reconecção mais suave para o mesmo cliente). Esta opção pode ser útil no modo de tela cheia.
-NC mantém o comportamento anterior UXPlay <1,45 que não fecha a janela de vídeo quando o cliente envia o sinal "Stop espelhando". Atualmente, esta opção é usada por padrão no macOS, como a janela criada no macOS por GStreamer não termina corretamente (causa um segfault) se ainda estiver aberto quando o pipeline gstreamer estiver fechado.
-Não abriga a conexão atual quando um novo cliente tenta se conectar. Sem essa opção, o cliente atual mantém a propriedade exclusiva do UXPlay até que ele se desconecte.
- -restringir os clientes restringem a se conectar àqueles especificados por -allow . O DeviceId possui a forma de um endereço MAC exibido pelo UXPlay quando o cliente tenta se conectar e parece ser imutável. Ele possui o formato XX:XX:XX:XX:XX:XX , x = 0-9, AF, e é possivelmente o endereço MAC de hardware "verdadeiro" do dispositivo. Observe que os clientes do iOS geralmente expõem diferentes endereços MAC de Wi_Fi particulares ("Fake" MAC) a diferentes redes (por razões de privacidade, para evitar o rastreamento), que podem mudar e não correspondem ao DeviceId.
-Ferrestre não remover restrições (padrão). Isso é útil como um argumento da linha de comando para sobrecarregar as restrições definidas no arquivo de inicialização.
-Alow ID adiciona o dispositivo DeviceId = ID à lista de clientes permitidos quando as restrições do cliente estão sendo aplicadas. Normalmente, isso será uma entrada no arquivo de inicialização do UXPlayRC.
-Block ID sempre bloqueia os clientes com o DeviceID = ID , mesmo quando as restrições do cliente não estão sendo aplicadas em geral. Normalmente, isso será uma entrada no arquivo de inicialização do UXPlayRC.
-Fpsdata ativa o monitoramento de relatórios regulares sobre o desempenho de streaming de vídeo enviado pelo cliente. Eles serão exibidos na janela do terminal se esta opção for usada. Os dados são atualizados pelo cliente em 1 segundo intervalos.
-fps n define uma taxa de quadro máximo (em quadros por segundo) para o cliente do AirPlay transmitir vídeo; n deve ser um número inteiro inferior a 256. (O cliente pode optar por servir vídeo a qualquer taxa de quadros menor que isso; o padrão é 30 fps.) Uma configuração de 60 fps pode fornecer vídeo aprimorado, mas não é recomendado no Raspberry Pi. Uma configuração abaixo de 30 qps pode ser útil para reduzir a latência se você estiver executando mais de uma instância do UXPlay ao mesmo tempo. Essa configuração é apenas um aviso para o dispositivo do cliente; portanto, definir um valor alto não forçará uma alta taxa de quadros. (Você pode testar usando "-vs fpsDisplaysink" para ver o que está sendo recebido por quadros ou usar a opção -fpsdata, que exibe dados de desempenho de fluxo de vídeo enviados continuamente pelo cliente durante a transmissão de vídeo.)
-f {h | v | i} implementa as transformações da imagem "videoflip": h = flip horizontal (flip-esquerdo da esquerda ou imagem espelhada); V = flip vertical; I = rotação ou inversão de 180 graus (que é a combinação de H com V).
-r {r | l} 90 graus à direita (no sentido horário) ou à esquerda (no sentido anti-horário); Essas transformações de imagem são realizadas após qualquer transformação -f .
-m [Mac] altera o endereço MAC (ID do dispositivo) usado pelo UXPlay (o padrão é usar o endereço MAC de hardware verdadeiro relatado pela placa de rede do computador host). (Diferentes servidores, endereços MAC e portas de rede são necessários para cada UXPlay em execução se você tentar executar mais de uma instância do UXPlay no mesmo computador.) Se [Mac] (no formulário XX: XX: XX: XX: XX: xx, 6 octetos hexáticos) não é fornecida, um endereço MAC aleatório é gerado. Se o UXPlay não encontrar o endereço MAC verdadeiro de uma placa de rede (mais especificamente, o endereço MAC usado pela primeira interface de rede ativa detectada) Um endereço MAC aleatório será usado mesmo que a opção -m não fosse especificada. (Observe que um endereço MAC aleatório será diferente cada vez que o uxplay for iniciado).
-Key [ nome do arquivo ] : Esta opção (mais segura) para gerar e armazenar uma chave pública persistente (necessária para a opção -pin) foi substituída por padrão por um método (menos seguro) que gera uma chave do "ID do dispositivo do servidor "(Endereço MAC, que pode ser alterado com a opção -m, convenientemente como uma opção de arquivo de inicialização). Quando a opção -Key é usada, um teclado gerado com segurança é gerado e armazenado em $HOME/.uxplay.pem , se esse arquivo não existir ou ler, se existir. (Opcionalmente, a chave pode ser armazenada no nome do arquivo .) Esse método é mais seguro do que o novo método padrão (porque o ID do dispositivo é transmitido no anúncio DNS_SD), mas ainda deixa a chave privada exposta a qualquer pessoa que possa acessar o arquivo PEM . Esta opção deve ser definida no arquivo de inicialização do UXPlay como uma linha "chave" ou " nome do arquivo de chave" (sem inicial "-"), onde o nome do arquivo é um caminho completo que deve ser fechado nas citações ( "...." ) se Ele contém qualquer espaços em branco. Como o método padrão é mais simples e é improvável que o acesso ao cliente ao UXPlay seja um problema importante, a opção -Key não é mais recomendada .
-dacp [ nome do arquivo ] : exportar o cliente atual DACP-ID e a chave de remoção ativa para o arquivo: o padrão é $ home/.uxplay.dacp. (Opcionalmente pode ser alterado para o nome do arquivo ). Pode ser usado por aplicativos de controle remoto. O arquivo é transitório: existe apenas enquanto o cliente está conectado.
-vdmp dumps h264 vídeo para arquivo videodump.h264. -vdmp n despejos não mais do que unidades nais para videodump.x.h264; x = 1,2, ... aumenta cada vez que uma unidade NAL SPS/PPS chega. Para alterar o nome Videodump , use -vdmp [n] nome do arquivo .
-AdMP despeja áudio para arquivar Audiodump.x.aac (AAC-ELD Format Audio), Audiodump.x.alac (ALAC Format Audio) ou Audiodump.x.aud (áudio de outro formato), onde x = 1,2,3 ... aumenta cada vez que o formato de áudio muda. -AdMP n restringe o número de pacotes despejados em um arquivo para n ou menos. Para alterar o nome Audiodump , use -admp [n] nome do arquivo . Observe que (diferentemente do vídeo despejado), o áudio despejado é atualmente útil apenas para depuração, pois não é contêiner para torná -lo jogável com players de áudio padrão.
-d Ativar saída de depuração. NOTA: Isso não mostra erros gstreamer ou mensagens de depuração. Para ver as mensagens do GSTREAMER ERRO e AVISO, defina a variável de ambiente GST_DEBUG com "Export gst_debug = 2" antes de executar o UXPlay. Para ver as mensagens de informação gStreamer, defina gst_debug = 4; Para mensagens de depuração, gst_debug = 5; Aumente isso para ver ainda mais os trabalhos internos do GStreamer.
Nota: uxplay é executado a partir de uma linha de comando de terminal e as mensagens informativas são gravadas no terminal.
Um usuário (no Ubuntu) encontrou a compilação falhada com mensagens sobre vincular a "usr/local/lib/libcrypto.a" e "zlib". Isso ocorreu porque (além da instalação padrão do Ubuntu do LIBSSL-DEV), o usuário não sabia que uma segunda instalação com libcrypto em /usr /local estava presente. Solução: Quando mais de uma instalação do OpenSSL estiver presente, defina a variável de ambiente Open_SSL_ROOT_DIR para apontar para o correto; No Ubuntu de 64 bits, isso é feito executando export OPENSSL_ROOT_DIR=/usr/lib/X86_64-linux-gnu/ antes de executar o cmake.
O serviço DNS_SD Service-Discovery ("Bonjour" ou "Zeroconf") é necessário para que o UXPlay funcione. No Linux, geralmente será fornecido por Avahi e, para solucionar isso, você deve usar a ferramenta avahi-browse . (Pode ser necessário instalar um pacote separado com um nome como avahi-utils para obter isso.)
No Linux, verifique se Avahi está instalado e inicie o serviço Avahi-Daemon no sistema que executa o uxplay (sua distribuição documentará como fazer isso, por exemplo: sudo systemctl ou sudo service avahi-daemon , com sudo find /etc -name avahi-daemon.conf iniciar, parar, status. sudo find /etc -name avahi-daemon.conf "): verifique se" desabilitar a publicação " não é uma opção selecionada). Alguns sistemas podem usar o daemon MDNSD como uma alternativa para fornecer serviço DNS-SD. (FreeBSD offers both alternatives, but only Avahi was tested; see here.)
If UxPlay stops with the "No DNS-SD Server found" message, this means that your network does not have a running Bonjour/zeroconf DNS-SD server. Before v1.60, UxPlay used to stall silently if DNS-SD service registration failed, but now stops with an error message returned by the DNSServiceRegister function: kDNSServiceErr_Unknown if no DNS-SD server was found: (A NixOS user found that in NixOS, this error can also occur if avahi-daemon service IS running with publishing enabled, but reports "the error disappeared on NixOS by setting services.avahi.openFirewall to true".) Other mDNS error codes are in the range FFFE FF00 (-65792) to FFFE FFFF (-65537), and are listed in the dnssd.h file. An older version of this (the one used by avahi) is found here. A few additional error codes are defined in a later version from Apple.
If UxPlay stalls without an error message and without the server name showing on the client , this is a network problem (if your UxPlay version is older than 1.60, it is also the behavior when no DNS-SD server is found.)
A useful tool for examining such network problems from the client end is the (free) Discovery DNS-SD browser available in the Apple App Store for both iOS (works on iPadOS too) and macOS.
If your router has this problem, a reported "fix" is to (at least on 5GHz) use fixed channel and/or fixed (not dynamic) channel width.
This is usually because Avahi is only using the "loopback" network interface, and is not receiving mDNS queries from new clients that were not listening when UxPlay started.
To check this, after starting uxplay, use the utility avahi-browse -a -t in a different terminal window on the server to verify that the UxPlay AirTunes and AirPlay services are correctly registered (only the AirTunes service is used in the "Legacy" AirPlay Mirror mode used by UxPlay, but the AirPlay service is used for the initial contact).
The results returned by avahi-browse should show entries for uxplay like
+ 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
If only the loopback ("lo") entries are shown, a firewall on the UxPlay host is probably blocking full DNS-SD service, and you need to open the default UDP port 5353 for mDNS requests, as loopback-based DNS-SD service is unreliable.
If the UxPlay services are listed by avahi-browse as above, but are not seen by the client, the problem is likely to be a problem with the local network.
This shows that a DNS-SD service is working, clients hear UxPlay is available, but the UxPlay server is not receiving the response from the client. This is usually because a firewall on the server is blocking the connection request from the client. (One user who insisted that the firewall had been turned off turned out to have had two active firewalls ( firewalld and ufw ) both running on the server!) If possible, either turn off the firewall to see if that is the problem, or get three consecutive network ports, starting at port n, all three in the range 1024-65535, opened for both tcp and udp, and use "uxplay -pn" (or open UDP 7011,6001,6000 TCP 7100,7000,7001 and use "uxplay -p").
If you are really sure there is no firewall, you may need to investigate your network transmissions with a tool like netstat, but almost always this is a firewall issue.
If you do not see the message raop_rtp_mirror starting mirroring , something went wrong before the client-server negotiations were finished. For such problems, use "uxplay -d " (debug log option) to see what is happening: it will show how far the connection process gets before the failure occurs. You can compare your debug output to that from a successful start of UxPlay in the UxPlay Wiki.
If UxPlay reports that mirroring started, but you get no video or audio, the problem is probably from a GStreamer plugin that doesn't work on your system (by default, GStreamer uses the "autovideosink" and "autoaudiosink" algorithms to guess what are the "best" plugins to use on your system). A different reason for no audio occurred when a user with a firewall only opened two udp network ports: three are required (the third one receives the audio data).
Raspberry Pi devices ( Pi 4B+ and earlier: this does not apply to the Pi 5, which does not provide hardware h264 decoding, and does not need it ) work best with hardware GPU h264 video decoding if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has been patched (see the UxPlay Wiki for patches). This is fixed in GStreamer-1.22, and by backport patches from this in distributions such as Raspberry Pi OS (Bullseye): use option -bt709 with the GStreamer-1.18.4 from Raspberry Pi OS . This also needs the bcm2835-codec kernel module that is not in the standard Linux kernel (it is available in Raspberry Pi OS, Ubuntu and Manjaro).
-avdec for software h264-decoding.Sometimes "autovideosink" may select the OpenGL renderer "glimagesink" which may not work correctly on your system. Try the options "-vs ximagesink" or "-vs xvimagesink" to see if using one of these fixes the problem.
Other reported problems are connected to the GStreamer VAAPI plugin (for hardware-accelerated Intel graphics, but not NVIDIA graphics). Use the option "-avdec" to force software h264 video decoding: this should prevent autovideosink from selecting the vaapisink videosink. Alternatively, find out if the gstreamer1.0-vaapi plugin is installed, and if so, uninstall it. (If this does not fix the problem, you can reinstall it.)
There are some reports of other GStreamer problems with hardware-accelerated Intel HD graphics. One user (on Debian) solved this with "sudo apt install intel-media-va-driver-non-free". This is a driver for 8'th (or later) generation "*-lake" Intel chips, that seems to be related to VAAPI accelerated graphics.
If you do have Intel HD graphics, and have installed the vaapi plugin, but -vs vaapisink does not work, check that vaapi is not "blacklisted" in your GStreamer installation: run gst-inspect-1.0 vaapi , if this reports 0 features , you need to export GST_VAAPI_ALL_DRIVERS=1 before running uxplay, or set this in the default environment.
You can try to fix audio or video problems by using the " -as " or " -vs " options to choose the GStreamer audiosink or videosink , rather than letting GStreamer choose one for you. (See above, in Starting and running UxPlay for choices of
The "OpenGL renderer" window created on Linux by "-vs glimagesink" sometimes does not close properly when its "close" button is clicked. (this is a GStreamer issue). You may need to terminate uxplay with Ctrl-C to close a "zombie" OpenGl window. If similar problems happen when the client sends the "Stop Mirroring" signal, try the no-close option "-nc" that leaves the video window open.
rm -rf ~/.cache/gstreamer-1.0/* may be the solution to problems where gst-inspect-1.0 does not show a plugin that you believe is installed. The cache will be regenerated next time GStreamer is started. This is the solution to puzzling problems that turn out to come from corruption of the cache, and should be tried first. If UxPlay fails to start, with a message that a required GStreamer plugin (such as "libav") was not found, first check with the GStreamer tool gst-inspect-1.0 to see what GStreamer knows is available. (You may need to install some additional GStreamer "tools" package to get gst-inspect-1.0). For, eg a libav problem, check with " gst-inspect-1.0 libav ". If it is not shown as available to GStreamer, but your package manager shows the relevant package as installed (as one user found), try entirely removing and reinstalling the package. That user found that a solution to a " Required gstreamer plugin 'libav' not found " message that kept recurring was to clear the user's gstreamer cache.
If it fails to start with an error like ' no element "avdec_aac" ' this is because even though gstreamer-libav is installed. it is incomplete because some plugin features are missing: " gst-inspect-1.0 | grep avdec_aac " will show if avdec_aac is available. Unlike other GStreamer plugins, the libav plugin is a front end to FFmpeg codecs which provide avdec_*.
Some distributions (RedHat, SUSE, etc) provide incomplete versions of FFmpeg because of patent issues with codecs used by certain plugins. In those cases there will be some "extra package" provider like RPM fusion (RedHat), packman (SUSE) where you can get complete packages (your distribution will usually provide instructions for this, Mageia puts them in an optional "tainted" repo) . The packages needed may be "ffmpeg*" or "libav*" packages: the GStreamer libav plugin package does not contain any codecs itself, it just provides a way for GStreamer to use ffmpeg/libav codec libraries which must be installed separately. For similar reasons, distributions may ship incomplete packages of GStreamer "plugins-bad". Use user on Fedora thought they had installed from rpmfusion, but the system had not obeyed: "Adding --allowerasing to the dnf command fixed it after a restart" .
starting with release UxPlay-1.65.3, UxPlay will continue to function, but without audio in mirror mode, if avdec_aac is missing.
To troubleshoot GStreamer execute "export GST_DEBUG=2" to set the GStreamer debug-level environment-variable in the terminal where you will run uxplay, so that you see warning and error messages; see GStreamer debugging tools for how to see much more of what is happening inside GStreamer. Run "gst-inspect-1.0" to see which GStreamer plugins are installed on your system.
Some extra GStreamer packages for special plugins may need to be installed (or reinstalled: a user using a Wayland display system as an alternative to X11 reported that after reinstalling Lubuntu 18.4, UxPlay would not work until gstreamer1.0-x was installed, presumably for Wayland's X11-compatibility mode). Different distributions may break up GStreamer 1.x into packages in different ways; the packages listed above in the build instructions should bring in other required GStreamer packages as dependencies, but will not install all possible plugins.
The GStreamer video pipeline, which is shown in the initial output from uxplay -d , has the default form
appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! autovideosink name=video_sink sync=false
The pipeline is fully configurable: default elements "h264parse", "decodebin", "videoconvert", and "autovideosink" can respectively be replaced by using uxplay options -vp , -vd , -vc , and -vs , if there is any need to modify it (entries can be given in quotes "..." to include options).
This can happen if the TCP video stream from the client stops arriving at the server, probably because of network problems (the UDP audio stream may continue to arrive). At 3-second intervals, UxPlay checks that the client is still connected by sending it a request for a NTP time signal. If a reply is not received from the client within a 0.3 sec time-window, an "ntp timeout" is registered. If a certain number (currently 5) of consecutive ntp timeouts occur, UxPlay assumes that the client is "dead", and resets the connection, becoming available for connection to a new client, or reconnection to the previous one. Sometimes the connection may recover before the timeout limit is reached, and if the default limit is not right for your network, it can be modified using the option "-reset n ", where n is the desired timeout-limit value ( n = 0 means "no limit"). If the connection starts to recover after ntp timeouts, a corrupt video packet from before the timeout may trigger a "connection reset by peer" error, which also causes UxPlay to reset the connection.
A protocol failure may trigger an unending stream of error messages, and means that the audio decryption key (also used in video decryption) was not correctly extracted from data sent by the client.
The protocol was modifed in UxPlay-1.65 after it was discovered that the client-server "pairing" step could be avoided (leading to a much quicker connection setup, without a 5 second delay) by disabling "Supports Legacy Pairing" (bit 27) in the "features" code UxPlay advertises on DNS-SD Service Discovery. Most clients will then not attempt the setup of a "shared secret key" when pairing, which is used by AppleTV for simultaneous handling of multiple clients (UxPlay only supports one client at a time). This change is now well-tested, but in case it causes any protocol failures, UxPlay can be reverted to the previous behavior by uncommenting the previous "FEATURES_1" setting (and commenting out the new one) in lib/dnssdint.h, and then rebuilding UxPlay. ("Pairing" is re-enabled when the new Apple-style one-time "pin" authentication is activated by running UxPlay with the "-pin" option introduced in UxPlay 1.67.)
Protocol failure should not happen for iOS 9.3 or later clients. However, if a client uses the same older version of the protocol that is used by the Windows-based AirPlay client emulator AirMyPC , the protocol can be switched to the older version by the setting OLD_PROTOCOL_CLIENT_USER_AGENT_LIST in UxPlay/lib/global.h . UxPlay reports the client's "User Agent" string when it connects. If some other client also fails to decrypt all audio and video, try adding its "User Agent" string in place of "xxx" in the entry "AirMyPC/2.0;xxx" in global.h and rebuild uxplay.
Note that for DNS-SD Service Discovery, Uxplay declares itself to be an AppleTV3,2 (a 32 bit device) with a sourceVersion 220.68; this can also be changed in global.h. UxPlay also works if it declares itself as an AppleTV6,2 with sourceVersion 380.20.1 (an AppleTV 4K 1st gen, introduced 2017, running tvOS 12.2.1), so it does not seem to matter what version UxPlay claims to be.
1.70 2024-10-04 Add support for 4K (h265) video (resolution 3840 x 2160). Fix issue with GStreamer >= 1.24 when client sleeps, then wakes.
1.69 2024-08-09 Internal improvements (eg in -nohold option, identifying GStreamer videosink selected by autovideosink, finding X11 display) in anticipation of future HLS video support. New -nofreeze option to not leave frozen video in place when a network connection is reset. Fixes for GStreamer-1.24.x changes.
1.68 2023-12-31 New simpler (default) method for generating a persistent public key from the server MAC address (which can now be set with the -m option). (The previous method is still available with -key option). New option -reg to maintain a register of pin-authenticated clients. Corrected volume-control: now interprets AirPlay volume range -30dB:0dB as decibel gain attenuation, with new option -db low[:high] for "flat" rescaling of the dB range. Add -taper option for a "tapered" AirPlay volume-control profile.
1.67 2023-11-30 Add support for Apple-style one-time pin authentication of clients with option "-pin": (uses SRP6a authentication protocol and public key persistence). Detection with error message of (currently) unsupported H265 video when requesting high resolution over wired ethernet. Removed rpi* options (which are not valid with new Raspberry Pi model 5, and can be replaced by combinations of other options). Added optional argument "mac" to "-m" option, to specify a replacement MAC address/Device ID. Update llhttp to v. 9.1.3. Add -dacp option for exporting current client DACP info (for remotes).
1.66 2023-09-05 Fix IPV6 support. Add option to restrict clients to those on a list of allowed deviceIDs, or to block connections from clients on a list of blocked deviceIDs. Fix for #207 from @thiccaxe (screen lag in vsync mode after client wakes from sleep).
1.65.3 2023-07-23 Add RPM spec file; add warning if required gstreamer libav feature "avdec_aac" is missing: (this occurs in RPM-based distributions that ship an incomplete FFmpeg for Patent or License reasons, and rely on users installing an externally-supplied complete FFmpeg). Mirror-mode airplay will now work without audio if avdec_aac is missing.
1.65 2023-06-03 Eliminate pair_setup part of connection protocol to allow faster connections with clients (thanks to @shuax #176 for this discovery); to revert, uncomment a line in lib/dnssdint.h. Disconnect from audio device when connection closes, to not block its use by other apps if uxplay is running but not connected. Fix for AirMyPC client (broken since 1.60), so its older non-NTP timestamp protocol works with -vsync. Corrected parsing of configuration file entries that were in quotes.
1.64 2023-04-23 Timestamp-based synchronization of audio and video is now the default in Mirror mode. (Use "-vsync no" to restore previous behavior.) A configuration file can now be used for startup options. Also some internal cleanups and a minor bugfix that fixes #192.
1.63 2023-02-12 Reworked audio-video synchronization, with new options -vsync (for Mirror mode) and -async (for Audio-Only mode, to sync with client video). Option -vsync makes software h264 decoding of streamed videos with option -avdec viable on some recent Raspberry Pi models. Internal change: all times are now processed in nanoseconds units. Removed -ao option introduced in 1.62.
1.62 2023-01-18 Added Audio-only mode time offset -ao x to allow user synchronization of ALAC audio playing on the server with video, song lyrics, etc. playing on the client. x = 5.0 appears to be optimal in many cases. Quality fixes: cleanup in volume changes, timestamps, some bugfixes.
1.61 2022-12-30 Removed -t option (workaround for an Avahi issue, correctly solved by opening network port UDP 5353 in firewall). Remove -g debug flag from CMAKE_CFLAGS. Postpend (instead of prepend) build environment CFLAGS to CMAKE_CFLAGS. Refactor parts of uxplay.cpp
1.60 2022-12-15 Added exit with error message if DNSServiceRegister fails (instead of just stalling). Test for Client's attempt to using unsupported AirPlay 2 "REMOTE CONTROL" protocol (with no timing channel), and exit if this occurs. Reworked metadata processing to correctly parse DMAP header (previous version worked with DMAP messages currently received, but was not correct).
1.59 2022-12-12 remove "ZOOMFIX" compile option and make compilation with X11-dependence the default if X11 development libraries are detected (this now also provides fullscreen mode with a F11 or Alt+Enter key toggle); ZOOMFIX is now automatically applied for GStreamer < 1.20. New cmake option -DNO_X11_DEPS compiles uxplay without X11 dependence. Reworked internal metadata handling. Fix segfault with "-vs 0".
1.58 2022-10-29 Add option "-nohold" that will drop existing connections when a new client connects. Update llhttp to v8.1.0.
1.57 2022-10-09 Minor fixes: (fix coredump on AUR on "stop mirroring", occurs when compiled with AUR CFLAGS -DFORTIFY_SOURCE); graceful exit when required plugins are missing; improved support for builds on Windows. Include audioresample in GStreamer audio pipeline.
1.56 2022-09-01 Added support for building and running UxPlay-1.56 on Windows (no changes to Unix (Linux, *BSD, macOS) codebase.)
1.56 2022-07-30 Remove -bt709 from -rpi, -rpiwl, -rpifb as GStreamer is now fixed.
1.55 2022-07-04 Remove the bt709 fix from -v4l2 and create a new -bt709 option (previous "-v4l2" is now "-v4l2 -bt709"). This allows the currently-required -bt709 option to be used on its own on RPi without -v4l2 (sometimes this give better results).
1.54 2022-06-25 Add support for "Cover Art" display in Audio-only (ALAC) mode. Reverted a change that caused VAAPI to crash with AMD POLARIS graphics cards. Minor internal changes to plist code and uxplay option parsing.
1.53 2022-06-13 Internal changes to audio sync code, revised documentation, Minor bugfix (fix assertion crash when resent audio packets are empty).
1.52 2022-05-05 Cleaned up initial audio sync code, and reformatted streaming debug output (readable aligned timestamps with decimal points in seconds). Eliminate memory leaks (found by valgrind). Support for display of ALAC (audio-only) metadata (soundtrack artist names, titles etc.) in the uxplay terminal.
1.51 2022-04-24 Reworked options forVideo4Linux2 support (new option -v4l2) and short options -rpi, -rpifb, -rpiwl as synonyms for -v4l2, -v4l2 -vs kmssink, and -v4l2 -vs waylandsink. Reverted a change from 1.48 that broke reconnection after "Stop Mirroring" is sent by client.
1.50 2022-04-22 Added -fs fullscreen option (for Wayland or VAAPI plugins only), Changed -rpi to be for framebuffer ("lite") RPi systems and added -rpigl (OpenGL) and -rpiwl (Wayland) options for RPi Desktop systems. Also modified timestamps from "DTS" to "PTS" for latency improvement, plus internal cleanups.
1.49 2022-03-28 Addded options for dumping video and/or audio to file, for debugging, etc. h264 PPS/SPS NALU's are shown with -d. Fixed video-not-working for M1 Mac clients.
1.48 2022-03-11 Made the GStreamer video pipeline fully configurable, for use with hardware h264 decoding. Support for Raspberry Pi.
1.47 2022-02-05 Added -FPSdata option to display (in the terminal) regular reports sent by the client about video streaming performance. Internal cleanups of processing of video packets received from the client. Added -reset n option to reset the connection after n ntp timeouts (also reset after "connection reset by peer" error in video stream).
1.46 2022-01-20 Restore pre-1.44 behavior (1.44 may have broken hardware acceleration): once again use decodebin in the video pipeline; introduce new option "-avdec" to force software h264 decoding by libav h264, if needed (to prevent selection of vaapisink by autovideosink). Update llhttp to v6.0.6. UxPlay now reports itself as AppleTV3,2. Restrict connections to one client at a time (second client must now wait for first client to disconnect).
1.45 2022-01-10 New behavior: close video window when client requests "stop mirroring". (A new "no close" option "-nc" is added for users who wish to retain previous behavior that does not close the video window).
1.44 2021-12-13 Omit hash of aeskey with ecdh_secret for an AirMyPC client; make an internal rearrangement of where this hash is done. Fully report all initial communications between client and server in -d debug mode. Replace decodebin in GStreamer video pipeline by h264-specific elements.
1.43 2021-12-07 Various internal changes, such as tests for successful decryption, uniform treatment of informational/debug messages, etc., updated README.
1.42 2021-11-20 Fix MAC detection to work with modern Linux interface naming practices, MacOS and *BSD.
1.41 2021-11-11 Further cleanups of multiple audio format support (internal changes, separated RAOP and GStreamer audio/video startup)
1.40 2021-11-09 Cleanup segfault in ALAC support, manpage location fix, show request Plists in debug mode.
1.39 2021-11-06 Added support for Apple Lossless (ALAC) audio streams.
1.38 2021-10-8 Add -as audiosink option to allow user to choose the GStreamer audiosink.
1.37 2021-09-29 Append "@hostname" to AirPlay Server name, where "hostname" is the name of the server running uxplay (reworked change in 1.36).
1.36 2021-09-29 Implemented suggestion (by @mrbesen and @PetrusZ) to use hostname of machine runing uxplay as the default server name
1.35.1 2021-09-28 Added the -vs 0 option for streaming audio, but not displaying video.
1.35 2021-09-10 now uses a GLib MainLoop, and builds on macOS (tested on Intel Mac, 10.15 ). New option -t timeout for relaunching server if no connections were active in previous timeout seconds (to renew Bonjour registration).
1.341 2021-09-04 fixed: render logger was not being destroyed by stop_server()
1.34 2021-08-27 Fixed "ZOOMFIX": the X11 window name fix was only being made the first time the GStreamer window was created by uxplay, and not if the server was relaunched after the GStreamer window was closed, with uxplay still running. Corrected in v. 1.34
If you need to do this, note that you may be able to use a newer version (OpenSSL-3.0.1 is known to work). You will need the standard development toolset (autoconf, automake, libtool). Download the source code from https://www.openssl.org/source/. Install the downloaded openssl by opening a terminal in your Downloads directory, and unpacking the source distribution: ("tar -xvzf openssl-3.0.1.tar.gz ; cd openssl-3.0.1"). Then build/install with "./config ; make ; sudo make install_dev". This will typically install the needed library libcrypto.* , either in /usr/local/lib or /usr/local/lib64.
(Ignore the following for builds on MacOS:) On some systems like Debian or Ubuntu, you may also need to add a missing entry /usr/local/lib64 in /etc/ld.so.conf (or place a file containing "/usr/local/lib64/libcrypto.so" in /etc/ld.so.conf.d) and then run "sudo ldconfig".
(Note: on Debian 9 "Stretch" or Ubuntu 16.04 LTS editions, you can avoid this step by installing libplist-dev and libplist3 from Debian 10 or Ubuntu 18.04.) As well as the usual build tools (autoconf, automake, libtool), you may need to also install some libpython*-dev package. Download the latest source with git from https://github.com/libimobiledevice/libplist, or get the source from the Releases section (use the *.tar.bz2 release, not the *.zip or *.tar.gz versions): download libplist-2.3.0, then unpack it ("tar -xvjf libplist-2.3.0.tar.bz2 ; cd libplist-2.3.0"), and build/install it: ("./configure ; make ; sudo make install"). This will probably install libplist-2.0.* in /usr/local/lib. The new libplist-2.3.0 release should be compatible with UxPlay; libplist-2.2.0 is also available if there are any issues.
(Ignore the following for builds on MacOS:) On some systems like Debian or Ubuntu, you may also need to add a missing entry /usr/local/lib in /etc/ld.so.conf (or place a file containing "/usr/local/lib/libplist-2.0.so" in /etc/ld.so.conf.d) and then run "sudo ldconfig".
All the resources in this repository are written using only freely available information from the internet. The code and related resources are meant for educational purposes only. It is the responsibility of the user to make sure all local laws are adhered to.
This project makes use of a third-party GPL library for handling FairPlay. The legal status of that library is unclear. Should you be a representative of Apple and have any objections against the legality of the library and its use in this project, please contact the developers and the appropriate steps will be taken.
Given the large number of third-party AirPlay receivers (mostly closed-source) available for purchase, it is our understanding that an open source implementation of the same functionality wouldn't violate any of Apple's rights either.
[adapted from fdraschbacher's notes on RPiPlay antecedents]
The code in this repository accumulated from various sources over time. Here is an attempt at listing the various authors and the components they created:
UxPlay was initially created by antimof from RPiPlay, by replacing its Raspberry-Pi-adapted OpenMAX video and audio rendering system with GStreamer rendering for desktop Linux systems; the antimof work on code in renderers/ was later backported to RPiPlay, and the antimof project became dormant, but was later revived at the current GitHub site to serve a wider community of users.
The previous authors of code included in UxPlay by inheritance from RPiPlay include:
lib/playfair folder. License: GNU GPLlib/ originally stems from this project. License: GNU LGPLv2.1+lib/ concerning mirroring is dsafa22's work. License: GNU LGPLv2.1+Independent of UxPlay, but used by it and bundled with it:
lib/llhttp/ . License: MIT
