{
    "kind": 30023,
    "id": "ee5b24264db2310fb1f396ab2e27dad106028ffcd74a97ba70ee24757754528d",
    "pubkey": "c1baf4f74cd829963828b1da8d73e52cc94caa6d8dc944f7ca450a75c4b3311f",
    "created_at": 1794148963,
    "tags": [
        [
            "title",
            "Twitch VOD herunterladen: Warum Streams nach 7 Tagen verfallen und wie 160p mit Segment-Splitting 93 Prozent Speicher spart"
        ],
        [
            "d",
            "zeigen-ae05ae95"
        ],
        [
            "summary",
            "Wer ein Twitch VOD herunterladen will, st\u00f6\u00dft auf L\u00f6schfristen ab 7 Tagen: Wie 160p bei 100 % Ton 93,7 % Platz spart und wie Segment-Splitting und twostamp Beweiskraft sichern."
        ],
        [
            "published_at",
            "1794148963"
        ]
    ],
    "content": "## Wer ein Twitch VOD herunterladen will, verliert ungesicherte Streams nach 7 bis 60 Tagen\n\nW\u00e4hrend die Analyse in [Videos downloaden free: Warum Web-Downloader an Twitch-Streams scheitern und wie HLS-Chunks die Datenmenge um 99 Prozent senken](https://stevennoack.de/artikel/kurze-note-in-stevens-stimme-zum-suchbegriff-videos-download/) darlegt, warum werbefinanzierte Webdienste bei mehrst\u00fcndigen \u00dcbertragungen abbrechen und wie sich kurze 30-Sekunden-Ausschnitte \u00fcber HTTP-Live-Streaming (HLS) ohne Gesamtdownload isolieren lassen, verlangt die vollst\u00e4ndige Archivierung einer vergangenen \u00dcbertragung eine andere Herangehensweise. Vergangene Live-Sendungen, sogenannte Video-on-Demand-Aufzeichnungen (VODs), verbleiben nicht dauerhaft auf den Plattformservern.\n\nLaut den offiziellen Speicherrichtlinien von Twitch (*On-Demand Content on Twitch*, help.twitch.tv, Stand November 2026) unterliegen alle archivierten Sendungen festen L\u00f6schfristen:\n\n1. **Standard-Streamer:** Automatische L\u00f6schung nach genau 7 Tagen.\n2. **Twitch Affiliates:** Automatische L\u00f6schung nach 14 Tagen.\n3. **Twitch Partner sowie Prime- und Turbo-Abonnenten:** Maximale Vorhaltezeit von 60 Tagen.\n4. **2K- und vertikale Streams:** Hochaufl\u00f6sende 2K-Streams und vertikale \u00dcbertragungen verfallen f\u00fcr alle Nutzergruppen, einschlie\u00dflich verifizierter Partner, ausnahmslos nach 7 Tagen.\n5. **Highlights und Uploads:** F\u00fcr manuell erstellte Highlights gilt eine strikte kanalseitige Gesamtobergrenze von 100 Stunden.\n\nDer Kundendienst von Twitch stellt in den offiziellen Richtlinien klar, dass abgelaufene VODs unwiederbringlich vom Server gel\u00f6scht werden. Eine nachtr\u00e4gliche Wiederherstellung durch den Support ist technisch ausgeschlossen. Wer eine \u00dcbertragung f\u00fcr Recherche, Berichterstattung oder Beweissicherung dauerhaft sichern will, muss das Material vor Ablauf dieser Fristen lokal auf eigenen Speichermedien ablegen.\n\n## Die 160p-Aufl\u00f6sung senkt die Dateigr\u00f6\u00dfe um 93,7 Prozent und erh\u00e4lt den vollen Originalton\n\nDie naheliegende Methode, einen Stream in voller Quellaufl\u00f6sung herunterzuladen, f\u00fchrt bei mehrst\u00fcndigen \u00dcbertragungen zu massiven Datenmengen. Ein typischer Livestream in 1080p60 wird von Twitch mit einer Videobitrate von 6.000 kbit/s und einer Audiomitrate von 160 kbit/s im Advanced Audio Coding (AAC) ausgeliefert. Das ergibt eine Gesamtbitrate von 6.160 kbit/s.\n\nBei einer f\u00fcnfst\u00fcndigen Sendung (konkret gemessen an einem Teststream mit 5 Stunden, 23 Minuten und 50 Sekunden, entsprechend 19.430 Sekunden) bel\u00e4uft sich das Datenvolumen auf 14,27 Gigabyte (14.268 Megabyte). Stehen auf einer mobilen Arbeits-SSD beispielsweise lediglich 7 Gigabyte freier Speicher zur Verf\u00fcgung, scheitert der Download zwangsl\u00e4ufig an Speichermangel.\n\nEin kleines Pr\u00fcfskript (`twitch-vod-check`) berechnet die Verteilung f\u00fcr die verschiedenen HLS-Profile:\n\n| Profil | Bitrate | Dateigr\u00f6\u00dfe (5:23:50 h) | Ersparnis gegen\u00fcber Quelle |\n|---|---|---|---|\n| 1080p60 (Twitch Quelle) | 6.160 kbit/s | 13,93 GB (14.268,0 MB) | Basis |\n| 720p60 (HD) | 4.660 kbit/s | 10,54 GB (10.793,7 MB) | -24,4 % |\n| 480p (SD) | 1.660 kbit/s | 3,75 GB (3.845,0 MB) | -73,1 % |\n| 360p (Niedrig) | 960 kbit/s | 2,17 GB (2.223,6 MB) | -84,4 % |\n| 160p (Archiv mit Originalton) | 390 kbit/s | 903,3 MB | -93,7 % |\n| Audio Copy (AAC nativ) | 160 kbit/s | 370,6 MB | -97,4 % |\n| MP3 192 kbit/s (CBR) | 192 kbit/s | 444,7 MB | -96,9 % |\n| MP3 80 kbit/s (Sprachprofil) | 80 kbit/s | 185,3 MB | -98,7 % |\n\nDie Stufe 160p kombiniert ein stark komprimiertes Videobild (rund 230 kbit/s) mit der unver\u00e4nderten 160-kbit/s-AAC-Audiospur. Dadurch sinkt der Speicherbedarf desselben f\u00fcnfst\u00fcndigen Streams von 14,27 Gigabyte auf 903,3 Megabyte. Das entspricht einer realen Ersparnis von 93,7 Prozent.\n\nDer technische Vorteil liegt in der Tonspur: Twitch transkodiert das Audiosignal f\u00fcr niedrigere Videostufen nicht separat herunter. Die Tonspur in 160p ist bitgenau identisch mit jener des 1080p60-Streams. Alle gesprochenen Aussagen, Tonh\u00f6hen und Hintergrundger\u00e4usche bleiben unber\u00fchrt. Zugleich gen\u00fcgt die Bildaufl\u00f6sung von 284 mal 160 Pixeln bei 30 Bildern pro Sekunde, um Uhrzeiten, Bildschirmeinblendungen, Chat-Fenster und Geschehnisse auf dem Monitor visuell zuzuordnen.\n\n## Segment-Splitting in f\u00fcnf Teile h\u00e4lt Dateigr\u00f6\u00dfen unter der 200-Megabyte-Grenze von NotebookLM\n\nEine ungeteilte 900-Megabyte-Videodatei st\u00f6\u00dft in redaktionellen und nachgelagerten Arbeitsabl\u00e4ufen auf technische Barrieren. Das Aufteilen eines Streams in f\u00fcnf gleich lange Abschnitte l\u00f6st drei praktische Probleme:\n\n1. **Dateisystemgrenzen \u00e4lterer Medien:** FAT32-formatierte USB-Sticks und externe Speicher erlauben keine Einzeldateien \u00fcber 4 Gigabyte (exakt 4.294.967.295 Bytes). Ein 1080p-Stream bricht bei 4 Gigabyte unvollst\u00e4ndig ab. In f\u00fcnf Teile zerlegt sinkt selbst der 1080p-Stream auf 2,79 Gigabyte pro Segment und bleibt unterhalb des Dateisystemlimits.\n2. **Grenzen von Cloud- und KI-Diensten:** Automatisierte Transkriptions- und Analysesysteme setzen strikte Obergrenzen f\u00fcr den Datei-Upload:\n   - Google NotebookLM: Maximal 200 Megabyte pro Quelldatei.\n   - OpenAI Whisper API: Maximal 25 Megabyte pro Audio- oder Videodatei.\n   - Telegram Bot API: Maximal 50 Megabyte pro Mediendatei.\n   \n   Bei einem 5:24-Stunden-Stream in 160p (903,3 Megabyte gesamt) dauert jedes der f\u00fcnf Teilst\u00fccke genau 1 Stunde, 4 Minuten und 46 Sekunden (3.886 Sekunden). Die Dateigr\u00f6\u00dfe jedes Segments liegt bei exakt 180,7 Megabyte. Damit unterschreitet jedes Teilst\u00fcck das Limit von Google NotebookLM (200 Megabyte), w\u00e4hrend die Gesamtdatei abgewiesen w\u00fcrde.\n3. **Schutz vor Dateibesch\u00e4digung:** Wenn ein f\u00fcnfst\u00fcndiger Download kurz vor Ende abbricht oder der MP4-Index (`moov atom`) beim Schreiben besch\u00e4digt wird, ist die gesamte Datei unbrauchbar. Segmentierte Dateien isolieren \u00dcbertragungsfehler auf einzelne Abschnitte.\n\nWie bereits in [Video schneiden online: Warum browserbasiertes Schneiden an Cloud-Limits scheitern und wie lokale Browser-APIs ohne Upload arbeiten](https://stevennoack.de/artikel/fachartikel-zum-suchbegriff-video-schneiden-online-3600-such/) gezeigt wurde, erfordert das Aufteilen von Videomaterial keine zeitraubende Neuberechnung. Mit FFmpeg erfolgt die Segmentierung \u00fcber den Kopiermodus (`-c copy`):\n\n```bash\nffmpeg -i vod_160p.mp4 -f segment -segment_time 3886 -reset_timestamps 1 -c copy teil_%02d.mp4\n```\n\nWeil Bild und Ton ohne Transkodierung direkt in neue MP4-Container kopiert werden, beansprucht dieser Vorgang praktisch keine Prozessorleistung. Der gesamte f\u00fcnfst\u00fcndige Stream ist innerhalb weniger Sekunden in f\u00fcnf Teile zerlegt, ohne Generationsverlust und ohne Qualit\u00e4tsminderung.\n\n## Herkunfts-Metadaten im MP4-Container sichern die Quelle vor nachtr\u00e4glichen Zweifeln ab\n\nEine reine Videodatei auf einer Festplatte besitzt f\u00fcr sich genommen wenig Aussagekraft. Datumsangaben des Dateisystems lassen sich mit einfachen Systembefehlen (`touch -t`) nachtr\u00e4glich ver\u00e4ndern. Um die Herkunft eines Mitschnitts zweifelsfrei zu dokumentieren, m\u00fcssen Metadaten bereits beim Abruf erhoben und fest im Dateicontainer verankert werden.\n\nBeim Abruf \u00fcber das Twitch-GraphQL-Interface (`gql.twitch.tv/gql` mit der standardm\u00e4\u00dfigen Client-ID `kimne78kx3ncx6brgo4mv6wki5h1ko`) werden Kanalname, Stream-ID, Titel und der Erstellungszeitpunkt (`createdAt`) erfasst. Parallel dazu liefern die HTTP-Header der geladenen HLS-Videosegmente den Nachweis: Der Header `Last-Modified` dokumentiert den genauen Serverzeitpunkt des CloudFront-Knotens, w\u00e4hrend der `ETag`-Header dem MD5-Hash des Segments auf Amazons S3-Speicher entspricht.\n\nDiese Herkunftsdaten werden beim Zusammenf\u00fcgen verlustfrei in die Metadatenfelder des MP4-Containers geschrieben:\n\n```bash\nffmpeg -i vod_160p.mp4 -c copy \\\n  -metadata title=\"Twitch VOD Sicherung\" \\\n  -metadata comment=\"Quelle: https://www.twitch.tv/videos/<VOD-ID> | Stream-ID: <STREAM-ID>\" \\\n  -metadata creation_time=\"<createdAt aus der GraphQL-Antwort>\" \\\n  vod_gesichert.mp4\n```\n\nDadurch tragen alle Segmente ihre Herkunftsinformationen direkt in den Datei-Headern, unabh\u00e4ngig davon, in welchem Verzeichnis oder auf welchem Datentr\u00e4ger sie sp\u00e4ter lagern.\n\n## Der Doppelzeitstempel \u00fcber RFC 3161 und Bitcoin belegt die Unver\u00e4nderbarkeit der Datei\n\nUm zu beweisen, dass die gesicherten Videodateien nach dem Herunterladen nicht nachtr\u00e4glich manipuliert, gek\u00fcrzt oder ver\u00e4ndert wurden, gen\u00fcgt kein lokales Dateidatum. Hier greift das Verfahren der doppelten Zeitstempelung, wie es in [twostamp: Zwei Zeitstempel f\u00fcr jede Datei, in einem Befehl](https://stevennoack.de/artikel/twostamp-zwei-zeitstempel-fuer-jede-datei/) und methodisch in [Gedanken verankern: Warum kryptografische Zeitstempel die Zukunft pers\u00f6nlichen Wissens sind](https://stevennoack.de/artikel/gedanken-kryptografisch-verankern/) beschrieben ist.\n\nZun\u00e4chst wird eine SHA-256-Pr\u00fcfsummendatei \u00fcber alle f\u00fcnf Segmente erzeugt:\n\n```bash\nshasum -a 256 teil_*.mp4 > SHA256SUMS.txt\n```\n\nAnschlie\u00dfend versieht das Werkzeug `twostamp` die Pr\u00fcfsummendatei mit zwei unabh\u00e4ngigen Zeitstempeln:\n\n```bash\ntwostamp SHA256SUMS.txt\n```\n\nDas Skript f\u00fchrt zwei kryptografische Nachweise durch:\n\n1. **Stempel nach IETF RFC 3161:** Ein Zeitstempeldienst (Time Stamping Authority wie freetsa.org) signiert den SHA-256-Hash mit einem X.509-Zertifikat. Das Ergebnis wird als signierte Antwortdatei (`.tsr`) abgelegt. Dieser Nachweis l\u00e4sst sich jederzeit offline mit Standardprogrammen wie OpenSSL \u00fcberpr\u00fcfen (`openssl ts -verify`).\n2. **Dezentraler Existenzbeweis via OpenTimestamps:** Der Hashwert wird \u00fcber einen kryptografischen Merkle Tree in eine Bitcoin-Transaktion eingebettet. Sobald der Block best\u00e4tigt ist, beweist die Blockchain mathematisch, dass die Pr\u00fcfsumme zu diesem Blockzeitpunkt existiert hat. Dieser Beweis ist dauerhaft haltbar, selbst wenn die ausstellende Zertifizierungsstelle ihren Betrieb einstellt.\n\n## Die Privatkopie nach Urheberrechtsgesetz greift bei unverschl\u00fcsselten Streams ohne DRM\n\nDas Herunterladen und Sichern \u00f6ffentlich zug\u00e4nglicher Twitch-Streams unterliegt dem deutschen Urheberrechtsgesetz (UrhG):\n\n- **Recht auf Privatkopie (\u00a7 53 Abs. 1 UrhG):** Einzelne Vervielf\u00e4ltigungen eines Werkes durch eine nat\u00fcrliche Person zum privaten Gebrauch sind auf beliebigen Tr\u00e4gern zul\u00e4ssig, sofern sie weder Erwerbszwecken dienen noch zur Herstellung eine offensichtlich rechtswidrig hergestellte oder \u00f6ffentlich zug\u00e4nglich gemachte Vorlage verwendet wird. Da Broadcaster ihre Streams selbst \u00f6ffentlich bereitstellen, handelt es sich um eine rechtm\u00e4\u00dfige Vorlage.\n- **Keine Umgehung technischer Schutzma\u00dfnahmen (\u00a7 95a UrhG):** Twitch verwendet f\u00fcr gew\u00f6hnliche Livestreams und VODs keine digitale Rechteverwaltung (DRM wie Widevine, FairPlay oder PlayReady). Die HLS-Segmente liegen unverschl\u00fcsselt als MPEG-TS- oder fMP4-Fragmente auf Content Delivery Networks. Das Auslesen der Streaming-Listen stellt keine Umgehung wirksamer technischer Schutzma\u00dfnahmen im Sinne des Gesetzes dar.\n- **Straffreiheit bei privatem Gebrauch (\u00a7 108b Abs. 1 UrhG):** Selbst in Streitf\u00e4llen \u00fcber technische Barrieren stellt der Gesetzgeber klar, dass Handlungen, die ausschlie\u00dflich zum eigenen privaten Gebrauch des T\u00e4ters oder mit ihm pers\u00f6nlich verbundener Personen erfolgen, straffrei bleiben.\n- **AGB-Klauseln versus Gesetz:** Abschnitt 9 der Twitch-Nutzungsbedingungen untersagt das automatisierte Herunterladen von Plattforminhalten. Dies kann zivilrechtliche Unterlassungsanspr\u00fcche von Twitch begr\u00fcnden (etwa Kontosperren), ber\u00fchrt jedoch weder die gesetzliche Zul\u00e4ssigkeit der Privatkopie nach \u00a7 53 UrhG noch begr\u00fcndet es einen Straftatbestand.\n- **Beweiswert im Zivilprozess (\u00a7 286 ZPO und eIDAS-Verordnung):** Nach Art. 41 Abs. 1 der EU-Verordnung Nr. 910/2014 (eIDAS) darf einem elektronischen Zeitstempel die Rechtswirkung und Zul\u00e4ssigkeit als Beweismittel in Gerichtsverfahren nicht allein wegen seiner elektronischen Form abgesprochen werden. In Verbindung mit dem Grundsatz der freien Beweisw\u00fcrdigung nach \u00a7 286 der Zivilprozessordnung liefert die Kombination aus SHA-256-Hash, RFC-3161-Signatur und Blockchain-Verankerung die st\u00e4rkste technische Absicherung gegen den Vorwurf, ein Video sei nachtr\u00e4glich montiert worden.\n\n## Wo das Verfahren an Grenzen st\u00f6\u00dft: Unver\u00f6ffentlichte Streams und die Grenzen einfacher Zeitstempel\n\nDas beschriebene Verfahren ist kein Universalschl\u00fcssel und weist konkrete Grenzen auf:\n\n1. **Unver\u00f6ffentlichte \u00dcbertragungen bei deaktivierter Archivierung:** Broadcaster k\u00f6nnen im Dashboard festlegen, ob vergangene \u00dcbertragungen gespeichert werden. Hat ein Kanalbetreiber die VOD-Speicherung vollst\u00e4ndig deaktiviert, verwerfen die CloudFront-Server die HLS-Segmente oft unmittelbar nach Streamende. In einer praktischen Stichprobe an einem Stream ohne gespeicherte Aufzeichnung lieferten alle 24 gepr\u00fcften CloudFront-Server nach Streamende ausnahmslos HTTP-Status 403 (insgesamt 57.624 abgewiesene Anfragen). Wenn Twitch die Transkodierung nicht im Cache vorh\u00e4lt, ist eine nachtr\u00e4gliche Rekonstruktion unm\u00f6glich.\n2. **Unterschied zwischen einfachen und qualifizierten Zeitstempeln:** Art. 41 Abs. 1 eIDAS garantiert die Zul\u00e4ssigkeit elektronischer Zeitstempel vor Gericht. Die gesetzliche Vermutung der Richtigkeit von Datum und Datenunversehrtheit nach Art. 42 eIDAS gilt jedoch nur f\u00fcr *qualifizierte* elektronische Zeitstempel von akkreditierten Vertrauensdiensteanbietern. Zeitstempel von Freetsa (RFC 3161) oder OpenTimestamps (Bitcoin) unterliegen als einfache Zeitstempel der freien richterlichen Beweisw\u00fcrdigung nach \u00a7 286 ZPO. Im juristischen Streitfall muss die Integrit\u00e4t durch Vorlage der Pr\u00fcfprotokolle und Zertifikatsketten dargelegt werden.\n3. **M\u00f6gliche k\u00fcnftige DRM-Sperren:** Sollte Twitch k\u00fcnftig verschl\u00fcsselte HLS-Str\u00f6me oder DRM-Systeme einsetzen (etwa f\u00fcr exklusive Pay-per-View-\u00dcbertragungen), greift das Umgehungsverbot des \u00a7 95a UrhG. Ein Download ohne Schl\u00fcssel w\u00e4re ab diesem Moment unzul\u00e4ssig.\n\n## Mit yt-dlp, FFmpeg und twostamp l\u00e4uft die Archivierung vollst\u00e4ndig im Terminal ab\n\nDer gesamte Ablauf von der Ermittlung der HLS-Playlists \u00fcber den Download in 160p, das verlustfreie Splitten bis zur kryptografischen Doppelstempelung l\u00e4sst sich mit Standard-Werkzeugen im Terminal automatisieren:\n\n```bash\n# 1. Arbeitsverzeichnis anlegen und VOD-Adresse definieren\nURL=\"https://www.twitch.tv/videos/<VOD-ID>\"\nmkdir -p vod_archiv && cd vod_archiv\n\n# 2. VOD in 160p mit vollem Originalton herunterladen\nyt-dlp -f \"160p/worstvideo+bestaudio/worst\" -o \"vod_160p.mp4\" \"$URL\"\n\n# 3. Metadaten einbetten\nffmpeg -i vod_160p.mp4 -c copy \\\n  -metadata title=\"Twitch VOD Archiv\" \\\n  -metadata comment=\"Quelle: $URL | Gesichert: $(date -u +%Y-%m-%dT%H:%M:%SZ)\" \\\n  vod_meta.mp4\n\n# 4. In Teilstuecke von je 3886 Sekunden schneiden (Segment-Muxer ohne Neukodierung)\nffmpeg -i vod_meta.mp4 -f segment -segment_time 3886 -reset_timestamps 1 -c copy \"teil_%02d.mp4\"\n\n# 5. SHA-256 Pr\u00fcfsummen berechnen und doppelt stempeln (RFC 3161 + Bitcoin)\nshasum -a 256 teil_*.mp4 > SHA256SUMS.txt\ntwostamp SHA256SUMS.txt\n```\n\nMit dieser Kette schrumpft ein f\u00fcnfst\u00fcndiger 14-Gigabyte-Stream auf 903 Megabyte, verteilt sich auf f\u00fcnf handliche Segmente unterhalb der 200-Megabyte-Grenze und bleibt \u00fcber zwei unabh\u00e4ngige kryptografische Verfahren gegen Manipulationsvorw\u00fcrfe abgesichert.",
    "sig": "a65e640cfa14553aa5fa585fd79d562be6f494582b2fb88453e56a435ba98442f7583ce399add44c7fcc41a80545357e8436cc8f99be2797b787d3207b2d678a"
}