YouTube fügt bei allen Videos, die den TV-Client (TVHTML5) verwenden, DRM hinzu

 (github.com/yt-dlp)
2 Punkte von GN⁺ 2025-03-11 | 1 Kommentare | Auf WhatsApp teilen
  • Bei einigen YouTube-Konten wurde ein Experiment bzw. A/B-Test beobachtet, bei dem nach dem Login über YouTube on TV selbst normale Videos im TVHTML5-Innertube-Client nur noch in DRM-Formaten ausgeliefert werden
  • Dieses Verhalten ist nicht auf yt-dlp beschränkt: Auch beim Test offizieller YouTube-TV-Clients wie PS3, Webbrowser und Apple TV mit demselben Konto werden die Videoformate nur mit DRM bereitgestellt
  • Da yt-dlp beim Abrufen von YouTube-Videodaten derzeit wie YouTube on TV agiert, werden bei von diesem Experiment betroffenen Konten selbst normale Videos mit dem Fehler This video is DRM protected behandelt
  • Das Reproduktionsprotokoll zeigt, dass beim Abruf des Videos aqz-KE-bpKQ mit Firefox-Cookies und der Einstellung youtube:player-client=tv ein DRM-Schutzfehler auftritt; wenn man über Entwickleroptionen nicht abspielbare Formate anzeigen lässt, erscheint bei Audio- und Videoformaten durchgehend die Kennzeichnung DRM
  • Das Issue ist geschlossen; auf der Seite sind die zugehörigen PRs #14122 und #13539 verlinkt, im Text selbst finden sich jedoch keine konkreten Angaben zur Art der Korrektur oder zur endgültigen Verhaltensänderung

Bei einigen Konten werden TV-Client-Formate nur mit DRM bereitgestellt

  • Es wurde gemeldet, dass bei einigen YouTube-Konten normale Videos im Innertube-Client tv bzw. TVHTML5 nur DRM-Formate haben
  • Das Problem scheint ein Experiment oder A/B-Test zu sein, den YouTube auf einige Konten anwendet; es lässt sich nicht sicher sagen, dass dies für alle Nutzer gilt
  • Zur Klarstellung wurde erläutert, dass bei einigen Konten, die bei YouTube on TV angemeldet sind, alle YouTube-Videos so erscheinen, als wären sie DRM-geschützt
  • YouTube on TV ist die für große Bildschirme gedachte Oberfläche bzw. App für Fernseher, Spielkonsolen usw. und kann mit einem TV- oder Konsolen-User-Agent unter https://www.youtube.com/tv aufgerufen werden

Auswirkungen auf yt-dlp

  • yt-dlp enthält derzeit eine Methode, YouTube-Videodaten über YouTube on TV anzufordern, und ist daher von diesem Experiment betroffen
  • In der Kombination aus betroffenem Konto und tv-Client stuft yt-dlp selbst normale Videos als DRM-geschützte Videos ein
  • Der Reproduktionsbefehl verwendet Firefox-Browser-Cookies und erzwingt mit --extractor-arg youtube:player-client=tv den TV-Client

Dasselbe Ergebnis auch in offiziellen YouTube-TV-Clients

  • Beim Test mehrerer offizieller YouTube-TV-Clients mit demselben Konto wurden ebenfalls nur DRM-Formate bereitgestellt
    • PS3
    • Webbrowser
    • Apple TV
  • Das beobachtete Verhalten ist daher nicht auf ein Implementierungsproblem von yt-dlp allein beschränkt

