Latência e desempenho

Cerca de 60 ms da câmera até o OBS por USB, em 1080p ou 4K; no Wi-Fi é mais alta e mais variável. O valor é medido continuamente, não estimado, e aparece no campo Status, na barra de status e no log.

De onde vem o atraso#

Etapa	Aproximadamente	Observações
Captura e exposição	Um quadro	Cenas mais claras expõem mais rápido, e a diferença aparece aqui.
Codificação por hardware	Alguns ms	VideoToolbox. Nada para ajustar.
O link	USB: pequena, estável. Wi-Fi: variável	A etapa que separa uma configuração boa de uma frustrante.
Decodificação	Alguns ms	GPU por padrão, com retorno automático ao software.
Até a sua cena	Menos de um milissegundo no pipeline de GPU	Fora dele, uma cópia para fora da memória da GPU e de volta.

Reduzindo o atraso#

Use USB. É o mais consistente, imune ao congestionamento do Wi-Fi, e ainda carrega o celular.
Ilumine a cena. Um ambiente escuro alonga a exposição, e isso cai direto no orçamento de latência.
Mantenha os padrões ativados. O modo de baixa latência e a decodificação por hardware já vêm ativados.
Não exagere nas especificações. Se o enquadramento é uma pessoa falando que ocupa 1000 px de largura na sua cena, 1080p não é uma concessão.
Use a teleobjetiva em vez de muito zoom digital. Vídeo com zoom e ruído comprime mal, o que aparece como picos de taxa de bits e de latência.

Congestionamento é descartado, não enfileirado. Quando o link trava, o LensLink descarta quadros e reduz a qualidade por um momento em vez de acumular atraso, então a latência fica estável em vez de ir subindo ao longo da transmissão.

Acompanhando os números#

Barra de status do OBS: LensLink: iPhone 60 fps · 11.9 Mb/s · 43 ms, uma entrada por fonte ao vivo.
O painel do LensLink (Visualizar → Painéis): uma linha por fonte.
No celular: Estatísticas, no menu de status da tela Ao vivo, mostra a mesma linha. Com Imagem limpa como tela de repouso, ela continua visível de propósito quando os controles somem.
O campo Status mostra a latência medida da captura à decodificação enquanto conectado.

O valor é real: uma troca de diferença de relógio no estilo NTP roda uma vez por segundo, e é ela também que torna possível a sincronia labial automática.

O pipeline de decodificação na GPU (beta)#

Normalmente, cada quadro decodificado é baixado da GPU para a memória do sistema, entregue ao OBS e enviado de volta na mesma hora para a composição: cerca de 2 GB/s de pixels em 4K60, para nada. O pipeline beta entrega o quadro ao OBS como textura e pula essa ida e volta.

Ferramentas → Configurações do LensLink. Todas as fontes mudam juntas, depois de reiniciar o OBS.

Resultados medidos#

Doze configurações, ~25 s de vídeo ao vivo cada, mesmo PC e mesmo celular por Wi-Fi. As cópias de pixels marcaram 0,00 MB/s em todas as execuções com o pipeline de GPU.

Configuração	Custo por quadro (ms)	Cópias de pixels (MB/s)	CPU do OBS
720p 60 HEVC	0,81 → 0,09	163 → 0	2,2% → 1,4%
1080p 60 H.264	2,11 → 0,10	370 → 0	2,3% → 1,6%
1080p 60 HEVC	1,42 → 0,09	373 → 0	2,6% → 1,4%
4K 30 HEVC	4,96 → 0,14	721 → 0	2,9% → 1,5%
4K 60 H.264	7,54 → 0,10	1221 → 0	4,1% → 1,8%
4K 60 HEVC	4,75 → 0,10	1439 → 0	4,1% → 1,6%

O custo por quadro cai de 89% a 99%, e o ganho cresce com a resolução: em 4K60 HEVC, o pipeline padrão passava cerca de 1,4 GB/s pela memória do sistema, o que este elimina por completo, reduzindo mais ou menos pela metade o uso de CPU do processo do OBS. A latência e a taxa de quadros não mostraram diferença sistemática: elas são determinadas pela rede e pelo codificador do celular, não pelo caminho de renderização.

Observações por plataforma#

Windows	Qualquer sistema suportado pelo OBS 32 (Windows 10 1909+), usando texturas D3D11 compartilhadas.
macOS	Qualquer sistema suportado pelo OBS 32 (macOS 13+), via IOSurface. Os fluxos de 10 bits são a exceção: o próprio VideoToolbox os converte para 8 bits, então HDR e Apple Log são renderizados pelo caminho padrão, e não por este.
Linux	Requer o OBS em EGL (o padrão no Wayland e nas versões atuais para X11) e um driver VAAPI, já incluído no Mesa para Intel e AMD; a NVIDIA precisa do `nvidia-vaapi-driver`.
Várias GPUs	Decodificar e renderizar em GPUs diferentes impede o compartilhamento de texturas; a fonte volta ao caminho padrão automaticamente.

O retorno ao caminho padrão é por fonte e automático: o pior caso é exatamente o pipeline padrão, com uma linha no log explicando o motivo.

A marca da GPU importa?#

Menos do que o sistema operacional. A decodificação é um bloco de função fixa em toda GPU moderna, e o plugin a solicita pela API da própria plataforma, e não por algo específico de um fabricante.

Windows	Independente de fabricante. D3D11VA em qualquer GPU atual, DXVA2 como alternativa.
macOS	VideoToolbox, tanto em Macs com Apple silicon quanto com Intel.
Linux, Intel ou AMD	O VAAPI já vem no Mesa: nada para instalar.
Linux, NVIDIA	Requer o `nvidia-vaapi-driver`; o VDPAU é a alternativa. Este é o único caso em que a marca decide se o pipeline de GPU entra em ação ou não.
Notebooks com duas GPUs	Se a decodificação cai em uma e o OBS renderiza na outra, as texturas não podem ser compartilhadas e a fonte volta ao caminho padrão sozinha.
GPUs mais antigas	Uma GPU sem decodificador HEVC Main10 usa decodificação por software para fluxos de 10 bits; os de 8 bits não são afetados.

Vários celulares ao mesmo tempo é uma carga de decodificação, não de codificação. O limite da NVIDIA de sessões NVENC simultâneas não se aplica: nada aqui é codificado no computador. O que limita você é a capacidade de decodificação e a largura de banda da memória, que é exatamente o que o pipeline de GPU economiza.

As medições acima vêm de uma única máquina Windows com placa NVIDIA. O pipeline está em beta em parte porque as outras combinações (IOSurface no macOS, VAAPI do Mesa, nvidia-vaapi-driver e o retorno ao padrão com várias GPUs) precisam mais de relatos de uso real do que de mais código.

Medindo você mesmo#

Ferramentas → Configurações do LensLink → Registrar benchmark do pipeline grava uma linha CSV por segundo na pasta de configuração do plugin (o caminho aparece no log), além de um resumo a cada cinco segundos. Transmita dez segundos em cada configuração e depois compare um par:

python3 tools/bench-report.py BEFORE.csv AFTER.csv

Espera-se que qualquer mudança de desempenho proposta ao LensLink cite um desses resultados.