yt-dlp: Externe JavaScript-Laufzeit ist jetzt Pflicht für vollständige YouTube-Unterstützung

 (github.com/yt-dlp)
12 Punkte von GN⁺ 2025-11-13 | 2 Kommentare | Auf WhatsApp teilen
  • yt-dlp ist ein kommandozeilenbasiertes Download-Tool, mit dem sich Audio und Video von Tausenden von Websites herunterladen lassen, und eine Fork-Version von youtube-dl
  • Für die n/sig-Entschlüsselung von YouTube werden das neu hinzugefügte Modul yt-dlp-ejs sowie eine externe JavaScript-Laufzeit benötigt, z. B. Deno, Node.js, Bun oder QuickJS
  • Deno ist als Standard-Laufzeit gesetzt; mit der Option --js-runtimes können Nutzer andere Laufzeiten angeben
  • Durch diese Änderung sind für die vollständige Nutzung der YouTube-bezogenen Funktionen nun die Installation von yt-dlp-ejs und einer JS-Laufzeit zwingend erforderlich
  • Die zusätzliche Abhängigkeit von einer externen Laufzeit ist eine notwendige Maßnahme als Reaktion auf Änderungen an YouTubes Verschlüsselungsstruktur und wird künftig ein Kernelement der Wartung sein

Überblick über yt-dlp

  • yt-dlp ist eine Fork von youtube-dl und ein Projekt, das auf dem nicht mehr gepflegten youtube-dlc basiert
  • Es kann Audio und Video von Tausenden von Websites herunterladen und unterstützt verschiedene Funktionen für Formatwahl, Nachbearbeitung, Untertitel und Plugins

Änderungen bei der YouTube-Unterstützung

  • Für die Entschlüsselung der n/sig-Werte von YouTube wird das Paket yt-dlp-ejs benötigt
    • Dieses Paket wird unter der Unlicense veröffentlicht und enthält Komponenten unter MIT- und ISC-Lizenz
  • Für die Ausführung von yt-dlp-ejs ist eine JavaScript-Laufzeit zwingend erforderlich
    • Unterstützte Laufzeiten: deno (empfohlen), node.js, bun, QuickJS
    • Die entsprechende Konfiguration kann mit der Option --js-runtimes festgelegt werden
  • Mit der Option --no-js-runtimes lässt sich die Standardkonfiguration der Laufzeiten zurücksetzen

Installation und Abhängigkeiten

  • yt-dlp unterstützt Python 3.10+ (CPython) und 3.11+ (PyPy)
  • Dringend empfohlene Abhängigkeiten:
    • ffmpeg / ffprobe: zum Zusammenführen von Audio und Video sowie für die Nachbearbeitung
    • yt-dlp-ejs: zum Entschlüsseln der YouTube-Verschlüsselung
    • JavaScript-Laufzeit: zur Ausführung von yt-dlp-ejs
  • Zu den optionalen Netzwerk-Abhängigkeiten gehören certifi, brotli, requests, curl_cffi und weitere

Wichtige Befehlsoptionen

  • --js-runtimes RUNTIME[:PATH]: verwendete JS-Laufzeit festlegen
  • --no-js-runtimes: alle JS-Laufzeiten deaktivieren
  • --remote-components COMPONENT: Option, mit der externe JS-Komponenten erlaubt werden können
  • --no-remote-components: Laden entfernter Komponenten blockieren

Bedeutung

  • Mit dieser Änderung verlangt yt-dlp nun zwingend eine externe JS-Laufzeit, um YouTubes aktuelle Verschlüsselungsstruktur vollständig zu unterstützen
  • Das ist ein struktureller Wechsel, um auf YouTubes fortlaufende Sicherheits- und Verschlüsselungsupdates zu reagieren, und eine zentrale Änderung für künftige Wartung und Funktionserweiterungen

Verwandte Beiträge

2 Kommentare

 
kimjoin2 2025-11-14

Wow … Es ist beeindruckend, wie gut sie das blockieren, und genauso beeindruckend, wie es umgangen wird. Wie analysieren sie das bloß und durchbrechen es?
 