Über Entwickleroptionen geprüfte Formatliste

  • Nachdem DRM-Formate auf eine Weise sichtbar gemacht wurden, die Codeänderungen erfordert, gibt --allow-un die Liste nicht abspielbarer Formate aus
  • In den ausgegebenen Formaten erscheint bei Audio- und Videoeinträgen durchgehend die Kennzeichnung DRM
    • Reine Audioformate m4a: 148, 149, 148-drc, 149-drc
    • Reine Videoformate mp4 und webm: einschließlich 144p bis 2160p60
    • Als Beispiel wird Format 558 als 3840x2160 60fps, vp9, ca. 1.27GiB, DRM, 2160p60, TV, webm_dash angezeigt
  • --allow-un ist eine Option für Entwickler-Debugging; im Ausgabelog ist eine Warnung enthalten, dass eine Auflistung oder ein Download nicht abspielbarer Formate angefordert wurde

Status des Issues und verknüpfte Arbeiten

  • Das GitHub-Issue hat den Status Closed
  • Auf der Seite sind die zugehörigen PRs #14122 und #13539 verlinkt
  • Im bereitgestellten Text sind jedoch weder die Änderungen in den beiden PRs noch ein Merge-Status, Umgehungsmethoden oder die endgültige Lösung enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-11
Meinungen auf Hacker News

  • Es braucht eine Erklärung, was dieses Issue tatsächlich bedeutet.
    Der Kernpunkt berührt Konzepte, die selbst für technisch versierte allgemeine Leser schwer zu verstehen sind, sodass die Diskussion am Ende wahrscheinlich nur an Schlagworten hängen bleibt und unproduktiv wird.
    Konkret frage ich mich, was der innertube-Client, der tv-innertube-Client, TVHTML5, ein „DRM-Format“, die Bedeutung davon, dass dieses Format „verfügbar“ ist, und warum es wichtig ist, wenn es nur dem tv-innertube-Client angeboten wird, bedeuten.

    • Kurz gesagt testet YouTube per A/B-Test eine Änderung, bei der an bestimmte Clients nur noch per DRM gesperrte Videostreams ausgeliefert werden.
      Das ist wichtig, weil yt-dlp sich im normalen Betrieb als diese Clients ausgibt, und da yt-dlp die Entschlüsselung DRM-geschützter Videos nicht unterstützen will, könnte diese Änderung das Herunterladen aller Videos kaputtmachen.
      innertube ist der Name einer privaten YouTube-API, die für verschiedene Arten von YouTube-Client-Software gedacht ist. Eine Beispielbibliothek ist https://github.com/tombulled/innertube/, und yt-dlp hat eigenen Client-Code.
      Der „tv“-Client ist eine der Client-Arten; ein Beispiel sieht man unter https://github.com/tombulled/innertube/blob/main/innertube/c....
      TVHTML5 ist ein bestimmter Client, zu unterscheiden von Dingen wie TVLITE oder TVANDROID, und es scheint, dass je nach Fernseher ein bestimmter TV-Client und eine bestimmte TV-API verwendet werden.
      Wenn yt-dlp ein Video abruft, tut es grob gesagt so, als wäre es einer der von innertube unterstützten Clients, erhält dann das oberste Videoobjekt und parst die Liste der verfügbaren Formate. Formate sind Dinge wie „MP4, 1080p, mit AAC-Audio“ oder „Ogg, nur Audio“. Standardmäßig lädt yt-dlp den Audiostream in höchster Qualität und den Videostream in höchster Qualität herunter und fügt sie zu einer Datei zusammen, das lässt sich aber konfigurieren.
      Ein DRM-Format ist vermutlich ein durch Widevine geschütztes Format, https://en.wikipedia.org/wiki/Widevine, und yt-dlp hat erklärt, diese Entschlüsselung nicht unterstützen zu wollen.
      „Verfügbar“ bedeutet, dass es dem yt-dlp-Client als Download-Option angezeigt wird. Nicht jedes Video bietet jedem Client alle Formate an; wenn es nicht in 4K hochgeladen wurde oder ein Client kein 4K-Decoding unterstützt, wird die 4K-Option möglicherweise nicht angezeigt.
      In diesem Fall heißt es, dass dieser spezielle interne Client-Typ das Video nicht abrufen kann, weil er auf Anfrage von yt-dlp nur DRM-gesperrte Formate erhält. Bemerkenswert ist das, weil der TV-Client eine Möglichkeit ist, ohne gültiges YouTube-Login-Token hochwertige Videos über die YouTube-API zu bekommen. Weiter unten im Issue sagt der Melder, dass der „web“-innertube-Client funktioniert, wenn man ein Token bereitstellt.

  • Die aktuelle Lage ist letztlich entstanden, weil die Leute mit diesem Zustand zufrieden sind.
    Viele finden es in Ordnung, Filme, Alben und Bücher nicht zu besitzen, und verstehen nicht, was das bedeutet. Diejenigen, die es verstehen, sind in der Minderheit.
    Ich bin nicht grundsätzlich gegen Streaming, aber jeder Anbieter sollte zu einem vernünftigen Preis die Option bieten, eine legale digitale Kopie zu besitzen. Mit Besitz meine ich, eine einfache Mediendatei ohne DRM zu haben und sie abspielen zu können, wo man möchte.
    Es ist überhaupt kein Problem, Geld zu bezahlen, um etwas zu besitzen, aber bis dahin werde ich diesen Firmen keinen Cent geben.

    • Eine Stunde Streaming verursacht 0,5 g CO₂, und bei 6 Stunden pro Tag an 365 Tagen sind das 1095 g pro Person und Jahr.
      Wenn man von 2 Milliarden streamenden Menschen ausgeht, sind das 2.000.000.000 × 1095 = 2.190.000.000.000 g, also 2,19 Millionen Tonnen unnötiges Kohlendioxid.
      Piraterie ist mit einem Mal erledigt, also könnte man sie auch als umweltfreundlicher betrachten, als etwas, das den Planeten retten kann.

  • Ich habe ein Skript gebaut, das mit yt-dlp abonnierte Kanäle herunterlädt, sie in MP3 umwandelt und im lokalen Netzwerk einen Podcast-Feed bereitstellt, und dadurch meine Nutzungszeit der YouTube-App bereits deutlich reduziert.
    Wenn das irgendwann kaputtgeht, muss ich in meiner Freizeit vielleicht nach draußen gehen, aber noch funktioniert es, also hoffe ich, dass es bis zum Frühling durchhält.

    • Ich hatte vor ein paar Tagen genau dieselbe Idee.
      Mich würde interessieren, welche Tools du außer yt-dlp verwendest. Zum Beispiel, womit du den RSS-Feed erzeugst und hostest.
    • Wenn man yt-dlp nach Nur-Audio-Dateien fragt, müsste man sie doch eigentlich nicht extra konvertieren, oder?
    • Dank der Kombination aus uBlock Origin, NewPipe und yt-dlp benutze ich seit Jahren keine YouTube-App mehr.

  • Wirklich schreckliche Nachrichten.
    Dass so etwas kommen würde, war ziemlich absehbar, und es wirkt auch ziemlich offensichtlich, dass es Teil von Googles sehr übergeordneter Strategie ist. Google hat über Jahre hinweg sowohl auf Client- als auch auf Serverseite massiv in all diese Bereiche investiert.
    Für mich riecht das nach Enshittification, aber noch größer betrachtet scheinen wir gerade in eine Ära abgeschotteter und geschlossener Technologien einzutreten. Im Gesamtbild wirkt YouTube ohne DRM fast schon wie ein Anachronismus.
    Da die meisten Menschen bereitwillig Geräte kaufen, die ihre Möglichkeiten stark einschränken, erwarte ich auch keinen nennenswerten Widerstand der Verbraucher. Diejenigen, denen das wirklich wichtig ist, werden wohl vor der Wahl stehen, sich aus Prinzip in der digitalen Welt selbst abzuspalten und Mangel in Kauf zu nehmen, oder zwangsweise in dieselbe Box wie die Nutzer des kleinsten gemeinsamen Nenners gedrängt zu werden.
    Wenn man bei Googles Führung keine bösen Absichten unterstellt, frage ich mich, ob AI vielleicht der letzte Auslöser war. Um den Burggraben von Gemini aufzubauen, müssen Datensammler daran gehindert werden, auf YouTube-Videos zuzugreifen, und die einzige „echte“ Möglichkeit, das sicherzustellen, ist DRM. X/Twitter, Reddit, Stack Overflow und andere haben aus ähnlichen Gründen Maßnahmen ergriffen. Vermutlich wollten sie das ohnehin tun, also ist AI vielleicht eher ein Vorwand als der Grund, aber völlig bedeutungslos ist der Faktor wohl nicht.

    • Ich wünschte, es gäbe eine stärkere Gegenbewegung gegen diese Machtkonzentration der Plattformen.
      Wir sind wie Frösche, die den eigenen Topf selbst befeuern.
      Früher galt DRM als etwas, das mit dem Browser kollidiert, weil es nicht die Interessen der Nutzer vertritt. Wenn DRM unbedingt nötig war, musste die Plattform es über externe Plugins wie Silverlight irgendwie hineinzwängen.
      Als Firefox die EME-Erweiterung einführte, sah ich darin den Anfang vom Ende. Wenn man DRM zu einem Schalter macht, den man einfach aktivieren kann, wird es zur Norm statt zur Ausnahme. Schon seit Jahren gab es absurde Vorschläge wie DRM für Schriftarten. Wenn ein Unternehmen auf DRM besteht, sollte dieses Unternehmen die Last dafür tragen, dass Browser etwas tun müssen, das sie eigentlich nicht nativ unterstützen sollten.
      Der Albtraum, auf den wir zurasen, ist eine Welt, in der man jeweils nur sehr kleine Videostücke cachen kann und TPM-Attestierungs-Hardware bei jeder HTTP-Anfrage ein Token mitschicken muss. Der Browser wird dann nur noch zu einer Software-Kabelbox.
      Auch URLs gefallen ihnen nicht, und wenn man etwas teilen will, werden sie einen ihren Bedingungen unterwerfen wollen, etwa indem die App eine URL mit ablaufendem Hash und Abruflimit erzeugt. Natürlich könnten Influencern unbegrenzte Sharing-Privilegien erhalten bleiben.
      In den letzten zehn Jahren wurde diese Infrastruktur langsam aufgebaut, und das sind keine isolierten Unannehmlichkeiten, sondern Nägel im Sarg.
    • Die Bedrohung, die das Management versteht, ist vermutlich AI.
      Es gibt auch ziemlich gute Drittanbieter-YouTube-Clients wie GrayJay https://grayjay.app/.
      Solche Apps ermöglichen es, Creators von mehreren Videoplattformen in einer App zu folgen, was schlecht für die YouTube-Abhängigkeit ist, die Google will.

  • Eine Zeit lang schienen die itags 18 und 22, also MP4-Videos mit Audiospur, zu verschwinden, während reine Videoformate wie itag 136 und 137 bevorzugt wurden.
    In diesem Fall musste man Audiospur und Video mit ffmpeg zusammenführen. In letzter Zeit scheint itag 18 wieder zurück zu sein.

  • YouTube scheint gegen Video-Downloads vorzugehen.
    Mit Tor bekomme ich jeden Tag die Meldung „Melde dich an, um zu beweisen, dass du kein Bot bist“, und ohne Tor kann ich nicht auf YouTube zugreifen. Werbung anzusehen oder Captchas zu lösen wäre in Ordnung, aber YouTube hat sich für die schlechteste Methode entschieden.

    • Vor Kurzem hat die YouTube-App auf dem Amazon FireCube angefangen, bei jedem Öffnen nach einer Anmeldung zu fragen.
      Man muss sich zwar nicht vollständig authentifizieren, aber ein Profil auswählen.
      Das begann vor ein paar Monaten, und ich habe mir nicht viel dabei gedacht, aber rückblickend könnte dieses Verhalten ein Vorbote des neuen DRM-Vorstoßes gewesen sein.
      YouTube liefert jeden Tag mehr Gründe, es komplett zu meiden.

  • Zufällig wurde ich auch hier von YouTube mit „Melde dich an, um zu bestätigen, dass du kein Bot bist, damit wir unsere Community schützen können“ begrüßt.
    Es gibt viele Möglichkeiten, die Leine enger zu ziehen.
    Leider werden manche Leute niemals ein Konto anlegen, und manche werden kein DRM-System verwenden. Man muss Wege finden, indirekt auf diese reichhaltigen Inhalte zuzugreifen.

  • Ich hätte gern Empfehlungen für YouTube-Alternativen, auf denen man Lofi- oder Synthwave-Musik entdecken kann.

  • Ich frage mich, was das für Firefox-Nutzer bedeutet
    Das von Firefox unterstützte DRM lässt sich leicht knacken – wird YouTube die Firefox-Unterstützung einstellen?

    • Derzeit scheint es nur bei einer bestimmten TV-Client-API aufzutreten, die yt-dlp nutzt, und offenbar nicht bei allen YouTube-Videos.
      Auch unter https://github.com/yuliskov/SmartTube/issues/4444 wurde es bei Videos „nur für Mitglieder“ beobachtet, aber ebenfalls nicht bei allen Videos.
      Wahrscheinlich geht es um den Unterschied zwischen Software-DRM und Hardware-DRM, etwa Widevine L3 und L1 sowie PlayReady SL2000 und SL3000; das ist aber nicht exakt ein Firefox-gegen-Chrome-Szenario. Soweit bekannt, hat auch Firefox daran gearbeitet, unter Windows Hardware-DRM nutzen zu können, vermutlich über die Media Foundation API.
      Das Worst-Case-Szenario, wie man es bei Diensten wie Netflix sieht, wäre, Browsern, die wie Firefox nur Software-DRM unterstützen, nur niedrige Bildqualität anzubieten und bessere Qualität mit Schlüsseln zu verschlüsseln, die nur über Hardware-DRM verfügbar sind. Allerdings weiß ich nicht, ob YouTube jetzt so weit gehen wird. Netflix oder Amazon haben Verträge mit Rechteinhabern, die solche Schutzmaßnahmen verlangen; YouTube hat zum Glück meiner Einschätzung nach nicht dieselbe Art von Beziehung und Verträgen mit „YouTubern“.
      Was YouTube derzeit offenbar will, ist, die Zahl der Leute deutlich zu reduzieren, die Inhalte nicht über die Website oder App ansehen, also keine Werbung sehen. Vermutlich zielt das eher auf die viel größere Zahl von Menschen, die YouTube-to-mp3-Seiten oder ähnlich einfache Tools nutzen, als auf yt-dlp-Nutzer.
      Schon das Erzwingen von Software-DRM könnte solche Tools zumindest vorübergehend kaputtmachen und Nutzer zurück auf die Plattform bringen. Und wenn ein Mechanismus zur „Umgehung der Verschlüsselung“ in die Tools eingebaut wird, könnte man wohl auch die Entwickler verklagen – ich bin allerdings kein Rechtsexperte.
    • Man kann sagen, dass der Hauptzweck von DRM darin besteht, das System rechtlich in den DMCA-Bereich zu ziehen.
      Dann ist es sehr wahrscheinlich vorbei damit, dass yt-dlp auf GitHub gehostet oder über apt-Repositories, pip, Homebrew usw. verteilt wird.
    • Ich halte es zwar für unwahrscheinlich, dass es dazu kommt, aber bei anderen Streaming-Diensten gab es bereits Fälle, in denen Clients ohne DRM-Unterstützung oder unerwünschte Clients nur niedrige Bildqualität erhielten.

  • In diesem Zusammenhang hat TubeArchivist gerade v0.5 veröffentlicht und befindet sich offiziell nicht in einem Feature-Freeze.