# Twitch VOD herunterladen: Warum Streams nach 7 Tagen verfallen und wie 160p mit Segment-Splitting 93 Prozent Speicher spart

2026-11-04 · Steven Noack · https://stevennoack.de/artikel/zeigen-ae05ae95/

## Wer ein Twitch VOD herunterladen will, verliert ungesicherte Streams nach 7 bis 60 Tagen

Während 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ündigen Übertragungen abbrechen und wie sich kurze 30-Sekunden-Ausschnitte über HTTP-Live-Streaming (HLS) ohne Gesamtdownload isolieren lassen, verlangt die vollständige Archivierung einer vergangenen Übertragung eine andere Herangehensweise. Vergangene Live-Sendungen, sogenannte Video-on-Demand-Aufzeichnungen (VODs), verbleiben nicht dauerhaft auf den Plattformservern.

Laut den offiziellen Speicherrichtlinien von Twitch (*On-Demand Content on Twitch*, help.twitch.tv, Stand November 2026) unterliegen alle archivierten Sendungen festen Löschfristen:

1. **Standard-Streamer:** Automatische Löschung nach genau 7 Tagen.
2. **Twitch Affiliates:** Automatische Löschung nach 14 Tagen.
3. **Twitch Partner sowie Prime- und Turbo-Abonnenten:** Maximale Vorhaltezeit von 60 Tagen.
4. **2K- und vertikale Streams:** Hochauflösende 2K-Streams und vertikale Übertragungen verfallen für alle Nutzergruppen, einschließlich verifizierter Partner, ausnahmslos nach 7 Tagen.
5. **Highlights und Uploads:** Für manuell erstellte Highlights gilt eine strikte kanalseitige Gesamtobergrenze von 100 Stunden.

Der Kundendienst von Twitch stellt in den offiziellen Richtlinien klar, dass abgelaufene VODs unwiederbringlich vom Server gelöscht werden. Eine nachträgliche Wiederherstellung durch den Support ist technisch ausgeschlossen. Wer eine Übertragung für Recherche, Berichterstattung oder Beweissicherung dauerhaft sichern will, muss das Material vor Ablauf dieser Fristen lokal auf eigenen Speichermedien ablegen.

## Die 160p-Auflösung senkt die Dateigröße um 93,7 Prozent und erhält den vollen Originalton

Die naheliegende Methode, einen Stream in voller Quellauflösung herunterzuladen, führt bei mehrstündigen Übertragungen 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.

Bei einer fünfstündigen Sendung (konkret gemessen an einem Teststream mit 5 Stunden, 23 Minuten und 50 Sekunden, entsprechend 19.430 Sekunden) beläuft sich das Datenvolumen auf 14,27 Gigabyte (14.268 Megabyte). Stehen auf einer mobilen Arbeits-SSD beispielsweise lediglich 7 Gigabyte freier Speicher zur Verfügung, scheitert der Download zwangsläufig an Speichermangel.

Ein kleines Prüfskript (`twitch-vod-check`) berechnet die Verteilung für die verschiedenen HLS-Profile:

| Profil | Bitrate | Dateigröße (5:23:50 h) | Ersparnis gegenüber Quelle |
|---|---|---|---|
| 1080p60 (Twitch Quelle) | 6.160 kbit/s | 13,93 GB (14.268,0 MB) | Basis |
| 720p60 (HD) | 4.660 kbit/s | 10,54 GB (10.793,7 MB) | -24,4 % |
| 480p (SD) | 1.660 kbit/s | 3,75 GB (3.845,0 MB) | -73,1 % |
| 360p (Niedrig) | 960 kbit/s | 2,17 GB (2.223,6 MB) | -84,4 % |
| 160p (Archiv mit Originalton) | 390 kbit/s | 903,3 MB | -93,7 % |
| Audio Copy (AAC nativ) | 160 kbit/s | 370,6 MB | -97,4 % |
| MP3 192 kbit/s (CBR) | 192 kbit/s | 444,7 MB | -96,9 % |
| MP3 80 kbit/s (Sprachprofil) | 80 kbit/s | 185,3 MB | -98,7 % |

Die Stufe 160p kombiniert ein stark komprimiertes Videobild (rund 230 kbit/s) mit der unveränderten 160-kbit/s-AAC-Audiospur. Dadurch sinkt der Speicherbedarf desselben fünfstündigen Streams von 14,27 Gigabyte auf 903,3 Megabyte. Das entspricht einer realen Ersparnis von 93,7 Prozent.

