- Para continuar usando normalmente os downloads do YouTube no yt-dlp, em breve será obrigatório instalar o Deno (ou um runtime JavaScript compatível)
- Devido a mudanças recentes no lado do YouTube, não será mais possível resolver os desafios JS apenas com o "interpretador" JavaScript embutido
- Usuários dos executáveis PyInstaller só precisarão preparar o Deno, enquanto quem usa o pacote do PyPI precisará instalar componentes JavaScript adicionais
- O suporte a outros runtimes JavaScript (Node, Bun etc.) continua em aberto, mas apenas o Deno é considerado adequado em termos de segurança e sandboxing
- Devem ser oferecidas opções e orientações específicas sobre instalação do Deno, dependências relacionadas e definição de caminhos
Anúncio das mudanças nos downloads do YouTube no yt-dlp e dos novos requisitos
Contexto da adoção dos novos requisitos
- Em breve, para usar normalmente a função de download do YouTube, será necessário instalar obrigatoriamente o Deno ou outro runtime JavaScript compatível
- Até agora, o yt-dlp vinha usando um interpretador JavaScript embutido para resolver os desafios JS do YouTube, mas devido a mudanças recentes na lógica interna do YouTube, esse método já não é mais suficiente
- Como as mudanças foram muito amplas, para funcionar corretamente o yt-dlp passará a precisar de um algoritmo baseado em um runtime JavaScript real para conseguir processar as requisições ao YouTube
Como cada tipo de usuário deve se preparar
- Instalar o Deno (ou um runtime JS compatível)
- A equipe deve informar futuramente, por meio do FAQ e outros canais, quais runtimes adicionais serão compatíveis
- Pode ser necessário instalar alguns componentes JavaScript exigidos pelo yt-dlp
- A necessidade de etapas adicionais varia conforme a forma de instalação e distribuição do yt-dlp
Checklist por distribuição oficial
- Executáveis oficiais fornecidos com PyInstaller (
yt-dlp.exe, yt-dlp_macos, yt-dlp_linux etc.)
- Basta instalar o Deno; os componentes adicionais já vêm incluídos no executável
- Pacote do PyPI (
pip, pipx etc.)
- É necessário instalar o yt-dlp com o grupo de dependências da opção
default e atualizar para a versão mais recente
- Exemplo:
pip install -U "yt-dlp[default]"
- Binário oficial
zipimport (yt-dlp para Unix)
- Será necessário adicionar uma flag para que o Deno baixe as dependências npm
- Ou instalar no ambiente Python um pacote separado de resolução JS para o yt-dlp (o nome do pacote e as opções serão anunciados depois)
- Pacotes de terceiros (
pacman, brew etc.)
- As medidas podem variar conforme a política de cada distribuição, mas é possível usar as orientações voltadas aos usuários do binário
zipimport
Discussão sobre runtime e segurança
- Há possibilidade de suporte a runtimes JS alternativos como Node e Bun, mas, no momento, eles não oferecem os mesmos recursos de segurança e sandboxing do Deno
- O suporte futuro a outros runtimes JS ainda está em discussão; até que haja uma definição final, a orientação será baseada no Deno
Orientações adicionais sobre a instalação do Deno
- Assim como o yt-dlp, o Deno pode ser usado apenas baixando um executável único do GitHub e colocando-o em um caminho acessível
- Futuramente, o yt-dlp deve receber a opção
--js-runtimes para permitir especificar o caminho do executável do Deno (o nome da opção e a forma de uso ainda podem mudar)
- Depois de baixar o Deno com
curl ou outro método, ele poderá funcionar normalmente se for colocado na mesma pasta do executável do yt-dlp
FAQ e orientações complementares
- Dependendo do sistema operacional ou do gerenciador de pacotes em uso, pode ser necessário adicionar o binário ao
PATH
- Em alguns ambientes, como no Linux, o Deno pode ser registrado automaticamente no
PATH
- Dúvidas adicionais e problemas de instalação devem ser tratados futuramente no FAQ ou na comunidade
Reações da comunidade e atualizações futuras
- Alguns usuários já perguntam sobre impactos diversos, como o possível fim do suporte a sistemas 32 bits e opções de distribuição
- A equipe de desenvolvimento do yt-dlp pretende preparar orientações e formas de suporte melhores com base em abertura de issues, patches e feedback da comunidade
Conclusão e resumo
- Com a mudança na estrutura do sistema do YouTube, a arquitetura de funcionamento e os requisitos do yt-dlp passam por uma grande alteração
- A principal mudança é que, para continuar usando normalmente os downloads do YouTube, será obrigatório preparar um runtime JS como o Deno
- É importante agir rapidamente de acordo com as orientações específicas de cada forma de distribuição oficial
- Mais orientações, FAQ e guias de instalação devem continuar sendo publicados
1 comentários
Comentários no Hacker News
Sou assinante pago do YouTube Premium. No fim de semana passado tentei baixar vídeos para ver no trem, mas tanto no iPad quanto no iPhone ficou travado em “Aguardando download...”. Reiniciar também não ajudou, então depois de tentar por 1 hora eu desisti. Baixei os vídeos com o yt-dlp, transferi para um pendrive USB-C e assisti assim. Quando implementarem a política de “restrição de compartilhamento do Premium entre familiares”, aí sim pretendo cancelar de vez. Minha família usa bastante o ambiente sem anúncios
Eu também assino o Premium, mas tive um problema parecido no app do iPad. Mesmo ao tentar baixar vídeos para mostrar ao bebê, quase nunca funciona direito de primeira. Fiquei tão irritado que comprei um Samsung Galaxy Tab A7 usado e instalei uma ROM customizada com LineageOS. Coloquei toda a mídia que eu queria em um cartão SD de 1 TB e reproduzo tudo muito bem com o VLC. Além disso, o NewPipe baixado pela loja F-Droid consegue baixar vídeos do YouTube com muito mais estabilidade do que o app oficial. Originalmente eu pretendia preencher a mídia com algo como o yt-dlp, mas agora nem preciso mais
Eu pago pelo YouTube Premium, mas no celular assisto com ReVanced porque preciso desativar a tradução automática. Não entendo como o app oficial não deixa o usuário mudar essa configuração
Se você sobe um vídeo no YouTube e depois tenta baixá-lo pelo painel do criador — por exemplo, se fez uma live e não manteve backup local, ou quando o computador está sobrecarregado — só consegue baixar em 720p de baixa qualidade. Já com o yt-dlp dá para obter a melhor qualidade possível
Cancelei a assinatura porque o ambiente sem anúncios não funcionava no YouTube Kids (usando um ShieldTV). Talvez fosse um bug, mas como não havia suporte ao cliente, não tinha o que fazer. Eu era assinante pago do Play Music e fui forçado a migrar para o YouTube, então essa foi realmente a última decepção
Se você estava esperando notícias sobre a política de restrição do compartilhamento familiar, informo que já existem notícias sobre isso. Eu também recebi um e-mail do YouTube a respeito. No momento ainda uso sem anúncios, mas não sei quando isso será aplicado de fato. Dá para conferir a matéria relacionada
Fico impressionado com o esforço de engenharia colocado no “interpretador JavaScript” do yt-dlp yt-dlp jsinterp.py
É uma abordagem perfeita para resolver o problema. É realmente impressionante terem implementado isso até esse nível sem overhead adicional
A parte mais escondida e importante deste anúncio é justamente essa. Eu não fazia ideia de que a estrutura já tinha ficado tão complexa, e acho isso muito impressionante
É um método de interpretar apenas uma parte do JavaScript. Dá para ver a discussão relacionada no HN aqui
Dei uma olhada rápida no código e acabei conhecendo o ChainMap do Python
Fico curioso sobre quanto JavaScript ele realmente interpreta e se, com menos de 1.000 linhas de código, isso poderia ser usado em uma aula introdutória de compiladores
Sou um “acumulador digital” que coleciona mídia digital há mais de 30 anos. Não tenho mídia física como VHS ou DVD, tudo é armazenado digitalmente. Tenho até alguns materiais raros ou que podem desaparecer. Minha esposa também se interessou pelo meu sistema, que “funciona como uma Netflix em casa”, e gostou de assistir sem anúncios. Eu não me achava uma pessoa especial e pensava que todo mundo usaria streaming. Durante anos disse às pessoas ao meu redor: “se eu tiver alguma mídia com um programa de que você gosta, me avise”. Nos últimos dois anos, familiares e amigos começaram a querer acesso ao meu servidor Jellyfin ou me pedir para montar pequenos servidores debaixo da TV deles. Mais recentemente também adicionei arquivamento de canais do YouTube ao Jellyfin, usando um diretório por canal e comandos do yt-dlp para baixar automaticamente os vídeos. Só que não consigo baixar no codec h264 que eu quero, então recodifico. Como os vídeos do YouTube são fornecidos em codec AV1 e minha smart TV ainda não suporta esse codec, eu mesmo faço a codificação
Antes eu usava um script simples, mas agora uso o ytdltt GitHub do ytdltt com um bot do Telegram para que minha mãe possa baixar vídeos do YouTube como audiolivros, organizados por diretório, e acessá-los pelo Jellyfin. Os audiolivros que ela acumulou em 3 anos somam cerca de 1,2 TB
Para um objetivo parecido, também vale testar o tubesync
Quando vi que não dava para baixar conteúdo em h264, achei a documentação do yt-dlp meio difícil, mas hoje o método que funciona bem é algo assim
yt-dlp -f "bestvideo[width<800][vcodec~='^(avc|h264)']+bestaudio[acodec~='^((mp|aa))']"Recentemente descobri o Pinchflat GitHub do Pinchflat, que usa o yt-dlp em segundo plano como uma alternativa web no estilo *arr. Você adiciona à playlist os vídeos que quer baixar e ele pega tudo automaticamente
Fico curioso se é necessário driblar a detecção de bots com registro de cookies e coisas do tipo, e se também é preciso usar VPN
Agora acabou a era de simplesmente buscar dados na web; entramos na era em que é preciso executar milhares de linhas de JavaScript ofuscado. Antes era fácil baixar um arquivo JSON de 1 KB e fazer cache; agora é preciso rodar um navegador inteiro, trocar 10 MB de dados em 100 requisições, e isso bagunça totalmente o ambiente de análise e o perfil de segurança. Todo mundo sai perdendo
Pelo lado positivo, esse ambiente inconveniente abriu oportunidade para 10.000 empresas de scraping coletarem 10 MB de lixo e venderem isso como uma API decente. Mas agora a qualidade do conteúdo dos sites também caiu, então esse tipo de problema vai ficando cada vez menos importante
Hoje a web ficou tão complexa que parece um jogo infinito de scraping-antibloqueio-bypass. Mas com a chegada de IA/LLMs, ficou possível extrair qualquer informação, ainda que com custo maior. Em breve os LLMs também vão passar por todos os CAPTCHAs. Talvez estejamos chegando a um ponto em que o “buraco analógico” fica sempre aberto. Basta apontar câmera e microfone para a tela e o som, e a IA já consegue interpretar isso melhor do que humanos
Felizmente, scraping em pequena escala como o do yt-dlp está mais fácil do que nunca. Com uma ou duas horas investidas, dá para montar scripts facilmente com Firefox headless e mitmproxy e arquivar o conteúdo que eu quiser, desde que eu não tente raspar um site inteiro rodando vários VPS em grande escala. O Cloudflare também não bloqueia usuários comuns de baixo volume. A automação moderna de navegadores é tão fácil que um usuário individual consegue raspar um site tranquilamente mesmo se ele for SPA. E CAPTCHAs, em pequena escala, eu mesmo posso resolver. Ultimamente, quando aparece um CAPTCHA, recebo um alerta no Discord, resolvo no notebook e deixo o scraping continuar. Como o app “World Garden” controla até os webtoons pelos quais paguei, acho que preciso controlar meus próprios dados
Na verdade, mesmo o JSON de 1 KB, na web moderna, acaba exigindo baixar megabytes de JavaScript para executar e só então mostrar os dados. O que eu quero é simplesmente receber 10 a 20 KB de HTML, um pouco de CSS e os arquivos de imagem. Com vídeo, bastaria baixar diretamente em mp4 e pronto. É simples e eficiente, mas a conversa muda quando a intenção é vender alguma coisa
Toda essa complexidade existe pelo mesmo motivo: vender mais anúncios
Nsig/sig: é um token especial que precisa obrigatoriamente estar incluído na chamada de API. Ele é gerado no base.js (código do player), e clientes de terceiros como o yt-dlp precisam extrair isso por bypass. Antigamente era possível obter o token puxando apenas partes do código com regex e afins, mas agora o código está tão espalhado que já é preciso executar o base.js inteiro para obtê-lo
PoToken: é o comprovante de origem que o Google reforçou recentemente. Sem ele, ocorre erro 403. No Android usa-se DroidGuard, no iOS um módulo embutido para apps, e na web é necessário executar código JS (challenge). Antes precisava ser emitido por ferramentas externas, mas com a atualização baseada em Deno do yt-dlp, em breve deve poder ser embutido
SABR: tecnologia de streaming adaptativo de bitrate no lado do servidor, usada junto com o protocolo UMP do Google, em que o servidor recebe a posição de reprodução e o estado do buffer para controlar o buffering ideal e até a inserção de anúncios. O suporte em clientes de terceiros ainda está em andamento
Exemplos de extração de Nsig/sig:
Guia do PoToken:
SABR:
(links de guias e exemplos de código adicionais atualizados)
Agora entendo por que Google e Cloudflare querem limitar a web a apenas alguns navegadores assinados e com integridade verificada
Sobre o PoToken na web, fico curioso como rodar um snippet JS prova que você não é um bot. Se for apenas JS do lado do cliente, isso não funcionaria também em um Chromium headless?
Já começaram a aparecer métodos de bypass logo depois da introdução disso pelo Google. Mesmo uma big tech não consegue impedir de verdade o bypass se for entregar o conteúdo ao cliente. É por isso que todos eles querem construir ecossistemas fechados e proprietários — assim conseguem forçar você a ver os anúncios até o fim ou cobrar pelo acesso
Outro dia apareceu no HN a ideia de que o YouTube quer que ferramentas de download continuem funcionando texto relacionado 1 texto relacionado 2. O YouTube opera um serviço global com 3 bilhões de usuários e passa a impressão de não querer bloquear downloads completamente, mas sim bloquear “na medida certa”. Acho que se todos no mundo usassem iPhones ou Androids recentes, eles colocariam DRM imediatamente
O yt-dlp usa a API de smart TVs antigas. Como esses aparelhos já não recebem mais atualizações de software, se esse tráfego desaparecer essa funcionalidade também pode acabar
Acho que a teoria da conspiração de que uma plataforma de conteúdo deseja suportar downloads mesmo prejudicando seu próprio modelo de receita não faz sentido nenhum
O player e a página do YouTube estão ficando tão pesados que, em PCs antigos, a situação ficou ironicamente mais lenta. Recentemente troquei “watch?v=” por “/embed/” e assisti em 480p, mas quando baixo o mesmo vídeo e vejo localmente, o uso de CPU fica em torno de 3%. Só que até isso está deixando de funcionar direito aos poucos. Enquanto isso, outros sites (por exemplo, sites pornôs) se preocupam mais em otimizar a experiência e nem ligam tanto para bloquear ferramentas de download
Vídeo (normal)
Vídeo (embed)
O GitHub também sofre do mesmo problema de falta de otimização; num PC com i5 de 8ª geração já fica quase inutilizável. Então eu simplesmente tiro snapshots e consulto tudo offline
Hoje em dia a degradação de desempenho do YouTube acontece porque estão forçando todo mundo a usar apenas codecs pesados e modernos. Meu notebook roda vídeo 4K em h264 sem problema, mas basta assistir a um vídeo 720p no YouTube para ele esquentar e travar. Dá para bloquear certos codecs com a extensão h264ify, mas é frustrante não poder ajustar esse comportamento básico. Acaba sendo mais confortável e confiável simplesmente baixar o vídeo e assistir assim
Não é só comigo. No 1º trimestre de 2025 eu ainda assistia pelo player embedado, mas no 3º trimestre o Google passou a bloquear isso de propósito. Hoje em dia só consigo acessar o YouTube via yt-dlp. Vida longa ao yt-dlp e aos seus desenvolvedores
Estou pensando em sair do YouTube e migrar para plataformas baseadas em PeerTube/p2p
Há relatos de que o QuickJS (interpretador JS leve) é tão lento que leva mais de 20 minutos por vídeo. O Deno é muito mais rápido, e fico me perguntando como essa diferença pode ser tão grande
(referência issue #14404 / resposta)
O QuickJS é um interpretador baseado em bytecode — lento como Python — priorizando simplicidade e estabilidade. Já o Deno usa um compilador JIT altamente eficiente, em nível Chrome, e por causa disso, especialmente em certos tipos de código, a diferença de desempenho pode passar de 20x. O QuickJIT (um fork do QuickJS com JIT adicionado usando TCC) talvez ainda seja mais lento que o Deno, mas tem espaço para melhorar
É assustador pensar que o desempenho ficou tão dramaticamente pior a ponto de parecer que o Google fez isso de propósito para ficar lento em outros interpretadores
Curioso. O Minecraft (Bedrock, para modding) usa QuickJS, e embora ele seja mais lento que o V8, não parece uma diferença tão extrema assim
Agora os sinais de que a era do ripping fácil está acabando são claros. Se houver vídeos do YT que você quer preservar a longo prazo, recomendo instalar algo como o tubearchivist agora mesmo e fazer backup
Também recomendo o pinchflat GitHub do Pinchflat como alternativa. É menos polido que o tubearchivist, mas na minha experiência tem menos bugs
Acho que este é o último momento para preservar o patrimônio cultural e educacional valioso que o YT acumulou graças ao monopólio de mercado. O tubearchivist parece interessante, mas a instalação e a manutenção parecem bem trabalhosas, o que me desanima. Além disso, ele é orientado a baixar canais inteiros assinados. No meu caso, se eu já tiver apenas uma pasta com os downloads, para mim bastaria uma solução superleve de servidor web local que interpretasse os nomes dos vídeos e gerasse páginas com links. Se houver alguma alternativa ultraleve que se instale em poucos cliques, aceito recomendações
O YouTube Movies já usa uma solução de DRM, então também fico curioso sobre por que essa tecnologia ainda não foi aplicada a todos os canais
Fiquei surpreso com a escolha do Deno, mas ele facilita a distribuição em um único executável, reduzindo problemas de instalação. O interpretador baseado em Python era um hack impressionante, mas tinha limites, e esse assunto já havia sido discutido no antigo projeto Youtube-dl discussão antiga no HN
O Node não tem recursos de segurança e isolamento como o Deno. Dá para ver opiniões semelhantes do mantenedor na mesma thread
O recurso de sandbox do Deno também é um motivo importante para a escolha. Não dá para confiar 100% nisso, mas ainda é melhor do que não ter nada
O yt-dlp não suporta só o YouTube, mas também inúmeros outros sites de streaming de vídeo, às vezes perigosos. Portanto, algum nível mínimo de sandboxing como o de um navegador é indispensável. Como ele acaba executando código não confiável por design, precisa garantir uma base de segurança