[WIP: work in progress - esta publicação pode ser acrescida sem aviso prévio]
OBS-Studio: https://github.com/obsproject/obs-studio/releases, mirror
as versões instaláveis não são necessárias e não apresentam vantagens sobre as versões standalone / portable. ainda, usar programas através de conta de usuário padrão ou limitado é mais seguro que utilizar os mesmos programas em modo administrador. por fim, sugiro utilizar versões zips (standalone, sem instalador e, logo, sem desinstalador) e, assim, quando não quiser mais usar o programa apenas delete sua pasta. sem necessidade de passos adicionais.
OBS-Studio docs - wiki: https://obsproject.com/wiki/
OBS-Studio docs - help guide: https://obsproject.com/forum/...pdf.365/
FFmpeg - help guide: https://ffmpeg.org/...html, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
FFmpeg - alternative guide: https://superuser.com/..., ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
Youtube - streaming guide: https://support.google.com/...6136989, ?, ?, ?, ?, ?
Twitch - streaming guide: https://stream.twitch.tv/encoding/, ?, ?
DLive - streaming guide: https://help.dlive.tv/hc/en-us/articles/...DLive, ?
Facebook - streaming guide: https://www.facebook.com/...6955, ?, ?
Restream - streaming guide: https://support.restream.io/en/...restream, ?
NVIDIA - streaming guide: https://www.nvidia.com/en-us/...guide/, ?
AMD - streaming guide: https://www.amd.com/en/.../dh-023, ?, ?, ?
Intel - streaming guide: https://www.intel.com/content/.../how-to-stream.html, ?
este guia deve estar atualizado para o uso até da versão 26.0.0 do OBS-Studio e até a data de 2020/09/17 em relação às configurações. versões futuras do obs-studio podem apresentar comportamentos diferentes e documentações oficiais podem sugerir configurações diversas em datas futuras.
antes de começar a usar qualquer programa de streaming é bom saber pelo menos os nomes ou as descrições dos componentes básicos do seu equipamento (como CPU, RAM, GPU, VRAM*, quantidade de monitores em uso e resoluções nativas de cada um), o sistema operacional em uso, além de realizar testes de velocidade de internet.
* VRAM diz respeito à memória presente na placa de vídeo, VideoRAM;
[ferramentas de suporte]
hardware em geral: HWiNFO, Speccy, "lspci"¹, "sudo lshw"¹
cpu: CPU-Z, "cat /proc/cpuinfo"¹, "sudo dmidecode --type processor"¹
gpu: GPU-Z, GPU Caps Viewer, GPU Shark, BltTest
velocidade de internet: EAQ, SpeedTest, SIMET, cloudflare, TwitchTest, ?, ?
uso de recursos: AfterBurner, MangoHUD¹, ProcessExplorer, SystemInformer
¹ linux only;
conhecer a capacidade do próprio equipamento e a velocidade do upload* nos ajudam a tomar melhores decisões na configuração do programa de streaming.
* a velocidade do download não tem relevância neste guia;
[stats / estatística]
a ferramenta mais importante em todo OBS-Studio é janela de estatística. a compreensão de seus resultados permite ao usuário a descobrir sozinho tudo que será apresentado aqui.
à rigor, apenas monitorando o impacto das configurações escolhidas sobre a janela de estatística durante testes, o usuário irá descobrir também como resolver a imensa maioria dos problemas que esteja sofrendo. não tente "adivinhar" o problema. leia a janela de estatística.
OBS-Studio > View > Docs > Stats
OBS-Studio > View > Stats
o processamento de quadros é apresentado através de uma fração na qual o numerador representa a perda de quadros (dropped frames) - se houver -, e o numerador, os quadros capturados no período.
apenas o primeiro número - a quantidade inteira de quadros perdidos - é relevante para nossa análise porém é preciso levar em consideração a duração completa da transmissão ou pelo menos o intervalo de tempo de nossas observações.
por exemplo, se transmitindo em 60 fps o número de quadros perdidos for de 360 frames num intervalo de 10 segundos, é muito provável que durante pelo menos 6 segundos a transmissão "caiu" para quem estiver assistindo, não importando se a queda tenha ocorrido em transmissão, renderização ou codificação.
porém, se apenas no intervalo de 1 hora os 360 frames perdidos forem atingidos, sendo um quadro perdido a cada 10 segundos, é muito provável que a transmissão seja considerada estável e a perda completamente imperceptível para todos os telespectadores.
mais do que isto, a perda de quadros durante uma transmissão ao vivo é esperada que ocorra - principalmente em computadores menos potentes - ao realizar abertura de novos programas, novas abas de navegação e eventualmente até em telas de loading. tal perda pode ser mitigada aumentando a prioridade do processo do obs-studio em sua configuração avançada. recurso que será abordado posteriormente.
de qualquer maneira, a origem da perda - se causada por renderização, codificação ou transmissão - é a melhor pista para solução dos problemas. e todas elas serão explicadas em momento oportuno.
por fim, durante a utilização do OBS-Studio, a tela de estatística irá "se poluir" com os resultado da captura antiga, e pode eventualmente refletir resultados distintos ao comportamento presente. é possível, porém, zerar os valores apresentados e assim ter uma referência mais clara do comportamento atual ao apertar o botão "reset" (traduzido em português como "redefinir").
[settings advanced]
OBS-Studio > settings > advanced > priority > normal
entenda prioridade de processo como uma fila de pessoas na agência lotérica. aumentar a prioridade de um processo é como fazer idosos serem atendidos primeiros. aumentar a prioridade para idosos não impacta na quantidade de pessoas atendidas (tamanho da fila / uso do processador), apenas muda o ordenamento desta mesma fila.
aumentar a prioridade de um processo não aumenta a carga de processamento. muda apenas quem irá utilizar o recurso escasso do tempo de execução do processador (cpu) primeiro.
via de regra usar prioridade "normal" ou "acima do normal" são seguros e sem impactos negativos. as demais opções, porém, não são recomendadas e eventualmente até prejudiciais.
"acima do normal" pode favorecer principalmente equipamentos pouco potentes a manterem a transmissão e captura mesmo durante períodos de alto uso da cpu por outros processos de menor prioridade. em cenários assim, bastante limitados, aumentar a prioridade do processo do OBS-Studio pela configuração do programa e aumentar a prioridade do processo do jogo - de modo manual ou através de scripts - pode ajudar a diminuir a quantidade de quadros perdidos e tornar a transmissão ao vivo mais estável.
infelizmente, o Windows 10 não permite a elevação manual de prioridade para todas aplicações. porém, tal efeito já é feito de modo implícito através da ativação do "game mode". o recurso - game mode -. além de elevar a prioridade de aplicações consideradas de jogos ou multimídia, aumenta o consumo de energia elétrica geral do sistema ao forçar de modo implícito o uso do perfil elétrico de "alta performance", desativa a instalação de updates em segundo plano e também diminui a prioridade das demais aplicações enquanto "um jogo" estiver aberto.
este último passo produzido pelo "game mode" do Windows 10 pode impactar na captura do OBS-Studio pelo fato do Windows não reconhecer o OBS-Studio como prioritário durante a execução de um jogo, e como "workaround" a NVIDIA recomenda utilizar OBS-Studio como administrador.
entenda que isto é mau uso da função administrativa. uma solução paliativa ou "gambiarra" ("workaround") e não uma solução definitiva. espera-se que eventualmente o comportamento indesejado seja definitivamente resolvido. enquanto isto, caso o usuário esteja utilizando Windows 10 com "game mode" ativo e tiver quedas de captura apesar de utilizar configurações adequadas ao hardware e à carga, o uso do OBS-Studio como administrador pode resolver o problema.
de qualquer modo, como já dito, é melhor evitar o uso de programas executados como administrador como uma forma de garantir a segurança e a preservação do comportamento original do sistema.
por fim, entenda que "executar como administrador" tem relação com privilégio de acesso, ou seja, a capacidade de utilizar recursos protegidos do sistema - e não tem relação com prioridade de processo, que diz respeito à fila de execução. dito isto, aplicativos executados como administrador (como é o caso de muitos jogos antigos que não funcionam se abertos de outro modo) só podem ser capturados por processos com o mesmo privilégio administrativo. e neste caso o OBS-Studio precisará ser executado "como administrador" para conseguir capturar a imagem da aplicação executada com privilégio administrativo.
info: https://docs.microsoft.com/.../win32/procthread/scheduling-priorities
info: https://www.tenforums.com/...windows-10-a.html
info: https://support.microsoft.com/...game-mode-on-your-pc
OBS-Studio > settings > advanced > color format > nv12
é o padrão, é recomendado, e com o melhor desempenho.
OBS-Studio > settings > advanced > color space > 709
"709" apresenta - pelo menos pra mim - um conjunto de cores mais vivas e pode ser aplicado também a capturas de câmeras. de qualquer forma, foi anunciado que este será o espaço de cor padrão das futuras versões do OBS-Studio - saiba também que "709" é o padrão da indústria para transmissões HD (720p+) ou superiores.
do outro lado, "601" é padrão da indústria para conteúdo SD (standard definition, 480p ou menos). porém, mesmo em resoluções menores ainda recomendo o uso de 709, já que não impacta na performance, apenas muda as cores utilizadas na confecção dos frames e produz um resultado mais "vivo".
info: https://en.wikipedia.org/wiki/Rec._601
info: https://en.wikipedia.org/wiki/Rec._709
info: https://en.wikipedia.org/wiki/SRGB
OBS-Studio > settings > advanced > color range > partial
use sempre o intervalo limitado "partial" para melhor qualidade de imagem e maior compactação.
settings > advanced > enable browser source hardware acceleration
as animações multimídias presentes nas capturas de navegador ("browser source") podem ser processadas (o termo "acelerada" como sinônimo de "local de processamento" é comumente utilizado também) por CPU ou GPU. por padrão, elas são aceleradas por GPU e na maioria dos casos é a opção adequada.
porém, usuários de computadores mais antigos com placa de vídeo integrada podem não possuir potência suficiente para a função e assim serem obrigados a utilizar aceleração por cpu, logo, desativando o recurso.
OBS-Studio > settings > audio > sample rate > 48 kHz
OBS-Studio > settings > audio > desktop audio > default
OBS-Studio > settings > audio > mic audio > default
a maioria das placas de som dos computadores atuais utilizam por padrão uma taxa de amostragem ("sample rate") de 48 kHz. e, ainda que seja marginal, é melhor do ponto de vista da preservação da qualidade e de algum processamento - ainda que mínimo - manter a taxa de amostragem em 48 kHz, assim como manter as capturas nativas de desktop e microfone.
vários usuários, porém, preferem se aventurar por rotas diversas, desativando as capturas nativas e adicionando capturas de áudio manuais, por cena, e até fazendo uso de programas como Virtual Audio Cable, Voicemeeter, Banana, etc.
entenda que tais configurações aumentam a manutenção e complexidade do sistema e em computadores pouco potentes adicionam algum processamento sem normalmente ofereceram alguma vantagem na função, visto que o usuário tende ao longo do tempo a re-criar exatamente o que já era oferecido através das opções nativas.
dito isto, só gostaria de evidenciar que não tenho qualquer interesse ou intenção de produzir guias de áudio, muito menos com a adição de mesa de sons digitais, etc. tal assunto não será abordado aqui.
OBS-Studio > settings > video > base (canvas) resolution > 1920x1080
OBS-Studio > settings > video > output (scaled) resolution > 1920x1080
OBS-Studio > settings > video > downscale filter > bilinear
OBS-Studio > settings > video > common fps values > 30
provavelmente a tela do OBS-Studio mais confusa antes da próxima para os novatos em transmissão online e provavelmente porque novatos não entendem claramente o que seja resolução.
pense inicialmente a resolução como a quantidade de peças de um quebra-cabeça mas com sua quantidade descrita através de uma multiplicação ao invés de um valor inteiro simples. assim um quebra-cabeça de 9 peças pode ter a resolução de 3x3, enquanto um quebra-cabeças de 900 peças pode ter uma resolução de 30x30.
não é difícil de perceber que um tabuleiro de 9 peças é muito mais simples, ocupa menos espaço, e é muito mais rápido de se construir que um tabuleiro de 900 ou 9.000 peças. e o mesmo comportamento é observado em relação aos pixels. resoluções maiores permitem imagens mais complexas ao custo de ocuparem mais ram, vram, espaço em disco, banda em barramento e custo de processamento.
espero que tenha ficado clara nossa primeira limitação: quanto mais potente é um equipamento, maiores resoluções ele é capaz de trabalhar. e, do outro lado, quanto mais modesto é um equipamento, menores resoluções ele é capaz de lidar.
tenha em mente que estamos introduzindo uma nova carga à carga de processamento já existente no equipamento ao adicionarmos as tarefas de captura, aplicação de filtros, rotina de renderização, codificação em h.264 e transmissão via rede. e assim dependendo da capacidade do hardware, a resolução original pode ser fator um limitante durante transmissões ao vivo e independente do programa de transmissão escolhido.
a princípio poderia-se recomendar um "canvas" (tela de resolução base) do mesmo tamanho da resolução nativa do monitor. tal cenário é realizável em hardware novo e potente. entretanto, em hardware menos potente, é melhor que se utilize configurações mais modestas nos jogos e assim que o "canvas" tenha o mesmo tamanho da resolução em uso na aplicação principal.
testes precisarão ser feitos até que se encontre uma resolução menor que a resolução nativa do monitor que una fluidez de gameplay e conforto visual para o usuário. por exemplo, ao invés de executar jogos em 1920x1080, experimente os mesmos jogos em 1600x900, 1440x810, 1280x720, 1024x576 960x540. ao encontrar a resolução ideal, use-a como valor de "canvas".
ao ter um "canvas" do mesmo tamanho da aplicação principal, nenhum redimensionamento é aplicado na imagem durante processo de captura. e isto significa (a) fidelidade de imagem, sem adição de artefatos visuais como efeito colateral do uso de redimensionamento e (b) impacto mínimo na performance da aplicação por não estar adicionando processamento de redimensionamento desnecessário.
falamos do "canvas", logo, do custo de composição da imagem ou renderização inicial da mesma. falaremos agora da resolução de saída, a qual poderá ser redimensionada ou não - o que impactará no custo da renderização final - e sua resolução impactará no nosso encoder.
caso o usuário decida utilizar em resolução de saída as mesmas dimensões presentes no "canvas" novamente pouparemos processamento de redimensionamento e preservaremos fidelidade de imagem. do ponto de vista dos custos envolvendo as atividades de renderização é uma cenário win-win utilizar canvas e saída com valores idênticos. nesta situação não há redução de imagem de "canvas" para "saída" e portanto o filtro de redução não é utilizado.
neste caso, a escolha de qualquer filtro de redução não produzirá nenhum efeito pois ele está sendo completamente ignorado. infelizmente, muitas vezes não se tem potência suficiente para codificar quadros tão grandes quanto os presentes no "canvas" e assim resoluções de saída menores precisarão ser utilizadas, o que forçará o uso de um filtro de redução.
o OBS-Studio conta com 4 filtros de redução, e diria que em qualidade todos os 4 são bastante satisfatórios. recomendo fazer uso do filtro bilinear - principalmente em reduções inteiras como de 1920x1080 para 960x540 ou de 1280x720 para 640x360 - e comparar com as demais opções em um teste cego para perder o medo de usá-lo. ele é significativamente mais leve que os demais, sem normalmente prejudicar a nitidez de imagem. o filtro área também é uma boa opção para quem tem um pouco de gpu livre.
como curiosidade, o filtro lanczos é padrão da industria, utilizado no cinema, porém, eu acredito que ele brilhe durante tarefas de "upscaling" (ampliações), cenário que não é comum durante transmissões ao vivo. em "downscaling" (reduções) muitas vezes os resultados dos filtros não são tão distintos na imagem final apesar da grande diferença de consumo de recursos para realização da redução.
por fim, temos a opção de framerate. voltando à analogia do quebra-cabeça, se um quebra-cabeça de 3x3 é mais leve que um quebra-cabeça de 30x30. montar 30 quebra-cabeças por minuto é mais fácil que montar 60 quebra-cabeças por minuto.
e assim usar um framerate mais baixo irá produzir menor impacto no gameplay, menor impacto na renderização e menor impacto na codificação. a diminuição do framerate também ajuda a aumentar a nitidez de imagem ao custo, porém, da diminuição da fluidez do vídeo.
OBS-Studio > settings > output > output mode > advanced
OBS-Studio > settings > output > keyframe > 2
OBS-Studio > settings > output > profile > high
recomendo fortemente 3 coisas: (a) usar o modo avançado de opções do encoder, (b) desativar a opção "enforce streaming service encoder settings" e (c) desativar a opção "rescale output".
(a) usaremos o modo avançado pois o intuito do guia é tonar o usuário apto a fazer as melhores decisões diante das limitações nas quais se encontra;
(b) desativaremos a opção para termos certeza que nossas decisões estão sendo utilizadas;
(c) não utilizaremos o re-escalamento de imagem no encoder, pois tal tarefa já está sendo utilizada pela GPU como parte da renderização final de cada quadro. há sim cenários no qual o escalamento no encoder faz sentido, mas muito raramente eles ocorrem. de modo geral, esta tarefa é melhor executada na fase de renderização pela GPU.
ao invés de simplesmente apresentar uma tabela de valores, pretendo dar uma visão geral do fenômeno da compactação multimídia, e assim através de um pouco de prática e testes qualquer um será capaz de otimizar a própria laive.
vamos brincar de pintar feijões!
caso tenha-se 10 feijões, e cada um tenha uma cor diferente... na brincadeira poderia-se dizer:
"o primeiro feijão será amarelo, o segundo será azul, o terceiro será verde, o quarto será preto, o quinto será rosa, o sexto será laranja, o sétimo será branco, o oitavo será cinza, o nono será marrom e o décimo será lilás.".
é preciso ser bastante verboso para explicar a cor de cada feijão. porém, se todos forem da mesma cor, basta que se diga:
"todos feijões serão brancos".
se consideramos que as descrições de cores de feijões são instruções de computador, facilmente se percebe que quanto menor o número de cores apresentadas, menos instruções são necessárias para descrever. logo, quanto menor o número de cores, maior é a compactação sobre as instruções.
do mesmo modo, quanto menor o número de feijões, potencialmente menor será o conjunto de instruções para pinturas, potencialmente maior será a compactação da instruções.
do mesmo modo que durante a explicação anterior reduzimos as duas dimensões (x e y) de uma imagem para uma única dimensão, transformando-as numa longa sequência de cores de feijão, podemos fazer a mesma operação mental sobre a dimensão temporal e dizermos que quanto menor a variação de cor entre quadros de feijão, menos instruções são necessárias para representar as transformações ao longo do tempo. logo, quanto menor o número de quadros (fps) e quanto mais parecidos sãos os quadros entre si, mais fácil é compactar as instruções.
espero que tenha ficado claro: diminuir a resolução, diminuir a quantidade de cores, diminuir a variação de conteúdo entre cada quadro e diminuir a quantidade de quadros por segundo, tudo isso favorece à compactação. logo, demanda menos processamento e menos banda de internet.
entenda, pessoas em frente de câmeras passam a maior parte do tempo movimentando apenas o rosto, o que representa uma variação de quadro a quadro muito pequena. logo, precisa-se de pouco bitrate (kbps) e pouco processamento (baixo custo de compactação).
do outro lado, jogos com movimentação rápida, com a presença de movimentação independente de múltiplos objetos, com muitas cores num mesmo quadro ou com a variação rápida de cores entre múltiplos quadros, como é o caso de filmagens de chuva, nevasca ou queda de confetes, tudo isso, aumenta a complexidade das imagens, e demanda muito bitrate (alto kbps) e muita compactação (alto processamento).
assim, configurações satisfatórias em testes de transmissão fazendo uso de jogos retrôs (baixa resolução) ou em modelo entrevista com a mera aparição de 1 ou 2 pessoas na maior parte do tempo imóveis podem não ser adequadas para imagens de alta resolução e alta movimentação dos jogos novos.
entenda porém que tais cenários podem mudar durante uma mesma transmissão, e assim quando alguém no chat disser que a imagem está muito "borrada/pixelizada" durante o gameplay, o streamer tende a parar, pausar o jogo, olhar a transmissão (mudando portanto o comportamento da captura) e se vê convencido de que a imagem estava boa, sem perceber que ninguém reclamou de imagem parada, com o jogo pausado, mas sim durante alta movimentação em momento que o streamer não tem condições de analisar a qualidade da transmissão senão posteriormente revendo o vídeo gravado.
do ponto de vista das opções disponíveis na janela de encoder para preservação de fidelidade de imagem em transmissões online temos apenas duas opções: uso de processamento e uso de banda.
pode-se dizer que quanto maior o uso de processamento e maior o uso de banda, maior é a fidelidade de imagem. porém, isto é verdade somente até um ponto, no qual chamamos de limite de transparência ("transparency threshold"). ou dito de outra forma, só é preciso compactar uma imagem ou consumir banda até um determinado ponto, o qual se ultrapassado representa apenas desperdício de recursos sem qualquer vantagem ou variação na qualidade de modo perceptível aos telespectadores.
dito isto, é preciso que fique claro que as recomendações oficiais de bitrate e grau de compactação das grandes plataformas são completamente adequadas para a imensa maioria das transmissões. não sendo necessário aumentar o bitrate ou a compactação na quase totalidade dos casos.
os valores sugeridos em tais plataformas só serão "desobedecidos" quando não for possível realizá-los. e assim, caso o usuário não tenha upload suficiente, ele precisará aumentar a compactação. e do outro lado, quando o usuário não tenha processamento suficiente, ele precisará aumentar o bitrate.
terão casos nos quais o usuário não tem upload suficiente e nem poder de compactação. nestes casos é preciso diminuir a resolução de saída até que se encontre um valor compatível com o hardware e com a contratação do provedor.
em relação ao bitrate, recomendo não utilizar mais do que 50% da banda testada do upload. e ainda que o valor seja um pouco menor que as sugestões das documentações oficiais que variam de 60 a 80%, ao trabalhar com folga tem-se ganho em estabilidade. evite usar wifi, use rede cabeada, e não terá problemas.
em relação à compactação, é preciso mais alguns esclarecimentos. as opções oferecidas pela interface do OBS-Studio já são uma simplificação dos parâmetros de compactação através de 2 opções: profile e preset.
ao invés de escrever os parâmetros assim: "cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=1 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00" o usuário apenas seleciona a opção "preset: veryfast".
ao escolher "preset: fast", o usuário é poupado de ter que escrever: "cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=1 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00"
não espero que o usuário compreenda todos os parâmetros, apenas que tenha algum entendimento sobre o que acontece ao mudar as opções de preset. parâmetros de compactação salvos em categorias pré-definidas ("presets") são utilizados de acordo com a escolha do usuário.
o interessante é que a lista oferecida tem duas características: ela é ordenada da pior à melhor em relação à preservação de fidelidade de imagem, e coincidentemente ordenada do menor ao maior custo de processamento. de "ultrafast" (baixíssima compactação, "muito leve", baixa fidelidade) para "veryslow" (altíssima compactação, "muito pesado", alta fidelidade).
como curiosidade, a opção "placebo" não tem vantagem real e nem utilidade fora dos testes dos próprios programadores do encoder. de qualquer modo, dificilmente um usuário precisará escolher uma compactação maior que medium, e ao mesmo tempo dificilmente o usuário terá bons resultados com compactações menores que veryfast.
como regra básica: tente usar "veryfast", "faster" ou "fast". uma destas três compactações utilizando o bitrate recomendado pela plataforma deve lhe oferecer imagem adequada. e caso não tenha potência necessária, opte por reduzir a resolução de saída.
caso a codificação esteja adequada, pode-se ter boa definição de imagem até em resoluções baixas como 360p. no caso da twitch, algumas resoluções intermediárias podem ser utilizadas, e usuários com dificuldade em manter, por exemplo, 720p na saída, podem fazer uso de 576 ou 540p sem qualquer degradação significativa na definição da imagem. poupa-se processamento e muitos vezes aumenta-se a definição assim.
por fim, existem as opções de profile: "baseline", "main" e "high". e elas representam limitações impostas sobre o preset escolhido. enquanto "high" faz uso completo de todas as estratégias de compactação em uso do preset, "main" visa produzir stream compatíveis com dispositivos clientes mais antigos, enquanto "baseline" tenta produzir stream compatíveis com os primeiros smartphones do mercado. assim, usar "main" ou "baseline" ao invés de "high" pode produzir imagens menos fieis em cenários de baixa compactação e baixo bitrate.
entenda, porém, como já foi dito, que uma baixa compactação pode ser compensada com elevação do bitrate para preservação da qualidade de imagem.
e assim não necessariamente uma laive que faça uso de preset menor como "superfast" e perfil menor como "main" produzirá menor qualidade de imagem. pois, a qualidade pode ser compensada com elevação do bitrate de transmissão. nestes casos, tente aumentar pelo menos em passos de +500 kbps em relação ao bitrate recomendado oficialmente para obter a qualidade que se espera. sem ultrapassar o limite total de 6.000 kps no caso de transmissões para Twitch.
o preset "ultrafast" e o profile "baseline", os quais são as opções mais leves possíveis mas com baixíssima compactação, eram proibidos em alguns serviços de streaming quando comecei a pesquisar sobre o assunto. porém, com o tempo e com a popularização das transmissões por celular, tais opções passaram a ser tornar aceitas pois são normalmente as únicas opções para smartphones mais modestos.
info: https://trac.ffmpeg.org/wiki/Encode/H.264
info: http://dev.beandog.org/x264_preset_reference.html
até aqui abordamos o uso de encoder "acelerado por software" (expressão sinônima para processamento executado pela CPU) como é o caso do x264. entretanto, tudo que foi dito para o encoder "acelerado por software" vale para os encoders "acelerados por hardware" (expressão para custo de processamento executado por GPU ou circuito dedicado à função), como são os casos para AMD VCE, Intel Quick Sync Video ou NVIDIA NVENC.
curiosamente o x264 é muitas vezes tratado como um encoder de menor qualidade por leigos e novatos, porém, façamos a leitura do seguinte trecho da documentação oficial do OBS-Studio no github:
"Q: Is it possible to achieve x264 quality with this?
It is not possible to be exactly identical to x264, but the AMD Encoder usually has similar quality to x264 superfast. Nvidia's H264 encoder is equal or often beats x264 veryfast, and Intels QSV H264 Encoder is also equal to x264 superfast on Haswell, but may have improved since then. As hardware vendors usually keep this feature locked down we are unlikely to see any improvements from strict open source implemented in their hardware."
source: https://github.com/obsproject/obs-amd-encoder/...this
como se vê para encoders acelerados por hardware com mais de 4 anos de idade, a qualidade de compactação oferecida por eles é compatível com "veryfast" do x264 para o mesmo bitrate. bitrates maiores aumentam a preservação da imagem para qualquer encoder, até o limite de transparência.
NOTA: a nova série 3000 da NVIDIA pode ou não apresentar circuito de codificação melhorado em relação às versões anteriores. aguardarei testes independentes para comentar sobre o assunto. de qualquer forma, espero que as novas versões produzam qualidade compatível com "fast" ou até mesmo "medium" do x264. e se confirmado, será um feito realmente impressionante por parte da NVIDIA!
a grande vantagem, porém, dos encoders acelerados por hardware estão nos dispositivos com a presença de circuito dedicado - como é o caso das versões 2060 ou superiores da NVIDIA. nestas placas a tarefa de codificação do vídeo não impacta na carga de processamento da GPU, apesar de poder degradar um pouco a fluidez do gameplay por compartilhar o mesmo barramento com os circuitos dedicados à shaders, etc.
em modelos sem circuito dedicado, porém, o usuário precisará testar qual dispositivo - se CPU ou GPU - tem mais processamento livre para mitigar o impacto negativo da adição de codificação à carga já existente produzida pela aplicação principal. seja jogo, câmera, etc.
um outro cenário comum é a presença de mais de uma placa de vídeo no computador, e ao contrário do que se espera, e pelo menos em relação ao OBS-Studio, o uso de placas adicionais prejudica o desempenho ao invés de aumentá-lo. tal fenômeno negativo não é observado em ferramentas da suíte Adobe, por exemplo. e até pelo contrário, tais ferramentas conseguem distribuir bem a carga entre as múltiplas unidades de processamento gráfico - o que não acontece com o OBS-Studio.
caso esteja utilizando SLI, prefira usar apenas uma placa para gameplay e use a mesma placa para codificação de vídeo para maximizar fluidez.
em caso de pcs e principalmente laptops, com a presença de iGPUs intel e dGPUs amd / nvidia, também prefira usar apenas uma placa para as ambas as funções.
link: https://www.youtube.com/watch?v=R0zEFF6q2Ng
dito todas estas coisas, é preciso abordar o caso mais difícil: dual gpus laptops.
em primeiro lugar, neste cenários use sempre a versão mais atualizada possível do Windows¹ e seus drivers, principalmente os drivers de vídeos.
¹ a versão do Windows ao contrário do que normalmente se acredita não é relevante; as diferenças entre versões "SKUs" do Windows - como "Home", "Professional", "Enterprise" -, são de funções e não de desempenho;
caso a necessidade seja apenas de captura da área de trabalho em dual gpus laptops, feche o OBS-Studio e apenas siga o passo-a-passo como no vídeo abaixo:
desktop (right click) > display settings > graphics settings (scroll down and click) > classic app > browse > choose ".../bin/64bit/obs64.exe" > add > options > power saving > save, done!
source: https://www.youtube.com/watch?v=awXP6_kDii4
entretanto, esta configuração pode prejudicar o desempenho em jogos mais exigentes por forçar o OBS-Studio a usar 2 GPUs ao mesmo tempo. o problema, porém, é que não existe um método único ou simples para transferir toda a carga de processamento para uma única GPU e além disto não necessariamente a decisão de utilizar apenas uma GPU seja vantajosa em todos os cenários de usos possíveis de um laptop, pois pode haver diminuição da duração da bateria e até mesmo elevação da temperatura internet do equipamento. de qualquer forma utilizar x264 tende a mitigar o impacto negativo das múltiplas GPUs.
apesar da menção, não devo tentar explicar como isolar o processamento a uma única GPU além do que já foi apresentado.
para fecharmos o assunto de encoder em definitivo, basta comentarmos sobre keyframe. e basta saber que o padrão de 2 segundos de keyframe é utilizado na maioria das grandes plataformas. em condições especiais, como baixas resoluções, valores maiores podem ser utilizadas e o aumento do keyframe tende a melhorar a qualidade de imagem ao custo de tornar falhas de transmissões mais danosas. suponto que durante uma transmissão com keyframe de 10 segundos e caso ocorra a perda de transmissão justamente do pacote contendo informações do keyframe, a transmissão irá presenciar forte distorção de imagem por 10 segundos. enquanto, uma mesma ocorrência ao usar keyframe de 2 segundos não produzirá mais do que 2 segundos de distorção para cada keyframe perdido.
(...)
WIP: audio, streaming key, capturas, overlay do piada, redes
(...)
FAQ (frequently asked questions)
pergunta: "por que fez este guia?"
resposta: provavelmente irei me "aposentar" da tarefa de auxiliar terceiros a configurar suas laives pelo discord e espero ser completamente substituído por este guia.
pergunta: "quem é o público alvo deste guia?"
resposta: qualquer um minimamente preocupado com preservação da qualidade de imagem capturada e com o baixo impacto no desempenho de seu equipamento. e mais do que isto para alguém fundamentalmente interessado em aprender um pouco sobre conversão e transmissão multimídia.
pergunta: "fará guia para uso de BOTs e criação de layout?"
resposta: não. minha preocupação exclusiva é sobre estabilidade e performance.
em relação à parte estética não sei fazer bons julgamentos ou decisões. e não estou desmerecendo o conceito. apenas reconhecendo que não tenho qualquer fluência na área para me aventurar a comentar sobre o assunto.
é muito provável que superado os problemas técnicos, os desafios para aumento de público e engajamento se movem sobre a qualidade de conteúdo e seus formatos estéticos.
pergunta: "fará um guia para o uso de filtros de áudio?"
resposta: não. considero-me leigo na área. não tenho o que explicar.
pergunta: "fará um guia para programas concorrentes ao OBS-Studio?"
resposta: não.
pergunta: "mas os programas pagos não são melhores?"
resposta: se por "melhor" estamos falando de gosto pessoal, interface mais organizada ou maior facilidade de uso, não faço questionamentos ou contestação. eles podem ser melhores.
porém, se por "melhor" estivermos falando sobre ser "mais leve" e assim ter vantagem de desempenho na execução da captura, no processo de renderização, no custo de conversão multimídia e na tarefa de transmissão, aí tenho profundas dúvidas a respeito destas afirmações.
apesar de gratuito, OBS-Studio faz uso de bibliotecas muito sólidas na área multimídia e não me assustaria se seus concorrentes pagos fizessem uso das mesmas bibliotecas, visto que o desenvolvimento de um encoder, por exemplo, não é barato, nem fácil e nem rápido de ser feito.
a parte de captura de navegação por exemplo é feito através de código cedido por engenheiros de software da Google. é praticamente um chrome embutido.
o chrome hoje é padrão da indústria. todos navegadores com exceção do Firefox usam o código do chromium (nome open source do projeto) como motor de renderização padrão. até o discord instalado.
como curiosidade, é estranho alegar que o discord rode melhor "no navegador" visto que a versão instalável utiliza uma versão simplificada do chromium embutida. e em relação à captura e transmissão, o discord faz uso de código do ffmpeg, assim como também fazem uso de código do ffmpeg o obs-studio, chrome, retroarch, blender, handbrake, lightworks, audacity, vlc, mplayer, kodi, super, etc.
source: https://trac.ffmpeg.org/wiki/Projects
pergunta: "OBS-Studio é a melhor opção para pcs antigos?"
resposta: se a data de fabricação dos componentes do seu computador tem menos de 5 anos, o OBS provavelmente é uma solução adequada.
se a data de fabricação dos componentes tem entre 5 e 10 anos, qualquer programa de streaming irá produzir impacto perceptível na performance do mesmo. entenda que comprometimentos de qualidade precisarão ser feitos. principalmente, redução da resolução e redução da taxa de quadros de saída.
se os componentes têm mais de 10 anos, além de reduzir a expectativa gráfica atingível, como o uso de múltiplas capturas de navegação, uso de alertas, gifs, uso de capturas de câmeras, resoluções elevadas, uso de altas taxas de quadros, considere fazer uso de programas extremamente limitados em recursos como o FFsplit. [mirror]
a título de curiosidade já ajudei na configuração de laives retrôs utilizando o FFsplit em um computador dual core 775, com 1 GB de RAM, placa de vídeo integrada da marca SiS, e Windows 7 32 bits. dá para fazer e dá para ficar estável. mas não pretendo orientar mais ninguém nestas aventuras e nem mesmo produzir um guia.
de qualquer forma, uma leitura atenta do presente guia permite uma configuração adequada do FFsplit. os conceitos apresentados, de fato, servem para qualquer programa de streaming.
entretanto, tirando os casos extremos, o OBS-Studio novo e atualizado é adequado para "pcs antigos".
pergunta: "a lentidão do meu pc não é provocada pelo OBS?"
resposta: não existe adição de tarefa que tenha impacto nulo no processamento.
toda atividade adicional aumenta a carga geral de processamento do sistema. normalmente, leigos e inexperientes não possuem referência alguma para avaliar o custo da adição de novas capturas, novos redimensionamentos, novas aplicações de filtros, mais a renderização, conversão e transmissão realizados por seus programas de streaming.
e assim se antes algo que era feito deixou de acontecer a única responsabilidade só pode ser da nova aplicação, e não das más decisões ou completo desconhecimento por parte do usuário.
seja econômico no uso de recursos do seu programa de streaming - qualquer um que seja - caso queira mitigar o impacto na performance.
pergunta: "usar bitrate alto trava o computador?"
resposta: não.
até ao contrário, como forma de diminuir a necessidade de compactação (o que demandaria mais processamento), equipamentos como câmeras e smartphones utilizam por padrão - o que seria o preset "ultrafast" do x264 - baixa compactação com altíssimo bitrate, exatamente para liberar processamento e assim economizar bateria ao custo de um consumo maior do espaço livre em unidades de armazenamento dos dispositivos.
tal estratégia também pode ser utilizada em computadores mas, para funcionarem, o bitrate precisa ser muito maior do que o máximo suportados pelos servidores ingest das grandes plataformas como youtube e twitch, logo, tal estratégia só tem efeito prático para gravação de gameplay offline.
source: https://support.google.com/youtube/answer/1722171?hl=en
pergunta: "meu pc sempre fica lento. devo formatá-lo todo mês?"
resposta: não. formatação não possui impacto na performance da máquina.
use apenas software original, atualizado e em configuração padrão / nativa. prefira usar programas que não precisem ser instalados (versão portable ou standalone - e sempre oficiais!). se conseguir manter o sistema inalterado desde a última formatação, não há motivo para o pc rodar mais rápido na futura formatação.
evite instalar aquilo que não precisa. evite seguir tutorais "gamers" ou de "aumento de desempenho", evite desativar serviços do sistema que você não entenda, evite fazer alterações no registro, apagar arquivos temporários diariamente e outros exageros.
evite fazer alterações de configuração no driver da placa de vídeo. a configuração padrão normalmente é a melhor e permite que em cada jogo você faça uso livre das opções oferecidas. não é incomum que o usuário proíba ou force uma determinada configuração no driver da gpu e dentro do jogo tente fazer uso diverso do mesmo recurso.
páre. respire. preste atenção no que está fazendo e ao menos leia em voz alta os nomes das opções que está alterando no driver e nos jogos. mantenha a calma. respire.
pergunta: "aquele outro Windows não é mais rápido?"
resposta: não. as versões domésticas e as versões destinadas a servidores possuem o mesmo desempenho para as mesmas tarefas.
não recomendo utilizar versões alteradas por terceiros. use sempre a versão original. e em caso de dúvida, veja o vídeo com benchmark realizado pelo Baboo.
"Baboo - Windows 10 LTSB x Pro x Home"
pergunta: "vc trata o uso de software original como uma bandeira moral?"
resposta: não. software original é objetivamente melhor e mais seguro.
pergunta: "meu Windows está com defeito, dá para corrigir?
resposta: caso ele seja original, provavelmente, sim e sem formatar.
no caso do Windows 10 é sempre melhor re-iniciar uma vez. e eventualmente explicarei o motivo em outra pergunta-resposta.
após a re-inicialização, com todos os programas fechados e sem abrir nenhum programa durante a execução destes passos, faça:
(0) abra o prompt de comando como administrador ("cmd.exe");
(1) cole no cmd: "DISM.exe /Online /Cleanup-image /Restorehealth";
apenas o conteúdo do comando, sem as aspas.
copiar e colar é mais fácil que digitar.
(2) aguarde, então, re-inicie;
(3) cole em novo cmd como admin: "sfc /scannow"
apenas o conteúdo do comando, sem as aspas. copiar e colar é mais fácil que digitar.
caso o erro persista, tente remover plugins de bancos presentes, desinstalar antivírus e eventualmente fazer escaneamento com ferramentas de segurança alternativas - sempre usando versões originais. opte pelas versões gratuitas caso não queira pagar por uma licença. as soluções pagas de segurança tendem a trazer mais conforto sem necessariamente aumentar a proteção ou a eficiência da remoção de malware.
repita os passos mais uma vez. o Windows deve ser capaz de corrigir sozinho todos os seus feitos.
caso os erros ainda persistam, talvez seja necessário fazer diagnóstico de hardware, verificar se não existe defeito em RAM, defeito em drive / mídia de armazenamento, ou ainda ser o caso de um driver defeituoso - e assim substituí-lo por uma versão mais nova, atualizada, ou no caso de já estar usando a última versão, testar uma versão mais antiga apenas após re-forçar a instalação da última versão.
no caso de drivers de vídeo, entrar em modo de reparação avançada do Windows e usar programas como o DDU podem forçar a remoção completa do driver defeituoso, mas um guia para tal ferramenta não será criado aqui.
source: https://support.microsoft.com/en-us/...file-checker
source: https://www.wagnardsoft.com/display-driver-uninstaller-ddu-
pergunta: "formatei, o que preciso instalar agora?"
resposta: existem 3 recursos importantes numa nova instalação e eventualmente necessários até antes de instalar os drivers: (a) um programa descompactador de arquivos, (b) bibliotecas Visual C++ e (c) .NET Framework;
(a) 7-zip, WinRAR e PeaZip são boas opções gratuitas;
link: https://www.7-zip.org/download.html
link: https://www.rarlab.com/download.htm
link: https://peazip.github.io/index.html [muito confortável no linux]
(b) bibliotecas Visual C++ atualizadas;
apesar de sempre recomendar o download dos sites oficias, neste caso, eu prefiro baixar o pacote de bibliotecas Visual C++ disponibilizado pelo site TechPowerUP - o qual também sempre fornece links atualizados para os mais novos drivers de gpu além de ser o site oficial da ferramenta GPU-Z.
infelizmente, a maioria das versões precisa ser instalada e por isso a versão do TechPowerUP é tão mais confortável. nela já vem tudo.
link: https://www.techpowerup.com/...all-in-one/
link: https://support.microsoft.com/en-us/...visual-c-downloads
(c) .NET Framework;
ao contrário da biblioteca anterior, basta instalar a última e mais recente versão!
link: https://dotnet.microsoft.com/download/dotnet-framework
link: https://dotnet.microsoft.com/download [para outras plataformas]
(d) bônus: Legacy DirectX;
caso o usuário faça uso de emuladores e outros jogos antigos, é muito provável que precisará instalar a versão antiga do DirectX para executar tais programas. as versões mais novas do DirectX são nativas do Windows 10 e atualizadas automaticamente pelo próprio Windows Update.
link: https://www.microsoft.com/en-us/download/details.aspx?id=8109
pergunta: "devo usar GNU/Linux para fazer laives?"
resposta: o comportamento e a performance do OBS-Studio no linux é extremamente similar à versão para Windows. a diferença se dá nos títulos de jogos suportados.
por volta de 70% dos títulos de jogos para Windows da Steam rodam sem ou com pouco prejuízo no linux. dentro dos 30% não suportados estão títulos que normalmente fazem uso de programas anti-cheat e assim são programados com intuito de não serem possíveis de serem executá-los no linux.
em relação à emulação retrô, a maioria dos desenvolvedores está migrando para plataforma. RetroArch por exemplo roda muito bem no linux.
se gosta de tecnologia em geral. experimente fazer dual boot em sua máquina.
pergunta: "aumentar a resolução e framerate não aumentam o desempenho?"
resposta: pára. respira. lê o que escreveu. pense sobre o que falou.
você já viu algum teste de desempenho na vida? e existe algum teste de desempenho que o aumento da resolução aumente o desempenho ou diminua a carga sobre o hardware?
dica: se aumentar a resolução diminuísse o custo de processamento... então para jogar em resolução máxima como 8K ao invés de uma nova RTX 3090 não seria necessário apenas uma antiga e simples GT 730?
se continua em dúvida: pense mais um pouco e faça testes. tudo isso faz bem.
pergunta: "devo trocar a pasta térmica todo mês?"
resposta: calma. inspira. expira. (repita)
limpeza é importante e fluxo de ar não obstruído também. porém, uma pasta pode muito bem apresentar boa performance por 2 anos ou mais. bem mais até. caso esteja extremamente preocupado procure por pads-térmicos reutilizáveis que apresentam desempenho compatível com as melhores pastas sem degradação da performance ao longo do tempo.
a frequência da limpeza depende do acumulo de poeira em seu equipamento. salas limpas diariamente, com baixo fluxo de pessoas e com uso de ar-condicionado, como é comum em empresas, produzem baixo acumulo de poeira. por sua vez, salas limpas uma vez por semana, com uso de ventiladores e janelas abertas - como é comum em casas - produzem muito mais acumulo de poeira.
pergunta: "preciso de 2 pcs para fazer laive?"
resposta: não. quanto mais novo e poderoso é o hardware, mais insignificante é o impacto negativo em performance de qualquer programa de streaming sobre ele. se está percebendo muito impacto, provavelmente seu hardware é antigo / fraco ou está fazendo uso de configurações inadequadas ao hardware disponível.
de qualquer modo, prefiro evitar emitir juízo sobre streamers famosos com hardwares poderosos fazendo uso de múltiplos computadores para transmissão de laive ou ainda defendendo a estratégia.
para a gravação de benchmark de hardware tal configuração dual faz sentido.
este, porém, não é um guia de benchmark, é um guia simples de transmissão.
se através do guia não conseguiu atingir um resultado satisfatório e precisa de mais desempenho para realizá-lo, invista num upgrade para seu pc. não é inteligente e nem é um bom investimento usar ou comprar duas máquinas velhas / fracas para transmissão de gameplay.
duas máquinas velhas ou fracas não produzem a mesma fluidez no gameplay e nem a mesma qualidade da transmissão de uma máquina nova e potente. o investimento financeiro, a complexidade de configuração, a ocupação do espaço, a quantidade de cabos envolvidos e o custo de manutenção de duas máquinas velhas / fracas são imensamente superiores à utilização de uma única máquina nova e potente.
se levar em consideração o custo de uma nova fonte de entrada, uma nova placa mãe de entrada, e um nova cpu de entrada, sem levar em consideração aos demais custos... com o dinheiro você compra um processador melhor, mais rápido, com mais núcleos e ainda sobra dinheiro.
se levar em consideração o custo de um conjunto novo de memórias de entrada, uma nova placa de vídeo de entrada, um novo gabinete, um novo drive de armazenamento... com o dinheiro você compra uma placa de vídeo mais rápida, com mais recursos e ainda economiza dinheiro.
manter-se preso a um pc antigo e considerar como vantajoso o investimento num pc auxiliar é não perceber a limitação implícita escolhida, a limitação no desempenho e na qualidade dos jogos ao hardware antigo, quando pode-se melhorar o desempenho e qualidade dos jogos ao mesmo tempo que pode-se adicionar mais função, como a transmissão online e ainda poupar tempo, dinheiro, energia elétrica, temperatura do ambiente, poluição sonora, espaço na sala, espaço sobre a mesa, ter uma organização mínima de cabos, etc.
a adição de mais núcleos de cpu e a substituição da gpu antiga por uma nova com circuito dedicado de codificação praticamente anulam qualquer prejuízo ao gameplay provocado pelo aplicativo de streaming.
comprar 2 máquinas para a tarefa em questão não faz sentido. é uma péssima decisão.
pergunta: "então o OBS-Studio não é um programa muito pesado?"
resposta: não.
pergunta: "a Intel recomenda 2 pcs. vc ñ tem vergonha de ser tão inútil?"
resposta: compre amd, siga o guia. me agradeça depois.
pergunta: "devo usar duas GPUs? uma para jogar e outra para o OBS?"
resposta: não.
pergunta: "no Adobe duas GPUs melhoram a performance, vc é inútil?"
resposta: OBS-Studio não faz parte da suíte Adobe.
em testes realizados no OBS-Studio, os usos de gpu adicionais para codificação de vídeo provocaram lentidões nos jogos significativamente maiores que o simples uso solitário de uma placa de vídeo. o uso adicional de gpu portanto - no caso do OBS-Studio - produz prejuízo de performance.
dependendo do cenário pode ser mais vantajoso oscilar a tarefa de codificação entre CPU e GPU, mas nunca entre múltiplas GPUs - seja entre iGPU/APUs e modelos discretos; seja entre dois ou mais modelos discretos¹.
¹ as placas de vídeo podem ser "embutidas" / "integradas" quando presentes na placa mãe ou cpu. neste caso usamos os termos "iGPU" (geral) ou "APU" (amd). no caso de placas de vídeo adicionais, independentes, avulsas, usamos o termo "dGPU" ou "discreta".
por fim, não tenho conhecimento do comportamento de tais cenários em outros programas de streaming.
pergunta: "ainda não estou convencido. não tem argumentos melhores?"
resposta: viva sua vida, seja feliz e faça como julgar vantajoso.
pergunta: "o modem diz estar conectado mas não navego, e aí?"
resposta: o servidor DNS padrão do seu provedor pode estar fora do ar. e ao contrário do que normalmente se diz, servidores DNS não apresentam impacto no desempenho da rede.
bons servidores DNS são estáveis e logo favorecem à confiabilidade da rede. usar servidores DNS mais estáveis garante menos problemas de navegação sem qualquer impacto na velocidade do download ou da própria navegação. alguns servidores podem inclusive aumentar a segurança ou impor restrições.
após a primeira consulta, o resposta do servidor DNS se torna cacheada na máquina local e logo não faz mais uso da internet para resolução da consulta. sendo assim sua resposta é praticamente instantânea.
Cisco Umbrella/OpenDNS IPv4: 208.67.222.222
Cisco Umbrella/OpenDNS IPv4: 208.67.220.220
Cisco Umbrella/OpenDNS IPv6: 2620:119:35:0:0:0:0:35
Cisco Umbrella/OpenDNS IPv6: 2620:119:53:0:0:0:0:53
CloudFlare DNS IPv4: 1.1.1.1
CloudFlare DNS IPv4: 1.0.0.1
CloudFlare DNS IPv6: 2606:4700:4700:0:0:0:0:1111
CloudFlare DNS IPv6: 2606:4700:4700:0:0:0:0:1001
Google DNS IPv4: 8.8.8.8
Google DNS IPv4: 8.8.4.4
Google DNS IPv6: 2001:4860:4860:0:0:0:0:8888
Google DNS IPv6: 2001:4860:4860:0:0:0:0:8844
escolha uma empresa e teste-a. todos os servidores listados são públicos, gratuitos, de abrangência mundial e podem ser configurados tanto manualmente em cada máquina ou nos dispositivos de rede como modem ou roteadores wifi para uso transparente por todos os clientes automaticamente.
info: https://support.opendns.com/hc/en-us/...Windows-10-Configuration
info: https://developers.google.com/speed/public-dns/docs/using
info: https://adguard-dns.io/kb/general/dns-providers/
pergunta: "posso bloquear malware, sites adultos, etc por DNS?"
resposta: sim!
entenda que através desta questão estamos mais no terreno da curiosidade do que propriamente no terreno das vantagens para realização de live streaming. não pretendo aprofundar o guia em redes, mas para caso alguém queira limitar internet para filhos ou no caso de alguém ter uma pequena empresa com wifi público e não queira que a internet seja utilizada para conteúdos pouco produtivos ou inseguros, os servidores abaixo podem ser utilizados, sem custos.
como curiosidade final, o uso de servidores dns com bloqueio de malware foi a única solução que encontrei para tornar o uso de dispositivos android - principalmente por parentes já na terceira idade mas novos em relação à tecnologia - minimamente sem sustos, sem infecções re-incidentes e sem prejuízos à navegação.
aviso porém que dependendo do servidor escolhido até mesmo a área de comentários do youtube pode ser bloqueada por padrão. então, decida com sabedoria.
AdGuard DNS IPv4: 90.140.14.14
AdGuard DNS IPv4: 94.140.15.15
AdGuard DNS IPv6: 2a10:50c0:0:0:0:0:ad1:ff
AdGuard DNS IPv6: 2a10:50c0:0:0:0:0:ad2:ff
AdGuard Family DNS IPv4: 94.140.14.15
AdGuard Family DNS IPv4: 90.140.15.16
AdGuard Family DNS IPv6: 2a10:50c0:0:0:0:0:bad1:ff
AdGuard Family DNS IPv6: 2a10:50c0:0:0:0:0:bad2:ff
CleanBrowsing Secure DNS IPv4: 185.228.168.9
CleanBrowsing Secure DNS IPv4: 185.228.169.9
CleanBrowsing Secure DNS IPv6: 2a0d:2a00:1:0:0:0:0:2
CleanBrowsing Secure DNS IPv6: 2a0d:2a00:2:0:0:0:0:2
CleanBrowsing Adult Filter DNS IPv4: 185.228.168.10
CleanBrowsing Adult Filter DNS IPv4: 185.228.169.11
CleanBrowsing Adult Filter DNS IPv6: 2a0d:2a00:1:0:0:0:0:1
CleanBrowsing Adult Filter DNS IPv6: 2a0d:2a00:2:0:0:0:0:1
CleanBrowsing VPN/Family DNS IPv4: 185.228.168.168
CleanBrowsing VPN/Family DNS IPv4: 185.228.169.168
CleanBrowsing VPN/Family DNS IPv6: 2a0d:2a00:1:0:0:0:0:0
CleanBrowsing VPN/Family DNS IPv6: 2a0d:2a00:2:0:0:0:0:0
CloudFlare Secure DNS IPv4: 1.1.1.2
CloudFlare Secure DNS IPv4: 1.0.0.2
CloudFlare Secure DNS IPv6: 2606:4700:4700:0:0:0:0:1112
CloudFlare Secure DNS IPv6: 2606:4700:4700:0:0:0:0:1002
CloudFlare Adult/Sec DNS IPv4: 1.1.1.3
CloudFlare Adult/Sec DNS IPv4: 1.0.0.3
CloudFlare Adult/Sec DNS IPv6: 2606:4700:4700:0:0:0:0:1113
CloudFlare Adult/Sec DNS IPv6: 2606:4700:4700:0:0:0:0:1003
Quad9 Secure DNS IPv4: 9.9.9.9
Quad9 Secure DNS IPv4: 149.112.112.112
Quad9 Secure DNS IPv6: 2620:fe:0:0:0:0:0:fe
Quad9 Secure DNS IPv6: 2620:fe:0:0:0:0:0:9
pergunta: "se este guia é curtíssimo, existe um guia longuíssimo?"
resposta: até comecei a escrevê-lo mas ele estava ficando tão grande que tive a impressão que não seria lido por ninguém. decidi escrever o curtíssimo primeiro.
um guia mais profundo não deve ser publicado. ainda, o futuro é imprevisível.
pergunta: "discordo de muita coisa escrita aqui. e aí?"
resposta: todo terra planista moderno é uma pessoa flexível à demonstrações empíricas reproduzíveis e dependendo da qualidade do texto até à documentação oficial adicional.
faça suas afirmações e me mande links ou orientações para que eu consiga atingir os mesmos resultados e me convença através da observação da realidade fria e objetiva dos dados.
textos e vídeos em português ou inglês me dedico a estudar mas sem chance para obras em outras línguas. não parei de errar, continuo errado diariamente. espero como hipótese que esteja errado. porém aguardo inconscientemente em erro até manifestação externa contrária persuasiva.
aceito também sugestões de guias alternativos que tenham profundo apreço por seu público consumidor, conteúdo relevante ou notável qualidade.
pergunta: "péra aí, ocê é terra planista?"
resposta: e você não!?!?
pergunta: "as informações aqui são confiáveis?"
resposta: não confie no que você lê na internet. e sempre faça testes!
pergunta: "gostei do guia, posso falar que ele é meu?"
resposta: sim.
qualquer coisa que eu produza deve ser utilizado sem qualquer solicitação e do modo que preferir. realmente não me importo com o controle sobre o uso do guia. ele foi escrito para ser utilizado por terceiros, e me encanta que possa ser útil para alguém, sem qualquer necessidade de prestação de créditos.
de qualquer forma, tudo que está aqui não é de fato invenção minha mas cópia direta das documentações oficiais ou resultado de testes - os quais são reproduzíveis por terceiros - e podem ser "descobertos" por qualquer um.
numa linha: tudo foi escrito para ser copiado.
pergunta: "por que o FAQ é bem maior que o guia?"
resposta: o que precisa ser feito é bem pouco. agora novas dúvidas surgem todos os dias.
pergunta: "como faço doações ao blog?"
resposta: no guia longuíssimo deverá ter explicações.
(...)
done!
Nenhum comentário:
Postar um comentário