Der technische Vorteil liegt in der Tonspur: Twitch transkodiert das Audiosignal für niedrigere Videostufen nicht separat herunter. Die Tonspur in 160p ist bitgenau identisch mit jener des 1080p60-Streams. Alle gesprochenen Aussagen, Tonhöhen und Hintergrundgeräusche bleiben unberührt. Zugleich genügt die Bildauflösung von 284 mal 160 Pixeln bei 30 Bildern pro Sekunde, um Uhrzeiten, Bildschirmeinblendungen, Chat-Fenster und Geschehnisse auf dem Monitor visuell zuzuordnen.

## Segment-Splitting in fünf Teile hält Dateigrößen unter der 200-Megabyte-Grenze von NotebookLM

Eine ungeteilte 900-Megabyte-Videodatei stößt in redaktionellen und nachgelagerten Arbeitsabläufen auf technische Barrieren. Das Aufteilen eines Streams in fünf gleich lange Abschnitte löst drei praktische Probleme:

1. **Dateisystemgrenzen älterer Medien:** FAT32-formatierte USB-Sticks und externe Speicher erlauben keine Einzeldateien über 4 Gigabyte (exakt 4.294.967.295 Bytes). Ein 1080p-Stream bricht bei 4 Gigabyte unvollständig ab. In fünf Teile zerlegt sinkt selbst der 1080p-Stream auf 2,79 Gigabyte pro Segment und bleibt unterhalb des Dateisystemlimits.
2. **Grenzen von Cloud- und KI-Diensten:** Automatisierte Transkriptions- und Analysesysteme setzen strikte Obergrenzen für den Datei-Upload:
   - Google NotebookLM: Maximal 200 Megabyte pro Quelldatei.
   - OpenAI Whisper API: Maximal 25 Megabyte pro Audio- oder Videodatei.
   - Telegram Bot API: Maximal 50 Megabyte pro Mediendatei.
   
   Bei einem 5:24-Stunden-Stream in 160p (903,3 Megabyte gesamt) dauert jedes der fünf Teilstücke genau 1 Stunde, 4 Minuten und 46 Sekunden (3.886 Sekunden). Die Dateigröße jedes Segments liegt bei exakt 180,7 Megabyte. Damit unterschreitet jedes Teilstück das Limit von Google NotebookLM (200 Megabyte), während die Gesamtdatei abgewiesen würde.
3. **Schutz vor Dateibeschädigung:** Wenn ein fünfstündiger Download kurz vor Ende abbricht oder der MP4-Index (`moov atom`) beim Schreiben beschädigt wird, ist die gesamte Datei unbrauchbar. Segmentierte Dateien isolieren Übertragungsfehler auf einzelne Abschnitte.

Wie 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 über den Kopiermodus (`-c copy`):

```bash
ffmpeg -i vod_160p.mp4 -f segment -segment_time 3886 -reset_timestamps 1 -c copy teil_%02d.mp4
```

Weil Bild und Ton ohne Transkodierung direkt in neue MP4-Container kopiert werden, beansprucht dieser Vorgang praktisch keine Prozessorleistung. Der gesamte fünfstündige Stream ist innerhalb weniger Sekunden in fünf Teile zerlegt, ohne Generationsverlust und ohne Qualitätsminderung.

## Herkunfts-Metadaten im MP4-Container sichern die Quelle vor nachträglichen Zweifeln ab

Eine reine Videodatei auf einer Festplatte besitzt für sich genommen wenig Aussagekraft. Datumsangaben des Dateisystems lassen sich mit einfachen Systembefehlen (`touch -t`) nachträglich verändern. Um die Herkunft eines Mitschnitts zweifelsfrei zu dokumentieren, müssen Metadaten bereits beim Abruf erhoben und fest im Dateicontainer verankert werden.