GN⁺ 2025-11-13
Hacker-News-Kommentare

  • Ist im Arch-Repository bereits enthalten und funktioniert daher sofort.
    Man muss dem Befehl yt-dlp --cookies-from-browser firefox --remote-components ejs:github ... nur ein Flag hinzufügen.
    Beim Ausführen wird der Solver zur Laufzeit heruntergeladen, was nur etwa 0,5 Sekunden dauert. Es fühlt sich an, als sei der Download-Start deutlich schneller geworden.
    Wenn man es jedoch in eingeschränkten Umgebungen ausführt, wäre es schön, den Solver vorab mit einem separaten Befehl herunterladen zu können. So ist es schon gut, aber mit Packaging-Automatisierung wäre es noch bequemer.

    • Schön zu hören, dass es schneller geworden ist. Heutzutage läuft YouTube nicht einmal mehr im Browser richtig, daher ist es beeindruckend, dass das Team den Zugriff per Python-Skript weiter möglich macht.
    • Ich frage mich, in welcher Umgebung Python funktioniert, JS aber nicht.
      Falls die Sicherheit ein Problem ist: Solange man Deno verwendet, ist die Sandboxing-Umsetzung recht solide.
      Falls das OS Deno oder Node nicht unterstützt, könnte man auch QuickJS in Betracht ziehen, das in C geschrieben ist. Es ist zwar langsam, läuft aber in fast jeder Umgebung.
      In diesem Fall fällt das Sandboxing allerdings weg. Trotzdem halte ich den Code für vertrauenswürdig, wenn er von der offiziellen YouTube-Domain ausgeliefert wird.
    • Wenn man den Solver vorab haben möchte, kann man nach dem Download eines beliebigen Videos die ejs-Datei aus dem Cache-Verzeichnis von yt-dlp kopieren, zum Beispiel aus /home/username/.cache.
      Alternativ könnte man mit make yt-dlp-extra Packaging-Automatisierung ausprobieren.
    • Das yt-dlp-ejs-Paket im AUR scheint genau für diesen Zweck gedacht zu sein.
    • Ich habe Deno manuell über Chocolately installiert und yt-dlp ebenfalls über choco, die Version ist v2025.10.22.

  • Vor Kurzem hat YouTube damit begonnen, bei eingebetteten Videos den Referrer-Header zu erzwingen.
    Wenn man youtube.com/embed/<videoid> direkt aufruft, erscheint ein Fehler, und in der FAQ steht ausdrücklich, dass dies beabsichtigt ist.
    Laut der offiziellen Dokumentation muss der Einbettende einen HTTP-Referer mitsenden, sonst erscheint der Bildschirm mit „error 153“.

    • Die meisten Embed-Dienste entwickeln sich zunehmend in diese Richtung. Ziel ist eine verstärkte Nachverfolgung. In manchen Fällen wird sogar ein Login verlangt.
    • Eigentlich lässt sich das mit einer simplen einzeiligen JS-Weiterleitung umgehen. Die Implementierung kostet Hunderttausende Dollar, die Umgehung kostet 0. Am Ende wirkt es wie die Botschaft: „Wenn wir wollen, können wir euch jederzeit blockieren.“

  • Als 1991 QuickTime erschien, hielt ich es für selbstverständlich, Videos einfach kopieren, einfügen und speichern zu können.
    Heute ist es kaum zu glauben, wie schlecht die User Experience selbst bei Videos ohne DRM geworden ist.

    • Heute ist es viel besser als früher. Damals hat man RealPlayer, Flash, Codec-Packs und Ähnliches installiert und sich dabei oft das System mit Adware ruiniert.
      Heute reicht in den meisten Fällen der Standard-Player des OS oder VLC.
    • Die frühen 90er waren die spannendste Zeit für PCs. Heute, wo Smartphones dominieren, ist das Konzept von Kopieren/Speichern für normale Nutzer im Grunde nur noch in Form von Screenshots oder Bildschirmaufnahmen übrig.
    • Videos haben eine hohe Datendichte, deshalb sind die Hosting-Kosten hoch. Darum sind im Wesentlichen nur große Plattformen wie YouTube übrig geblieben, während Alternativen wie Nebula, PeerTube und Odysee bei Qualität oder Kosten an Grenzen stoßen.
    • Früher war das Ziel eine nutzerzentrierte Optimierung, heute leben wir in einer Zeit, in der Unternehmen zuerst an den eigenen Vorteil denken.
    • Auch beim Broadcast-Standard ATSC 3 gab es Probleme, weil DRM spät hinzugefügt wurde und bestehende Empfänger dadurch inkompatibel wurden.

  • Ich nutze yt-dlp seit 2010, einschließlich der youtube-dl-Zeit, und archiviere damit alle Videos, die mir gefallen.
    Inzwischen habe ich Zehntausende Videos gespeichert, und viele davon sind bereits von der Website verschwunden.
    Auch Videos wie die NHK-Sumo-Highlights, die nur einen Monat lang verfügbar sind, speichere ich.

    • Das könnte man als digitalen Sammeltrieb bezeichnen. Es wäre interessant, eine Funktion ähnlich Google Memories zu bauen, die einen regelmäßig an alte Videos erinnert.
    • Viele Kanäle machen ihre Videos selbst privat oder löschen sie, deshalb habe ich angefangen, gute Inhalte zu speichern, bevor sie verschwinden.
    • Alles im Internet kann jederzeit verschwinden. Was wichtig ist, muss man selbst speichern, wenn man es später wiedersehen will.
    • Ich hätte nicht gedacht, hier jemanden zu sehen, der Sumo-Videos speichert. Es gibt offenbar einige von uns.
    • In einer Zeit mit Überfluss an Inhalten frage ich mich, ob man wirklich alles speichern muss. Früher habe ich MP3s und Filme gesammelt, heute bewahre ich nur noch Fotos in der Cloud auf.

  • In diesem endlosen Wettrüsten zwischen Ad-Blocking und Werbeeinblendungen könnte am Ende tatsächlich AGI/ASI entstehen.
    Beide Seiten werden LLMs einsetzen, und der Mensch wird dazwischen zu einem Wesen, dem sowohl Geldbeutel als auch Aufmerksamkeit entzogen werden.

  • In zehn Jahren könnte YouTube im Browser vielleicht überhaupt nicht mehr zugänglich sein.
    Wenn Generationen, die an Tablet-Apps gewöhnt sind, zur Mehrheit werden, könnte Google genug Selbstvertrauen haben, das Web fallen zu lassen.

    • Wenn man echtes DRM erzwingen will, braucht man dedizierte Hardware. Verschlüsselte Streams müssten dann nur auf L2-zertifizierten Geräten abspielbar sein.
    • Mobile Web-Apps sind so fehlerhaft, dass sie kaum nutzbar sind. Selbst Kommentare verschwinden häufig.
    • Trotzdem hat Google immer eine webzentrierte Strategie verfolgt.
    • Es gibt immer noch viele Menschen, die YouTube im Browser nutzen, und mit dem chinesischen bilibili existieren auch Alternativen.
    • Die Generationen mit Kaufkraft sind aber Browser-Nutzer, daher wird Google diesen Markt wohl nicht vollständig aufgeben.

  • In yt-dlp Issue #14404 wurde vorgeschlagen, Selenium oder einen Headless-Browser zu verwenden,
    doch das Maintainer-Team antwortete: „Das wäre eine Kapitulationserklärung und widerspricht dem Geist des Projekts.“

  • Scraping ist wirklich harte Arbeit. APIs brechen ständig, und es ist bemerkenswert, so etwas aufrechtzuerhalten, wenn die Anbieter einen nicht mögen.

    • Dass „die Anbieter uns nicht mögen“, ist vielleicht gerade der Reiz dieses Projekts.
    • Ich könnte yt-dlp niemals maintainen. Das ist viel zu auszehrende Arbeit.

  • Man merkt, dass YouTube den Nutzern gegenüber immer konfrontativer wird.
    Maßnahmen gegen Ad-Blocker, das Einsammeln von Inhalten für AI-Training, API-Beschränkungen — sie scheinen auszunutzen, dass es kaum Konkurrenz gibt.

    • Eigentlich sind Googles echte Kunden die Werbekunden. Wir sind nur ihr Produkt.
      Auf die Zufriedenheit der Werbekunden wird sensibel reagiert, aber Nutzer und Creator werden wie Verbrauchsmaterial behandelt.
      Kostenlos zu starten, Konkurrenten auszuschalten und danach eine Monopolstruktur zu schaffen, war eine Art Köderstrategie.
      Jetzt brauchen wir neue Alternativen. Auch ein kostenpflichtiger, aber transparenter Dienst wäre willkommen.
    • In letzter Zeit nehmen besonders bei Kindervideos nicht überspringbare Anzeigen zu.
    • Die Betriebskosten von YouTube sind so hoch, dass Ad-Blocking durchaus Auswirkungen auf den Fortbestand des Dienstes haben könnte.
    • Letztlich ist die heutige katastrophale UX (enshittification) selbst Teil des Geschäftsmodells geworden.

  • Laut dem yt-dlp-EJS-Wiki wird Deno empfohlen,
    weil sich Code mit eingeschränkten Rechten ausführen lässt und EJS-Abhängigkeiten aus npm remote bezogen werden können.

    • Man sollte Deno-Sandboxing aber nicht überschätzen. Isolation auf Runtime-Ebene ist schwach,
      daher ist eine Isolierung auf OS-/VM-Ebene wie mit Firecracker sicherer.
    • Früher hat yt-dlp JS nur mit Python interpretiert, aber die Runtime-Anforderungen wurden immer komplexer, sodass der eigene Interpreter an Grenzen stieß.