- Damit YouTube-Downloads mit yt-dlp weiterhin zuverlässig funktionieren, wird in Kürze die Installation von Deno (oder einer unterstützten JavaScript-Laufzeit) verpflichtend
- Durch jüngste Änderungen auf YouTube-Seite lassen sich die JS-Challenges nicht mehr allein mit dem eingebauten JavaScript-"Interpreter" lösen
- Nutzer der PyInstaller-Binaries benötigen lediglich Deno; bei Verwendung des PyPI-Pakets sind zusätzliche JavaScript-Komponenten erforderlich
- Unterstützung für andere JavaScript-Laufzeiten wie Node oder Bun bleibt grundsätzlich möglich, doch nur Deno gilt derzeit in Bezug auf Sicherheit und Sandboxing als geeignet
- Für die Installation von Deno und zugehörigen Abhängigkeiten sowie zur Pfadangabe sollen separate Optionen und Anleitungen bereitgestellt werden
Änderungen bei YouTube-Downloads in yt-dlp und neue Anforderungen angekündigt
Hintergrund der neuen Anforderungen
- In naher Zukunft wird für die ordnungsgemäße Nutzung der YouTube-Download-Funktion zwingend die Installation von Deno oder einer anderen unterstützten JavaScript-Laufzeit erforderlich
- Bisher hat yt-dlp mithilfe eines eingebauten JavaScript-Interpreters die JS-Challenges von YouTube gelöst, doch durch die jüngsten Änderungen an YouTubes interner Logik funktioniert dieser Ansatz allein nicht mehr
- Der Umfang der Änderungen ist so groß, dass yt-dlp für einen zuverlässigen Betrieb zwingend einen Algorithmus auf Basis einer vollwertigen JavaScript-Laufzeit nutzen muss, um YouTube-Anfragen weiterhin erfolgreich abwickeln zu können
Vorbereitung und Vorgehen je nach Nutzergruppe
- Deno (oder eine unterstützte JS-Laufzeit) installieren
- Weitere unterstützte Laufzeiten sollen später etwa über die FAQ bekanntgegeben werden
- Möglicherweise müssen einige von yt-dlp benötigte JavaScript-Komponenten installiert werden
- Ob zusätzliche Schritte nötig sind, hängt von der Installationsmethode und der Distributionsform von yt-dlp ab
Checkliste nach offizieller Distribution
- Offizielle mit PyInstaller bereitgestellte ausführbare Dateien (
yt-dlp.exe, yt-dlp_macos, yt-dlp_linux usw.)
- Es muss nur Deno installiert werden; zusätzliche Komponenten sind bereits in der ausführbaren Datei enthalten
- PyPI-Paket (
pip, pipx usw.)
- yt-dlp muss mit der Abhängigkeitsgruppe
default installiert und auf die neueste Version aktualisiert werden
- Beispiel:
pip install -U "yt-dlp[default]"
- Offizielle zipimport-Binary (Unix-
yt-dlp)
- Es wird ein zusätzlicher Schalter benötigt, damit Deno npm-Abhängigkeiten herunterladen kann
- Alternativ muss ein separates JS-Solving-Paket für yt-dlp in der Python-Umgebung installiert werden (Option und Paketname werden später bekanntgegeben)
- Pakete von Drittanbietern (
pacman, brew usw.)
- Je nach Richtlinien der jeweiligen Distribution können unterschiedliche Maßnahmen nötig sein, es lässt sich aber die Vorgehensweise für Nutzer der zipimport-Binary anwenden
Diskussion zu Laufzeiten und Sicherheit
- Eine Unterstützung alternativer JS-Laufzeiten wie Node oder Bun ist grundsätzlich möglich, allerdings bieten diese Laufzeiten derzeit nicht dieselben Sicherheits- und Sandboxing-Funktionen wie Deno
- Ob künftig weitere JS-Laufzeiten unterstützt werden, ist noch in Diskussion; bis zur endgültigen Entscheidung orientieren sich die Hinweise an Deno als Standard
Zusätzliche Hinweise zur Deno-Installation
- Genau wie yt-dlp lässt sich auch Deno als einzelne ausführbare Datei von GitHub beziehen und durch Ablegen im Pfad verwenden
- Künftig soll in yt-dlp die Option
--js-runtimes eingeführt werden, mit der sich der Pfad zur Deno-Datei angeben lässt (Optionsname und Verwendung können sich noch ändern)
- Wird Deno etwa per Curl heruntergeladen und im gleichen Ordner wie die yt-dlp-Binary abgelegt, sollte der Betrieb problemlos möglich sein
FAQ und weitere Hinweise
- Je nach verwendetem Betriebssystem oder Paketmanager kann es nötig sein, PATH anzupassen
- Unter Linux und in ähnlichen Umgebungen kann Deno je nach Konfiguration automatisch zu PATH hinzugefügt werden
- Weitere Fragen und Installationsprobleme sollen über FAQ oder die Community unterstützt werden
Weitere Community-Reaktionen und kommende Updates
- Einige Nutzer fragen bereits nach möglichen Auswirkungen wie dem Ende der Unterstützung für 32-Bit-Systeme oder Änderungen bei Distributionsoptionen
- Das yt-dlp-Entwicklerteam bereitet auf Basis von Issues, Patches und Community-Feedback bessere Hinweise und Unterstützungsmaßnahmen vor
Fazit und Zusammenfassung
- Durch Änderungen an YouTubes Systemarchitektur ändern sich Funktionsweise und Systemanforderungen von yt-dlp deutlich
- Die wichtigste Änderung: Wer YouTube-Downloads weiterhin normal nutzen möchte, muss künftig Deno oder eine JS-Laufzeit bereitstellen
- Je nach offizieller Distributionsform ist eine schnelle Reaktion gemäß den jeweiligen Hinweisen erforderlich
- Weitere Hinweise, FAQ und Installationsanleitungen sollen fortlaufend ergänzt werden
1 Kommentare
Hacker-News-Kommentare
Ich bin zahlender YouTube-Premium-Abonnent. Letztes Wochenende wollte ich im Zug Videos herunterladen, die Downloads blieben aber sowohl auf dem iPad als auch auf dem iPhone bei „Warten auf Download..“ hängen. Auch ein Neustart half nicht, also habe ich es nach einer Stunde aufgegeben. Am Ende habe ich die Videos mit yt-dlp geholt, auf einen USB-C-Flash-Drive kopiert und so angesehen. Wenn demnächst wirklich eine „Einschränkung beim Teilen von Premium in Familien“ kommt, kündige ich dann endgültig. Meine Familie nutzt die werbefreie Umgebung nämlich sehr gern.
Ich bin auch Premium-Abonnent und habe auf der iPad-App ein ähnliches Problem. Selbst wenn ich Videos für mein Baby herunterladen will, klappt es nicht zuverlässig auf Anhieb. Das hat mich so genervt, dass ich mir gebraucht ein Samsung Galaxy Tab A7 gekauft und LineageOS als Custom-ROM installiert habe. Auf einer 1-TB-SD-Karte habe ich jetzt alle gewünschten Medien und spiele sie problemlos mit VLC ab. Zusätzlich kann NewPipe aus dem F-Droid-Store YouTube-Videos viel zuverlässiger herunterladen als die offizielle App. Ursprünglich wollte ich die Medien mit etwas wie yt-dlp befüllen, aber inzwischen brauche ich das nicht mehr.
Ich bezahle zwar für YouTube Premium, schaue auf dem Smartphone aber mit ReVanced, weil ich die automatische Übersetzung deaktivieren muss. Ich verstehe nicht, warum man das in der offiziellen App nicht selbst einstellen kann.
Wenn man ein Video auf YouTube hochlädt und es dann im Creator-Dashboard herunterladen will — etwa nach einem Livestream ohne lokales Backup oder wenn der Rechner gerade ausgelastet ist — bekommt man es nur in 720p mit niedriger Qualität. Mit yt-dlp bekommt man dagegen die bestmögliche Qualität.
Ich habe mein Abo gekündigt, weil die werbefreie Nutzung in YouTube Kids nicht funktionierte (ich nutze ein ShieldTV). Wahrscheinlich war es ein Bug, aber ohne Kundensupport konnte ich nichts machen. Ich hatte früher ein bezahltes Play-Music-Abo und wurde dann zu YouTube migriert — das war für mich wirklich die letzte Enttäuschung.
Falls du auf Neuigkeiten zur Familienfreigabe-Beschränkung gewartet hast: Dazu gibt es bereits Berichte. Ich habe von YouTube auch eine entsprechende E-Mail bekommen. Momentan nutze ich noch alles ohne Werbung, aber wann es wirklich umgesetzt wird, weiß ich nicht. Siehe diesen Artikel.
Ich bin beeindruckt von der Entwicklungsarbeit, die in den „JavaScript-Interpreter“ von yt-dlp geflossen ist: yt-dlp jsinterp.py
Das ist genau der richtige Ansatz für das Problem. Dass sie es ohne nennenswerten Overhead bis hierhin gebracht haben, ist wirklich beeindruckend.
Das ist der eigentliche, versteckte Kern dieser Ankündigung. Mir war nicht klar, dass die Struktur schon so komplex geworden ist, und ich bin sehr beeindruckt.
Es wird nur ein Teil von JavaScript interpretiert. Siehe auch diese HN-Diskussion: Link
Ich habe kurz in den Code geschaut und dabei Python
ChainMapkennengelernt.Ich frage mich, wie viel JavaScript tatsächlich interpretiert wird und ob man die unter 1.000 Zeilen Code vielleicht im Compiler-Einführungskurs verwenden könnte.
Ich bin seit über 30 Jahren ein „digital hoarder“ und sammle digitale Medien. Physische Medien wie VHS oder DVDs habe ich nicht, bei mir ist alles digital archiviert. Darunter sind auch ein paar seltene oder möglicherweise verschwindende Stücke. Meine Frau fand mein System, das „Netflix zu Hause“ nachbildet, irgendwann ebenfalls interessant und mochte das werbefreie Schauen. Ich hielt mich nie für etwas Besonderes und dachte, alle würden einfach Streaming nutzen. Seit Jahren sage ich Leuten in meinem Umfeld: „Wenn ich eine Sendung habe, die du magst, sag Bescheid.“ In den letzten zwei Jahren wollten Familie und Freunde zunehmend Zugriff auf meinen Jellyfin-Server oder baten mich, kleine Server unter ihren Fernsehern einzurichten. Kürzlich habe ich zu Jellyfin auch das Archivieren von YouTube-Kanälen hinzugefügt und lade Videos pro Kanal automatisch mit einem Verzeichnis und einem yt-dlp-Befehl herunter. Allerdings bekomme ich sie nicht in dem von mir gewünschten h264-Codec und kodiere sie deshalb neu. YouTube liefert die Videos in AV1 aus, aber meine Smart-TVs unterstützen diesen Codec noch nicht, also kodiere ich selbst um.
Früher hatte ich nur ein simples Skript, inzwischen nutze ich aber ytdltt: ytdltt GitHub. Darüber kann meine Mutter per Telegram-Bot YouTube-Inhalte wie Hörbücher anfordern; die Downloads werden nach Verzeichnissen sortiert und sind dann über Jellyfin erreichbar. Allein die Hörbücher, die meine Mutter in drei Jahren gesammelt hat, belegen etwa 1,2 TB.
Für einen ähnlichen Zweck kann man sich auch tubesync ansehen.
Wenn du keine h264-Inhalte herunterladen konntest: Die yt-dlp-Dokumentation fand ich auch schwer zugänglich, aber aktuell funktioniert so etwas ganz gut:
yt-dlp -f "bestvideo[width<800][vcodec~='^(avc|h264)']+bestaudio[acodec~='^((mp|aa))']"Vor Kurzem habe ich Pinchflat entdeckt: Pinchflat GitHub. Es ist eine Web-Alternative im *arr-Stil und nutzt yt-dlp im Backend. Man fügt die gewünschten Videos einer Playlist hinzu, und sie werden automatisch heruntergeladen.
Mich würde interessieren, ob man Dinge wie Cookies hinterlegen muss, um Bot-Erkennung zu umgehen, und ob dafür auch ein VPN nötig ist.
Die Zeit, in der man im Web einfach Daten abrufen konnte, ist vorbei — jetzt muss man Tausende Zeilen obfuskiertes JavaScript ausführen. Früher konnte man problemlos eine 1-kB-JSON-Datei holen und cachen, heute muss man einen ganzen Browser starten, für 100 Requests 10 MB Daten hin- und herschieben, und die Analyse- sowie Sicherheitsprofile werden völlig chaotisch. Das ist für alle schlechter.
Positiv betrachtet eröffnet diese Unbequemlichkeit ein Geschäftsmodell für 10.000 Scraping-Firmen, die 10 MB Müll einsammeln und dann als brauchbare API anbieten. Allerdings sinkt inzwischen auch die Qualität der Website-Inhalte, sodass solche Fragen allmählich weniger relevant werden.
Das Web wirkt inzwischen wie ein endloses Spiel aus Scraping, Anti-Scraping und Umgehung. Mit AI/LLMs kann man aber — wenn auch teurer — inzwischen praktisch jede Information extrahieren. Bald werden LLMs wohl auch jede CAPTCHA lösen. Vielleicht sind „analoge Löcher“ dann dauerhaft offen: Eine Kamera und ein Mikrofon auf Bildschirm und Ton gerichtet, und die KI interpretiert alles besser als ein Mensch.
Zum Glück ist kleinmaßstäbliches Scraping mit Tools wie yt-dlp heute einfacher denn je. Mit ein oder zwei Stunden Aufwand kann man mit headless Firefox und mitmproxy leicht ein Skript bauen, und solange ich nicht im großen Stil mit mehreren VPS eine ganze Website absauge, kann ich die Inhalte, die ich will, problemlos archivieren. Cloudflare blockiert normale Nutzer mit geringem Volumen auch nicht. Moderne Browser-Automatisierung ist leicht genug, dass Einzelpersonen selbst SPAs problemlos scrapen können. CAPTCHAs kann man in kleinem Umfang auch manuell lösen. Ich bekomme inzwischen bei einer CAPTCHA sogar eine Discord-Benachrichtigung, löse sie am Laptop und lasse das Scraping dann weiterlaufen. Eine kostenpflichtig gekaufte Webtoon-Sammlung wird von der „World Garden“-App kontrolliert, und ich finde, meine Daten sollten unter meiner Kontrolle stehen.
Selbst für 1-kB-JSON muss man im modernen Web de facto erst MB an JavaScript laden und ausführen, damit die Daten angezeigt werden. Ich will eigentlich nur 10–20 kB HTML, etwas CSS und Bilddateien. Videos kann man direkt als mp4 herunterladen, dann ist es erledigt. Das wäre simpel und effizient — aber sobald man etwas verkaufen will, sieht die Sache anders aus.
Der Grund für diese ganze Komplexität ist letztlich, mehr Werbung zu verkaufen.
Nsig/sig — ein spezielles Token, das bei API-Aufrufen zwingend mitgeschickt werden muss. Es wird aus
base.js(dem Player-Code) generiert, und Dritt-Clients wie yt-dlp müssen es durch Reverse Engineering extrahieren. Früher reichte es, mit Regex oder ähnlichem einen Teil des Codes herauszuziehen, heute ist die Logik so verteilt, dass praktischbase.jskomplett ausgeführt werden muss, um das Token zu bekommen.PoToken — ein neuerer Herkunftsnachweis-Token, den Google verschärft hat. Fehlt er, gibt es einen 403-Fehler. Unter Android ist dafür DroidGuard zuständig, unter iOS ein eingebautes App-Modul, im Web muss JavaScript-Code (eine Challenge) ausgeführt werden. Früher musste man den Token mit externen Tools beschaffen; mit dem Deno-basierten Update von yt-dlp soll das bald integriert werden können.
SABR — eine serverseitige adaptive Bitraten-Streaming-Technik, die zusammen mit Googles UMP-Protokoll verwendet wird. Der Server erhält Wiedergabeposition und Buffer-Status und steuert damit optimales Buffering und sogar die Werbeeinblendung. Support für Dritt-Clients ist noch in Arbeit.
Beispiel für Nsig/sig-Extraktion:
PoToken-Leitfaden:
SABR:
(weitere Codebeispiele und Guide-Links wurden aktualisiert)
Jetzt verstehe ich, warum Google und Cloudflare das Web auf wenige signierte Browser mit Integritätsprüfung beschränken wollen.
Mich würde bei PoToken im Web interessieren, wie ein ausgeführtes JS-Snippet beweisen soll, dass man kein Bot ist. Wenn es einfach nur Client-JS ist, müsste es doch auch in headless Chromium laufen, oder?
Google hat das gerade erst eingeführt, und es gibt schon Umgehungen. Selbst für große Konzerne gilt: Sobald Inhalte an den Client ausgeliefert werden, lassen sie sich am Ende umgehen. Deshalb wollen alle geschlossene proprietäre Ökosysteme schaffen — damit sie Werbung bis zum Ende ausspielen oder Nutzungsgebühren kassieren können.
Vor Kurzem gab es auf HN auch die Behauptung, YouTube wolle, dass Download-Tools funktionieren: Artikel 1 Artikel 2. YouTube betreibt einen globalen Dienst mit 3 Milliarden Nutzern und wirkt dabei so, als wolle es Downloads nie vollständig blockieren, sondern immer nur „gerade genug“. Wenn weltweit alle Nutzer aktuelle iPhones oder Android-Geräte hätten, würden sie wahrscheinlich sofort überall DRM aktivieren.
yt-dlp nutzt die API für ältere Smart-TVs. Diese Geräte bekommen keine Software-Updates mehr, also könnte diese Funktion verschwinden, sobald dieser Traffic wegfällt.
Ich halte die Verschwörungstheorie, dass Content-Plattformen Downloads unterstützen wollten, obwohl das ihr Geschäftsmodell beschädigt, für völlig unlogisch.
Der YouTube-Player und die Seiten werden immer schwergewichtiger, sodass sie auf älteren PCs paradoxerweise langsamer laufen. Ich habe zuletzt
watch?v=durch/embed/ersetzt und so in 480p geschaut; lädt man dasselbe Video herunter, liegt die CPU-Auslastung nur bei etwa 3 %. Aber selbst das funktioniert zunehmend schlechter. Andere Seiten (z. B. Porno-Seiten) kümmern sich dagegen um eine optimierte Nutzererfahrung und interessieren sich kaum dafür, Download-Tools zu blockieren.Video (normal)
Video (embed)
Bei GitHub ist es ähnlich unoptimiert; auf einem PC mit i5 der 8. Generation ist es fast unbenutzbar. Deshalb mache ich inzwischen einfach Snapshots und schaue sie mir offline an.
Der Grund für die schlechte YouTube-Performance heute ist, dass alle gezwungen werden, nur noch moderne schwere Codecs zu verwenden. Mein Laptop kann 4K-h264-Videos problemlos abspielen, aber schon bei einem 720p-YouTube-Video wird er heiß und beginnt zu ruckeln. Mit der Browser-Erweiterung
h264ifykann man bestimmte Codecs blockieren, und ich frage mich, warum man so ein Standardverhalten nicht direkt steuern kann. Einfach das Video herunterzuladen und anzusehen ist oft bequemer und stabiler.Das geht nicht nur mir so. Im ersten Quartal 2025 habe ich noch über den Embed-Player geschaut, aber im dritten Quartal hat Google den Embed-Player absichtlich blockiert. Aktuell kommt man an YouTube nur noch mit yt-dlp heran. Lang lebe yt-dlp und sein Entwicklerteam.
Ich denke darüber nach, YouTube zu verlassen und zu PeerTube bzw. Peer-basierten Plattformen zu wechseln.
Es gibt Berichte, dass QuickJS (ein leichtgewichtiger JS-Interpreter) so langsam ist, dass er pro Video über 20 Minuten braucht. Deno ist viel schneller — ich frage mich, wie dieser Unterschied so groß sein kann.
(siehe Issue #14404 / Antwort)
QuickJS ist ein Bytecode-basierter Interpreter — wie Python eher langsam — und priorisiert Einfachheit und Stabilität. Deno nutzt dagegen einen hocheffizienten JIT-Compiler auf Chrome-Niveau, und dadurch kann die Ausführung in bestimmten Code-Situationen leicht mehr als 20-mal schneller sein. QuickJIT (ein Fork von QuickJS mit zusätzlichem JIT über TCC) wäre wohl immer noch langsamer als Deno, könnte aber Verbesserungen bringen.
Es ist schon fast unheimlich, dass die Performance so drastisch eingebrochen ist — fast so, als hätte Google absichtlich dafür gesorgt, dass es in anderen Interpretern langsam läuft.
Interessant. In Minecraft (Bedrock, fürs Modding) nutzt man QuickJS; es ist zwar langsamer als V8, aber so extrem wirkt der Unterschied dort nicht.
Es ist inzwischen ziemlich klar, dass die Zeit des einfachen Rippens zu Ende geht. Wenn es YouTube-Videos gibt, die du langfristig behalten willst, solltest du jetzt sofort etwas wie tubearchivist aufsetzen und Backups machen.
Ich empfehle auch pinchflat: Pinchflat GitHub. Es ist weniger ausgereift als tubearchivist, hat meiner Erfahrung nach aber weniger Bugs.
Die kulturellen und Bildungswerte, die YouTube durch seine marktbeherrschende Stellung angesammelt hat, lassen sich meiner Meinung nach vielleicht nur noch jetzt retten. tubearchivist sieht interessant aus, wirkt aber beim Aufsetzen und im Betrieb ziemlich aufwendig, und das schreckt mich ab. Außerdem ist es auf das Herunterladen ganzer Abokanäle ausgerichtet. Mir würde schon eine sehr leichte lokale Webserver-Lösung reichen, die einfach nur vorhandene Download-Ordner nimmt, Videonamen interpretiert und daraus Link-Seiten baut. Wenn jemand eine ultraleichte Alternative kennt, die sich mit wenigen Klicks installieren lässt, wäre ich dankbar.
Für YouTube-Filme gibt es schon DRM-Lösungen — ich frage mich, warum diese Technik nicht längst für alle Kanäle ausgerollt wurde.
Dass Deno gewählt wurde, hat mich überrascht, aber Deno lässt sich leicht als einzelne ausführbare Datei verteilen, was Installationsprobleme reduziert. Der Python-basierte Interpreter war ein beeindruckender Hack, hatte aber Grenzen, und darüber wurde schon im alten Youtube-dl-Projekt diskutiert: frühere HN-Diskussion
Node hat nicht dieselben Sicherheits- und Isolationsfunktionen wie Deno. Im selben Thread findet man auch Kommentare der Maintainer dazu.
Die Sandbox-Funktionen von Deno waren sicher ebenfalls ein wichtiger Grund für die Wahl. Hundertprozentig vertrauen würde ich ihnen zwar nicht, aber sie sind besser als gar nichts.
yt-dlp unterstützt nicht nur YouTube, sondern auch viele andere — manchmal riskante — Video-Streaming-Seiten. Deshalb ist wenigstens ein Mindestmaß an Sandbox wie im Browser unverzichtbar. Das Design sieht nun einmal vor, potenziell nicht vertrauenswürdigen Code auszuführen; grundlegende Sicherheit muss also gegeben sein.