Beim Abruf über das Twitch-GraphQL-Interface (`gql.twitch.tv/gql` mit der standardmäßigen 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ährend der `ETag`-Header dem MD5-Hash des Segments auf Amazons S3-Speicher entspricht.

Diese Herkunftsdaten werden beim Zusammenfügen verlustfrei in die Metadatenfelder des MP4-Containers geschrieben:

```bash
ffmpeg -i vod_160p.mp4 -c copy \
  -metadata title="Twitch VOD Sicherung" \
  -metadata comment="Quelle: https://www.twitch.tv/videos/<VOD-ID> | Stream-ID: <STREAM-ID>" \
  -metadata creation_time="<createdAt aus der GraphQL-Antwort>" \
  vod_gesichert.mp4
```

Dadurch tragen alle Segmente ihre Herkunftsinformationen direkt in den Datei-Headern, unabhängig davon, in welchem Verzeichnis oder auf welchem Datenträger sie später lagern.

## Der Doppelzeitstempel über RFC 3161 und Bitcoin belegt die Unveränderbarkeit der Datei

Um zu beweisen, dass die gesicherten Videodateien nach dem Herunterladen nicht nachträglich manipuliert, gekürzt oder verändert wurden, genügt kein lokales Dateidatum. Hier greift das Verfahren der doppelten Zeitstempelung, wie es in [twostamp: Zwei Zeitstempel für 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önlichen Wissens sind](https://stevennoack.de/artikel/gedanken-kryptografisch-verankern/) beschrieben ist.

Zunächst wird eine SHA-256-Prüfsummendatei über alle fünf Segmente erzeugt:

```bash
shasum -a 256 teil_*.mp4 > SHA256SUMS.txt
```

Anschließend versieht das Werkzeug `twostamp` die Prüfsummendatei mit zwei unabhängigen Zeitstempeln:

```bash
twostamp SHA256SUMS.txt
```

Das Skript führt zwei kryptografische Nachweise durch:

1. **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ässt sich jederzeit offline mit Standardprogrammen wie OpenSSL überprüfen (`openssl ts -verify`).
2. **Dezentraler Existenzbeweis via OpenTimestamps:** Der Hashwert wird über einen kryptografischen Merkle Tree in eine Bitcoin-Transaktion eingebettet. Sobald der Block bestätigt ist, beweist die Blockchain mathematisch, dass die Prüfsumme zu diesem Blockzeitpunkt existiert hat. Dieser Beweis ist dauerhaft haltbar, selbst wenn die ausstellende Zertifizierungsstelle ihren Betrieb einstellt.

## Die Privatkopie nach Urheberrechtsgesetz greift bei unverschlüsselten Streams ohne DRM

Das Herunterladen und Sichern öffentlich zugänglicher Twitch-Streams unterliegt dem deutschen Urheberrechtsgesetz (UrhG):

- **Recht auf Privatkopie (§ 53 Abs. 1 UrhG):** Einzelne Vervielfältigungen eines Werkes durch eine natürliche Person zum privaten Gebrauch sind auf beliebigen Trägern zulässig, sofern sie weder Erwerbszwecken dienen noch zur Herstellung eine offensichtlich rechtswidrig hergestellte oder öffentlich zugänglich gemachte Vorlage verwendet wird. Da Broadcaster ihre Streams selbst öffentlich bereitstellen, handelt es sich um eine rechtmäßige Vorlage.
- **Keine Umgehung technischer Schutzmaßnahmen (§ 95a UrhG):** Twitch verwendet für gewöhnliche Livestreams und VODs keine digitale Rechteverwaltung (DRM wie Widevine, FairPlay oder PlayReady). Die HLS-Segmente liegen unverschlüsselt als MPEG-TS- oder fMP4-Fragmente auf Content Delivery Networks. Das Auslesen der Streaming-Listen stellt keine Umgehung wirksamer technischer Schutzmaßnahmen im Sinne des Gesetzes dar.
- **Straffreiheit bei privatem Gebrauch (§ 108b Abs. 1 UrhG):** Selbst in Streitfällen über technische Barrieren stellt der Gesetzgeber klar, dass Handlungen, die ausschließlich zum eigenen privaten Gebrauch des Täters oder mit ihm persönlich verbundener Personen erfolgen, straffrei bleiben.
- **AGB-Klauseln versus Gesetz:** Abschnitt 9 der Twitch-Nutzungsbedingungen untersagt das automatisierte Herunterladen von Plattforminhalten. Dies kann zivilrechtliche Unterlassungsansprüche von Twitch begründen (etwa Kontosperren), berührt jedoch weder die gesetzliche Zulässigkeit der Privatkopie nach § 53 UrhG noch begründet es einen Straftatbestand.
- **Beweiswert im Zivilprozess (§ 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ässigkeit als Beweismittel in Gerichtsverfahren nicht allein wegen seiner elektronischen Form abgesprochen werden. In Verbindung mit dem Grundsatz der freien Beweiswürdigung nach § 286 der Zivilprozessordnung liefert die Kombination aus SHA-256-Hash, RFC-3161-Signatur und Blockchain-Verankerung die stärkste technische Absicherung gegen den Vorwurf, ein Video sei nachträglich montiert worden.

## Wo das Verfahren an Grenzen stößt: Unveröffentlichte Streams und die Grenzen einfacher Zeitstempel

Das beschriebene Verfahren ist kein Universalschlüssel und weist konkrete Grenzen auf:

1. **Unveröffentlichte Übertragungen bei deaktivierter Archivierung:** Broadcaster können im Dashboard festlegen, ob vergangene Übertragungen gespeichert werden. Hat ein Kanalbetreiber die VOD-Speicherung vollständig 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üften CloudFront-Server nach Streamende ausnahmslos HTTP-Status 403 (insgesamt 57.624 abgewiesene Anfragen). Wenn Twitch die Transkodierung nicht im Cache vorhält, ist eine nachträgliche Rekonstruktion unmöglich.
2. **Unterschied zwischen einfachen und qualifizierten Zeitstempeln:** Art. 41 Abs. 1 eIDAS garantiert die Zulässigkeit elektronischer Zeitstempel vor Gericht. Die gesetzliche Vermutung der Richtigkeit von Datum und Datenunversehrtheit nach Art. 42 eIDAS gilt jedoch nur für *qualifizierte* elektronische Zeitstempel von akkreditierten Vertrauensdiensteanbietern. Zeitstempel von Freetsa (RFC 3161) oder OpenTimestamps (Bitcoin) unterliegen als einfache Zeitstempel der freien richterlichen Beweiswürdigung nach § 286 ZPO. Im juristischen Streitfall muss die Integrität durch Vorlage der Prüfprotokolle und Zertifikatsketten dargelegt werden.
3. **Mögliche künftige DRM-Sperren:** Sollte Twitch künftig verschlüsselte HLS-Ströme oder DRM-Systeme einsetzen (etwa für exklusive Pay-per-View-Übertragungen), greift das Umgehungsverbot des § 95a UrhG. Ein Download ohne Schlüssel wäre ab diesem Moment unzulässig.

## Mit yt-dlp, FFmpeg und twostamp läuft die Archivierung vollständig im Terminal ab

Der gesamte Ablauf von der Ermittlung der HLS-Playlists über den Download in 160p, das verlustfreie Splitten bis zur kryptografischen Doppelstempelung lässt sich mit Standard-Werkzeugen im Terminal automatisieren:

```bash
# 1. Arbeitsverzeichnis anlegen und VOD-Adresse definieren
URL="https://www.twitch.tv/videos/<VOD-ID>"
mkdir -p vod_archiv && cd vod_archiv

# 2. VOD in 160p mit vollem Originalton herunterladen
yt-dlp -f "160p/worstvideo+bestaudio/worst" -o "vod_160p.mp4" "$URL"

# 3. Metadaten einbetten
ffmpeg -i vod_160p.mp4 -c copy \
  -metadata title="Twitch VOD Archiv" \
  -metadata comment="Quelle: $URL | Gesichert: $(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  vod_meta.mp4

# 4. In Teilstuecke von je 3886 Sekunden schneiden (Segment-Muxer ohne Neukodierung)
ffmpeg -i vod_meta.mp4 -f segment -segment_time 3886 -reset_timestamps 1 -c copy "teil_%02d.mp4"

# 5. SHA-256 Prüfsummen berechnen und doppelt stempeln (RFC 3161 + Bitcoin)
shasum -a 256 teil_*.mp4 > SHA256SUMS.txt
twostamp SHA256SUMS.txt
```

Mit dieser Kette schrumpft ein fünfstündiger 14-Gigabyte-Stream auf 903 Megabyte, verteilt sich auf fünf handliche Segmente unterhalb der 200-Megabyte-Grenze und bleibt über zwei unabhängige kryptografische Verfahren gegen Manipulationsvorwürfe abgesichert.