Als youtube-dl, ein bekanntes Werkzeug zum Offlinegucken von langweiligem Unsinn, vor zwei Wochen rechtliche Probleme bekam, weil die RIAA anscheinend der Ansicht ist, dass das Besorgen urheberrechtlich geschützten Popmülls kein legitimes Nutzungsbeispiel sein sollte, geriet das Netz wieder einmal in hektische Angst, was die Zukunft des Herunterladens betrifft. Ich habe der Situation vergleichsweise entspannt zugesehen, denn mir war etwas aufgefallen:
Die vergleichsweise oft genannte Alternative you-get teilt mit youtube-dl und vielen anderen Optionen das wesentliche Problem, dass sie in Python geschrieben ist. Python mag en vogue sein, weil es schnelle Lösungen verspricht, aber das tat BASIC seinerzeit eben auch – und BASIC war nicht dafür bekannt, vor allem elend langsam zu sein. Mehr noch: Nicht selten fand ich auf meinen Systemen nach einem Pythonupgrade manche Anwendungssoftware nicht mehr lauffähig vor, meist wegen inkompatibler Abhängigkeiten. Meine letzte eigene Pythonsoftware – die Kuckucksuhr – ist deshalb inzwischen auch in Rust (dazu unten mehr) geschrieben. Je mehr Programme, die ich einsetze, statisch gelinkt werden, desto weniger wahrscheinlich geht nach einem größeren Update irgendwas kaputt.
piko sah als Go-Anwendung daher interessant aus, hat von youtube-dl aber die beiden Designärgernisse abgeguckt, dass es erstens nicht nur Video‑, sondern auch Bilderplattformen unterstützen will, was die Komplexität unnötig erhöht, und zweitens – für mich selbst ganz interessant – keine einheitliche Möglichkeit anbietet, nach dem Download nur noch die Audiodaten zu behalten. Der zusätzliche Befehl kann bei häufiger Nutzung doch recht lästig werden.
In einem Anflug geistiger Umnachtung habe ich daher laut gedacht, so was könnte ich auch. Leider wollte es dann auch jemand haben. Schade.
Die wesentlichen Funktionen sollten folgende sein:
- Keine unnötigen Spielereien. Es sollen Videos (optional: nur die Audiostreams) in der besten verfügbaren Qualität heruntergeladen werden können. Keine Bilder. Keine GIFs.
- Kein Python. Aus Gründen.
- Einfache Erweiterbarkeit. Zwar muss natürlich YouTube unterstützt werden, aber spätere Erweiterungen um andere Seiten sollten so wenig doppelten Code wie möglich erfordern.
Ich habe also yaydl in Rust programmiert, einer Sprache, mit der ich – schon wegen des beachtlich guten cargo-Systems – sowieso mal mehr machen wollte als bloß ein bisschen Text auszugeben. Zwar nutze ich in letzter Zeit vor allem Go (und Perl), aber das wäre ja keine Herausforderung. Das trait-Konzept ist auch recht überzeugend: Um eine weitere Website neben YouTube hinzuzufügen, muss in yaydl nur ein Interface mit jeweils sechs Funktionen implementiert werden. Das sollte schaffbar sein.
Über Vor- und Nachteile von Go und Rust, auch gegenüber anderen von mir gemochten Sprachen, möchte ich an dieser Stelle nicht diskutieren, das überlasse ich irgendwelchen Quatschblogs, die mit so was ihr Geld verdienen. Stattdessen möchte ich die eingangs gestellte Frage selbst beantworten: YouTube macht es einem wirklich nicht leicht, Videos herunterzuladen, denn direkte URLs gibt es nicht.
Daher muss man zu einem Video erst die get_video_info-Datei herunterladen, dort das JSON-Objekt mit den Videodaten heraussuchen und in diesem in einer undokumentierten Liste an nummerierten Formaten das beste heraussuchen und dessen URL extrahieren. Meine erste Version macht genau das, jedoch scheint es empfohlen zu sein, aus diesen vier Schritten (mindestens) zwölf zu machen. Ich vermute, die Macher von YouTube haben sich etwas dabei gedacht, ich werde den Code nach Abklingen meiner Kopfschmerzen möglicherweise entsprechend erweitern.
Immerhin: Ich beginne zu verstehen, warum es bisher so wenige gute Alternativen gab.
Stattdessen möchte ich die eingangs gestellte Frage selbst beantworten: YouTube macht es einem wirklich nicht leicht, Videos herunterzuladen, denn direkte URLs gibt es nicht.
Daher muss man zu einem Video erst die get_video_info-Datei herunterladen, dort das JSON-Objekt mit den Videodaten heraussuchen und in diesem in einer undokumentierten Liste an nummerierten Formaten das beste heraussuchen und dessen URL extrahieren. Meine erste Version macht genau das, jedoch scheint es empfohlen zu sein, aus diesen vier Schritten (mindestens) zwölf zu machen. Ich vermute, die Macher von YouTube haben sich etwas dabei gedacht, ich werde den Code nach Abklingen meiner Kopfschmerzen möglicherweise entsprechend erweitern.
Na dann auch viel Spaß, beim regelmäßigen Rückwärts-ingenieuren und Nachpflegen, wenn YouTube wieder mal kleine oder größere Änderungen einbaut. Es hat schon seinen Grund, warum bei youtube-dl so häufige Updates kommen und andere Projekte keinen Bock mehr hatten.
Immerhin: Ich beginne zu verstehen, warum es bisher so wenige gute Alternativen gab.
Na dann wollen wir mal hoffen, dass Du doch bald noch in ein Alter kommst, in dem Du am Anfang dann mal nicht mehr so groß die Klappe aufreißt. Mit Deiner „Nur ich allein hab den absoluten Durchblick“-Attitüde wärst Du übrigens auch ein perfekter Verschwörungsschwurbler (btw. würde das Deinen Vermögensverhältnissen vielleicht auch ganz gut tun, so wie es bei den Anderen da abgeht…).
Da steckt aber eine Menge Emotion in der Technikszene. Lass mich raten: Linuxnutzer?
Betriebssystem-Flamewars? Hab ich damals auch gemacht, als ich 14 war.
Also ja.
Was ist los? Ich vermisse noch die Nie-Na-Nazivorwürfe, weil jemand eine nützliche Software veröffentlicht und eine Andeutung der Probleme macht, die er wegen der Downloadverhinderungsstrategien (von mir auch gern »Technikverhinderung« genannt) von Googles YouTube hat. Denn ohne diese Technikverhinderung wäre es wirklich kein großes Problem, sondern im Idealfall ein Shellskript um
curl.Der Lauffähigkeit von Software ist die Persönlichkeit des Proggers völlig egal. Zum Glück!
Und ich vermisse die Zeiten damals, als das Internet mehr ein Plätschern als ein jede Vernunft und Zurückhaltung mit sich reißender Strom war; damals, als ich einfach ein YouTube-Video pausieren konnte, der Download währenddessen weiterging, so dass ichab warten konnte, bis es komplett im lokalen Buffer war und es dann ohne Nachladepausen abspielen konnte. Na gut, ich vermisse die Zeiten nicht wirklich. Aber so sieht das eben ohne Technikverhinderung aus. Das Problem ist hier eine hirnlos-geschäftstüchtig agierende Unternehmung, die einerseits einen Download ermöglichen muss (damit der »Stream« in den Browser kommt), die andererseits aber einen Download erschweren oder verhindern will – und dass diese Unternehmung auch noch sehr willkürlich zensiert und dass wertvolle Inhalte (ich meine damit nicht die Einlassungen von KenFM und Konsorten, die gute Klickbringer und Reklamevermarkter für YouTube sind) aus Bullshitgründen verschwinden, macht die Sache nicht besser. Für mich ist jedenfalls klar, auf welcher Seite dieses absurden Theaters das Arschloch steht. Ein ziemlich technokratisches Loch ist es…
Danke.
Für mich ist jedenfalls klar, auf welcher Seite dieses absurden Theaters das Arschloch steht. Ein ziemlich technokratisches Loch ist es…
Wie bitte? Ich soll jetzt Teil der großen YouTube-Verschwörung sein oder was?
Ich kritisierte lediglich, in welchem großkotzigen Tonfall der Autor sich mal wieder äußerte und alle anderen sinngemäß als doof und Idioten beschimpfte, und er weiß mal wieder alles besser, natürlich auch als Projekte, die sich ca. 15 Jahre schon mit dem Thema herumschlagen.
Und ich bemerkte, dass er seine immer zur Schau gestellte Großkotz-Attitüde (zusammen mit Dunning-Kruger-Effekt, zu beliebigen Themen) eben mit Verschwörungsschwurblern gemeinsam hat.
Warum sollte ich Etwas gegen seine Eigenentwicklung haben? Mein Hinweis ging lediglich in die Richtung, dass er besser Viele bei der Entwicklung um sich scharen sollte (bzw. sich schon existierenden Gruppen anschließen sollte, die auch schon regelmäßig das Reverse-Engineering betreiben, etc.), denn als Ein-Mann-Projekt ist es wegen der vielen und auch umfangreicheren Änderungen bei den Protokollen (die auch mit der Zeit immer komplexer wurden, siehe auch HLS, etc.) der Portale ziemlich aufwändig, die Software funktionsfähig zu halten.
Jeder ist herzlich eingeladen, Code beizutragen. Ich freue mich auf deinen.
du bist doch schon lange Teil der großen YouTube-Verschwörung
m(
Also… ich komme ziemlich gut mit SaveFrom.net zurecht. Spricht etwas aus Expertensicht dagegen?
Zu viele Trackingscripts, zu wenig Transparenz. Ich persönlich mag keine Webdienste. Aber bitte, wenn’s den Zweck erfüllt?
Mnjaaa, ich hab mir gerade mal dieses Script angeguckt, das sie hier in Schritt 2 reintun:
https://de.savefrom.net/userjs-for-google-chrome.php
Das Einzige, was ich begriffen habe, war, daß ich nichts begriffen habe. Jetzt bin ich mir nicht mehr sicher, ob ich so was im Browser haben will.
Nein, willst du nicht.
versuch mal mit sowas wie SaveFrom zb vr-3D-180/360° videos im Equirectangular-format (und vor allem eben nicht als cube-map) in 4K von youtube zu ziehen. geht idr nicht mit webdiensten. du *weisst*, die sind auf dem youtube-server, kommst aber ums verrecken nicht ran. manchmal erwischt ne app wie vidMate die richtige webM-fassung, aber normalerweise bekommste nur die standart-mono-fassung in max. 1080 angeboten.
nervt.
Das kann mein Programm tatsächlich auch nicht.
Noch nicht.
*wenn* du das hinkrichst, ist dir ewige dankbarkeit meinerseits sicha!
wie se alle heißen
LOL! Jehova! Jehova!
Cool von dir, dass du diese Lernerfahrung in deinen Blog gepackt hat. Manchmal muss man es halt erst wirklich bauen um zu sehen warum etwas kompliziert ist.