uni/slides/223015b/04-distribution-apis-zukunft.md

marp, theme, paginate, backgroundColor, header, footer, title

marp	theme	paginate	backgroundColor	header	footer	title
true	gaia	true		Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)	Michael Czechowski – HdM Stuttgart – SoSe 2026	Dateiformate, Schnittstellen, Speichermedien & Distributionswege

<style> :root { --color-foreground: #1a1a2e; --color-highlight: #1e5f8a; --color-dimmed: #4a4a6a; } section.invert { --color-foreground: #fff; } section { font-size: 1.7rem; } h1 { color: #1e5f8a; } section.invert h1 { color: #fff; } h2 { color: #1f2937; } pre { background: #0f0f23; color: #5fb3e4; border-radius: 8px; border-left: 3px solid #1e5f8a; } pre code { background: transparent; color: inherit; } code { background: #0f0f23; padding: 0.15em 0.4em; border-radius: 4px; font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; } section code:not(.hljs) { color: #5fb3e4 !important; } section code.hljs { color: #f8f8f8 !important; } a { color: var(--color-highlight); } section.klausur { background: repeating-linear-gradient( 135deg, #e3f2fd, #e3f2fd 40px, #fff 40px, #fff 80px ) !important; } @media print { section.klausur { background: #e3f2fd !important; } } section.aufgabe { background: #e3f2fd !important; } section.aufgabe footer { display: none; } </style>

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

223015b · Modul "Technik 1" · 1. Semester Digital- und Medienwirtschaft Hochschule der Medien Stuttgart

Sommersemester 2026

https://librete.ch/hdm/223015b/

---

---

Kapitel 4 – 30.01.2026

Distribution, APIs & Zukunft

---

---

Das Problem: Daten müssen reisen

Szenario: 100 TB von Berlin nach München

Option 1: Internet-Upload

• 1 Gbps Uplink = 125 MB/s
• Zeit: 9,3 Tage (non-stop!)

Option 2: Festplatte per Post

• 10× 10TB HDDs (~2.000€)
• Kopieren: ~10 Stunden
• Versand: 1-2 Tage
• Gesamt: ~3 Tage

"Never underestimate the bandwidth of a station wagon full of tapes." — Andrew Tanenbaum (1981)

---

---

AWS Snowball

AWS Snowball (seit 2015):

Problem: Petabytes on-premise → AWS-Cloud

Geräte:

• Snowball Edge: 100 TB
• Snowmobile: 100 PB (Container auf LKW!)

Prozess:

1. AWS schickt verschlüsseltes Gerät
2. KundIn kopiert Daten lokal (schnell!)
3. Gerät zurück an AWS
4. AWS lädt in S3 hoch

Kosten: Günstiger als Internet-Transfer bei >10 TB

---

---

Physische Distribution

CD (1982): 700 MB DVD (1995): 4,7 GB / 8,5 GB Blu-ray (2006): 25 GB / 50 GB / 100 GB

Problem heute:

• Games: 50-150 GB (Call of Duty: 200+ GB!)
• Filme: Streaming überholt Blu-ray
• Disc = "License Key", Rest wird geladen

---

---

Zentralisierte Distribution

Klassisches Modell: Ein Server, viele Clients

Problem: 1 Million Nutzende wollen 1 GB-Datei → Server braucht 1 PB Bandbreite! → Server überlastet → "Hug of Death"

Lösung: Content Delivery Networks (CDNs)

---

---

CDNs: Content Delivery Networks

CDN = Verteiltes Netzwerk weltweit

Funktionsweise:

1. Origin Server (Hauptquelle)
2. Edge Servers (geografisch verteilt)
3. Nutzende → nächster Edge Server
4. Erste Anfrage: Edge holt von Origin, cached
5. Weitere Anfragen: Direkt vom Edge (schnell!)

Vorteile: ✓ Reduzierte Latenz (geografische Nähe) ✓ Last-Verteilung ✓ Bandbreitenersparnis

---

CDN-Strategien

Static Content:

• Bilder, CSS, JS, Videos
• Lange Cache-Zeit (TTL: Tage/Wochen)

Dynamic Content:

• Nutzungs-spezifisch (Profil)
• Kurze TTL oder nicht cachebar

Cache Invalidation:

• Versioning (style.css → style.v2.css)
• Cache-Purge (manuell leeren)

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

---

---

Netflix: Fallstudie CDN

Netflix Open Connect (eigenes CDN):

Strategie:

• Server IN ISP-Rechenzentren (Telekom, Vodafone...)
• Popular Content vorgeladen (Predictive Caching)
• 95%+ Traffic vom lokalen ISP-Server

Zahlen (2024):

• 200M+ Subscriber
• ~15% des globalen Internet-Traffics!
• Ohne CDN: Unmöglich

---

---

P2P: Peer-to-Peer

P2P = Jeder ist Client UND Server

Philosophie: Dezentralisierung

Anwendungen:

• BitTorrent (File-Sharing)
• IPFS (InterPlanetary File System)
• Blockchain (Bitcoin, Ethereum)

Vorteil: Skalierbar (mehr Nutzende = mehr Bandbreite!)

Nachteil: Langsam bei wenigen Peers, oft für Piraterie missbraucht

---

---

BitTorrent: Wie funktioniert's?

BitTorrent (Bram Cohen, 2001):

Komponenten:

1. .torrent-Datei: Metadaten (Hashes, Tracker-URL)
2. Tracker: Vermittelt Peers
3. Seeders: Haben komplette Datei
4. Leechers: Laden noch
5. Swarm: Alle Peers zusammen

Mechanismus:

• Datei in Chunks (z.B. 256 KB)
• Jeder Peer lädt von verschiedenen Peers
• "Tit-for-tat": Wer uploaded, lädt schneller

---

---

BitTorrent & Piraterie

2000er: Musik-/Film-Piraterie-Revolution

Napster (1999-2001): Zentralisiert → Verklagt, Shutdown

BitTorrent (2001+): Dezentral → Schwerer zu verklagen

The Pirate Bay (2003): BitTorrent-Index

• Blockiert, zieht um, neue Domains
• Whack-a-Mole-Spiel

Rechtliche Grauzone:

• Protokoll selbst: Legal
• Inhalte: Oft illegal (Urheberrecht)
• Legitime Uses: Linux-ISOs, Open-Source, Public Domain

---

---

IPFS: Dezentrales Web?

IPFS = InterPlanetary File System (2015)

Vision: Web ohne Server

Funktionsweise:

• Content-Addressable: Dateien durch Hash identifiziert
• CID: Content Identifier (QmXyZ123...)
• Datei auf vielen Knoten (wie BitTorrent, aber persistent)
• Abruf: "Gib mir Datei mit Hash X" (egal wo)

Vorteile: Zensur-resistent, kein Single Point of Failure

Nachteile: Langsam (noch), keine Verfügbarkeitsgarantie

Anwendung: NFT-Speicher

---

---

Streaming: Real-Time-Distribution

Streaming = Daten während Empfang konsumiert

Protokolle:

• HLS (Apple): HTTP-basiert, Segmente
• MPEG-DASH: Standard, ähnlich HLS
• WebRTC: Browser-zu-Browser, niedrige Latenz

Adaptive Bitrate:

• Stream in mehreren Qualitäten (240p-4K)
• Player wechselt dynamisch
• Segmente: 2-10 Sekunden

Latenz:

• Traditional (HLS): 10-30 Sekunden
• Low-Latency HLS: 2-5 Sekunden
• WebRTC: <1 Sekunde (Videocalls)

---

Hands-On: Torrent & CDN

Aufgabe (40 Min):

Teil 1: BitTorrent (20 Min)

1. Lade legalen Torrent (Linux-ISO: ubuntu.com)
2. Tool: qBittorrent oder Transmission
3. Beobachte: Peers, Seeders, Download-Speed, Upload-Speed

Teil 2: CDN-Analyse (20 Min)

1. Öffne populäre Website (z.B. nytimes.com)
2. Browser DevTools → Network-Tab
3. Schaue auf Requests: Welche CDN-Domains?
4. Response-Headers: X-Cache, CF-Ray, etc.

Tools: cdn77.com/cdn-check

---

Dateitransfer-Protokolle

FTP (File Transfer Protocol, 1971):

• Ältestes Internet-Protokoll für Dateitransfer
• ⚠️ Unverschlüsselt! (Passwort im Klartext)
• SFTP/FTPS: Sichere Varianten

WebDAV (Web-based Distributed Authoring):

• HTTP-basiert → Firewall-freundlich
• Wird von vielen Cloud-Diensten genutzt
• Mountbar als Netzlaufwerk

Moderne Alternativen: rsync, rclone, Cloud-APIs

---

Teil 2: APIs

Software-Schnittstellen & Protokolle

---

---

Was ist eine API?

API = Application Programming Interface

Analogie: Restaurant

• Du (Client) → Speisekarte (API-Dokumentation)
• Bestellst (Request)
• Küche bereitet zu (Backend)
• Kellner bringt Essen (Response)
• Du weißt nicht, WIE gekocht wird – nur WAS du kriegst

Typen: Hardware-APIs, OS-APIs, Web-APIs, Library-APIs

---

---

HTTP: Das Fundament

HTTP = HyperText Transfer Protocol (1991)

Request-Struktur:

• Method: GET, POST, PUT, DELETE
• URL: Resource-Identifier
• Headers: Metadaten (Content-Type, Authorization...)
• Body: Optional (bei POST/PUT)

Response-Struktur:

• Status Code: 200 OK, 404 Not Found, 500 Error
• Headers: Metadaten
• Body: HTML, JSON, XML, Binary...

---

HTTP-Methods: CRUD

CRUD = Create, Read, Update, Delete

Method	CRUD	Beispiel
GET	Read	/posts → Alle Posts
POST	Create	/posts → Neuer Post
PUT	Update	/posts/42 → Post ersetzen
PATCH	Update	/posts/42 → Teilupdate
DELETE	Delete	/posts/42 → Post löschen

GET = Idempotent (mehrfach ausführen = gleiches Ergebnis)

---

---

REST: Representational State Transfer

REST (Roy Fielding, 2000):

Prinzipien:

1. Stateless: Jede Anfrage eigenständig
2. Resource-Based: URLs = Ressourcen (/users/123)
3. HTTP-Methods: CRUD-Operationen
4. Hypermedia: Links zu verwandten Ressourcen

Beispiel: Twitter-API

GET /tweets/123           → Tweet mit ID 123
POST /tweets              → Neuen Tweet erstellen
DELETE /tweets/123        → Tweet löschen
GET /users/alice/tweets   → Tweets von Alice

---

REST-Probleme

Problem 1: Over-Fetching

GET /users/123
→ Gibt zurück: Name, Email, Bio, Avatar, 
  Follower-Count, Posts, Friends...

Du willst nur Name → Kriegst 90% zu viel

Problem 2: Under-Fetching

GET /users/123        → User-Daten
GET /users/123/posts  → Alle Posts

2 Requests statt einem

Lösung: GraphQL

---

---

GraphQL: Die REST-Alternative

GraphQL (Facebook, 2015):

Idee: Client fragt EXAKT, was er braucht

Query-Beispiel:

{
  user(id: 123) {
    name
    email
    posts(limit: 5) {
      title
      createdAt
    }
  }
}

Vorteile: ✓ Kein Over-/Under-Fetching ✓ Ein Endpoint (/graphql) ✓ Strongly Typed (Schema!)

---

GraphQL Schema

type User {
  id: ID!
  name: String!
  email: String
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
}

type Query {
  user(id: ID!): User
  posts: [Post!]!
}

type Mutation {
  createPost(title: String!, content: String!): Post!
}

! = Required (non-nullable)

---

---

WebSockets: Real-Time

Problem mit HTTP:

• Request-Response-Zyklus
• Server kann nicht "pushen"
• Polling ineffizient

WebSocket (2011):

• Bidirektionale Verbindung
• Bleibt offen (Persistent)
• Server kann jederzeit senden

Anwendungen: Chat (Discord), Live-Updates (Aktienkurse), Multiplayer-Games

---

WebSocket: Chat-Beispiel

Flow:

1. Alice öffnet Chat → WebSocket-Connection
2. Bob öffnet Chat → Eigene Connection
3. Alice tippt: "Hi Bob!"
4. Client sendet: {"type": "message", "text": "Hi Bob!", "to": "bob"}
5. Server leitet an Bobs Connection weiter
6. Bob empfängt, zeigt an

Kein Polling! Instant!

---

---

gRPC: Google's Approach

gRPC = Google Remote Procedure Call (2015)

Idee: Funktion auf Remote-Server aufrufen, als wäre es lokal

Eigenschaften:

• Protocol Buffers (Protobuf): Binär, kompakt (statt JSON)
• HTTP/2: Multiplexing, Bidirektional
• Strongly Typed
• Code-Generierung (Client/Server aus .proto-Datei)

Vorteile: Performance, Streaming Nachteile: Nicht Browser-kompatibel, Debugging schwieriger

---

gRPC Beispiel

.proto-Datei:

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
  rpc ListPosts (Empty) returns (stream Post);
}

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

Code-Generierung: Client/Server-Code automatisch generiert

---

JSON: Das Standard-Format

JSON = JavaScript Object Notation

Eigenschaften:

• Textbasiert, menschenlesbar
• Schlüssel-Wert-Paare
• Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null

Beispiel:

{
  "name": "Alice",
  "age": 28,
  "posts": [
    {"title": "Hello", "views": 42},
    {"title": "World", "views": 123}
  ]
}

---

Hands-On: API abfragen

Aufgabe (40 Min):

Teil 1: REST-API (20 Min)

1. Öffentliche API: jsonplaceholder.typicode.com
2. Tool: curl (Terminal) oder Postman (GUI)
3. Beispiele:

curl https://jsonplaceholder.typicode.com/posts/1
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Test","body":"Hello","userId":1}'

4. Analysiere: Status-Code, Headers, Body

Teil 2: WebSocket (20 Min)

1. Öffne: websocket.org/echo.html
2. Verbinde, sende Nachrichten
3. Beobachte: Instant Response

---

Teil 3: Metadaten

Daten über Daten & Interoperabilität

---

---

Was sind Metadaten?

Metadaten = Daten über Daten

Beispiele:

• Foto: Kamera, Datum, GPS, Belichtung
• MP3: KünstlerInnen, Album, Jahr, Genre, Cover
• PDF: AutorIn, Datum, Software
• E-Mail: Absender, Empfänger, Zeitstempel

Warum wichtig? ✓ Organisation, Suche ✓ Kontext (Wann/Wo/Wie?)

Aber auch: ❌ Privacy-Risiko, Forensische Spuren

---

EXIF: Exchangeable Image File Format

EXIF (1995, Kamera-Hersteller):

Typische Daten:

• Kamera-Modell (z.B. "iPhone 15 Pro")
• Datum & Uhrzeit
• Belichtung (Blende, Verschlusszeit, ISO)
• GPS-Koordinaten (Latitude, Longitude, Altitude)
• Software (z.B. "Photoshop 2024")

Speicherort: JPEG-Header (Binärformat)

Tools: exiftool, ExifPurge, metapicz.com

---

---

EXIF: Privacy-Albtraum

Szenario 1: Stalking

• Foto auf Twitter: "Zuhause entspannen 🏡"
• EXIF: GPS 52.5200° N, 13.4050° E
• → Stalker weiß, wo du wohnst

Szenario 2: Whistleblowing

• Anonyme Quelle schickt PDF
• Metadaten: "Erstellt von: John Doe, Firma XY"
• → Quelle identifiziert

Berühmter Fall: John McAfee (2012): Vice-Magazine vergaß EXIF zu entfernen → GPS verriet Aufenthaltsort in Guatemala

---

Social Media & EXIF-Stripping

Welche Plattformen entfernen EXIF?

✓ Twitter/X: Ja (seit 2015) ✓ Facebook/Instagram: Ja (GPS entfernt) ✓ Reddit: Ja ❌ WhatsApp: Nein (privat, aber Metadaten bleiben) ❌ E-Mail-Anhänge: Nein ❌ Cloud (Dropbox, Google Drive): Nein

Best Practice: EXIF manuell entfernen vor Upload

exiftool -all= foto.jpg  # Entfernt ALLE Metadaten

---

---

ID3-Tags: Musik-Metadaten

ID3 = Identification 3 (1996)

Versionen:

• ID3v1: 128 Bytes am Ende (limitiert!)
  • Titel (30 Zeichen), Artist, Album, Jahr
• ID3v2: Am Anfang, variable Länge
  • Unbegrenzte Textfelder, Cover-Art, Lyrics, BPM

Tools:

• Kid3 (GUI, Multi-Platform)
• MusicBrainz Picard (Auto-Tagging!)
• mp3tag (Windows)

---

---

MusicBrainz: Offene Musik-Datenbank

MusicBrainz (2000):

Idee: Wikipedia für Musik-Metadaten

Community-gepflegt:

• KünstlerInnen, Alben, Tracks
• Relationships (Band-Mitglieder, Label...)
• Releases (verschiedene Editionen, Länder)

MusicBrainz Picard:

• Audio-Fingerprinting (AcoustID)
• Analysiert Waveform, matched mit Datenbank
• Auto-Tagging (auch bei falsch benannten Dateien!)

Philosophie: Open Data (gegen proprietäre Gracenote/CDDB)

---

Dublin Core: Universelle Metadaten

Dublin Core (1995, Dublin, Ohio):

15 Kern-Elemente:

1. Title, 2. Creator, 3. Subject, 4. Description
2. Publisher, 6. Contributor, 7. Date, 8. Type
3. Format, 10. Identifier (ISBN, DOI)
4. Source, 12. Language, 13. Relation
5. Coverage, 15. Rights

Anwendung: Bibliotheken, Archive, Webseiten (HTML <meta>)

---

---

PDF-Metadaten: Hidden Dangers

PDF-Metadaten (XMP):

Gespeichert:

• Titel, AutorIn, Betreff, Keywords
• Erstellungsdatum, Änderungsdatum
• Software, Company (aus Office-Lizenz!)

Versteckte Daten:

• Änderungshistorie (Track Changes)
• Kommentare (vermeintlich gelöscht)
• Ebenen (InDesign, Illustrator)

Berühmter Fall: Tony Blair Dossier (2003, Irak-Krieg) → PDF-Metadaten zeigten Manipulation

---

Interoperabilität: Offene vs. Proprietäre

Offene Formate: ✓ Spezifikation öffentlich ✓ Keine Lizenzgebühren ✓ Viele Programme unterstützen1 Beispiele: PNG, OGG, MKV, Markdown, SVG

Proprietäre Formate: ❌ Spezifikation geheim ❌ Oft nur in einer Software voll nutzbar ❌ Lock-in-Effekt Beispiele: PSD (Photoshop), INDD (InDesign), DWG (AutoCAD), .pages

111

Vendor Lock-in: Beispiele

Fall 1: Microsoft Office (.docx)

• Historisch: .doc undokumentiert
• LibreOffice konnte nicht perfekt konvertieren
• "Formatierung kaputt" → Zurück zu MS Office

Fall 2: Adobe Creative Suite

• PSD: Layer, Blend-Modes → Nur in Photoshop voll editierbar
• GIMP kann öffnen, aber Features fehlen

Fall 3: Apple Ecosystem

• .pages, .numbers, .key → Nur auf Apple native Bearbeitung

---

Datenmigration & Langzeitarchivierung

Beispiele toter Formate:

• WordPerfect (.wpd) – 1980-90er dominant, heute kaum lesbar
• Lotus 1-2-3 (.wks) – Spreadsheet, verschwunden
• Flash (.swf) – Millionen Websites/Games, seit 2020 tot

Archivierungs-Strategien:

1. Migration: Regelmäßig in aktuelle Formate konvertieren
2. Emulation: Alte Software in VM
3. Offene Standards: PDF/A, TIFF, Plain Text

---

Metadaten für Accessibility

Alt-Text (Alternative Text):

<img src="cat.jpg" alt="Orange tabby cat sleeping on windowsill">

Warum? ✓ Screen-Reader (Blinde/Sehbehinderte) ✓ SEO (Suchmaschinen) ✓ Fallback (Bild lädt nicht)

PDF-Tags: Strukturierte PDFs (Überschriften, Listen) → Screen-Reader kann navigieren

Video: Closed Captions (CC), Audio Descriptions

---

Hands-On: Metadaten analysieren & entfernen

Aufgabe (40 Min):

Teil 1: EXIF (20 Min)

1. Nimm Foto (oder nutze altes)
2. Analysiere: exiftool foto.jpg oder metapicz.com
3. Notiere: GPS? Kamera-Modell? Software?
4. Entferne: exiftool -all= foto.jpg
5. Vergleiche Dateigrößen

Teil 2: ID3 (20 Min)

1. Nimm MP3-Datei
2. Analysiere: Kid3, mp3tag, oder exiftool
3. Ändere Tags (z.B. falscher Artist)
4. Optional: MusicBrainz Picard (Auto-Tagging)

---

Teil 4: Zukunft

Trends & Ausblick

---

---

AI-basierte Kompression

Problem: JPEG/H.264 basieren auf 90er-Jahre-Modellen

Neue Ansätze:

1. Neuronale Bild-Kompression:

   • Deep Learning lernt Kompression/Dekompression
   • Google's "Learned Image Compression" (2018)
   • Outperforms JPEG bei gleicher Größe

2. Generative Kompression:

   • Encoder extrahiert semantische Features
   • Decoder generiert Bild neu (wie DALL-E)
   • 99%+ Kompression, aber nicht bit-genau!

Problem: Hoher Rechenaufwand, keine Standardisierung

---

---

JPEG XL: Der moderne JPEG

JPEG XL (2021, ISO-Standard):

Ziele: ✓ 60% besser als JPEG ✓ Besser als WebP/AVIF (manchmal) ✓ Lossless UND Lossy ✓ Progressive Decoding (wie klassisches JPEG) ✓ Rückwärtskompatibel (JPEG → JPEG XL "Wrapper")

Features: HDR, Animation (wie GIF, aber besser)

Status 2025: Browser-Support langsam (Safari ja, Chrome on-off)

Problem: Google favorisiert WebP/AVIF → politischer Kampf

---

AV1 & VVC: Codec-Krieg

AV1 (Alliance for Open Media): ✓ Etabliert sich (YouTube 4K, Netflix) ✓ Hardware-Decoder in neuen GPUs/Smartphones

VVC (H.266, 2020):

• 50% besser als H.265
• Aber: Patent-Problem (mehrere Pools, unklare Kosten)
• Adoption gering

LCEVC: Add-on für existierende Codecs

Zukunft:

• AV2 (Nachfolger AV1) in Entwicklung
• ML integriert?

---

---

DNA-Storage

Konzept: Daten in DNA-Sequenzen

Eigenschaften:

• Speicherdichte: 215 Petabyte/Gramm
• Haltbarkeit: Tausende Jahre
• Kosten: Aktuell $3.500/MB (sinkend)

Beispiele:

• Microsoft + Twist Bioscience
• Netflix "Biohackers"-Episode (2021)
• Harvard: Wikipedia (11 GB) in DNA (2017)

Problem: Synthese & Sequenzierung extrem langsam/teuer

Anwendung: Langzeitarchivierung (nicht Live-Daten)

---

Holografischer Speicher

Holographic Data Storage:

Prinzip:

• Laser schreibt in 3D-Kristall (statt 2D-Oberfläche)
• Interferenzmuster speichert Bits
• Paralleler Zugriff (schnell!)

Vorteile: ✓ Hohe Dichte (Terabytes pro Disc) ✓ Schnelle Lesegeschwindigkeit ✓ Langlebig (50+ Jahre)

Stand 2025: Prototypen (Sony, InPhase †), Kommerzialisierung gescheitert

Problem: Teuer, Konkurrenz durch SSDs

---

Quantum Storage?

Quantenspeicher:

Konzept:

• Qubits statt klassische Bits
• Superposition: 0 UND 1 gleichzeitig
• Verschränkung: Qubits korreliert über Distanz

Anwendung:

• Nicht für klassische Daten (Qubits instabil)
• Quantum Key Distribution (QKD) für Kommunikation
• Zukunft: Quanten-RAM für Quantencomputer

Stand 2025: Experimentell, Speicherzeit Millisekunden

---

Web3 & Dezentraler Speicher

IPFS, Filecoin, Arweave, Storj:

Idee: Speicher ohne zentrale Server

Filecoin (2017):

• Blockchain-basiert
• Nutzende vermieten Festplatten-Platz
• Bezahlung in FIL (Kryptowährung)

Arweave (2018):

• "Permanent Storage"
• Einmalige Zahlung → Daten für immer (theoretisch)

Kritik: ❌ Langsam vs. AWS S3 ❌ Teurer (oft) ❌ Keine Garantie (Nodes offline)

---

Streaming-Zukunft

Trends:

8K-Streaming:

• 7680×4320 = 33 Megapixel/Frame
• Braucht 100+ Mbps (selbst mit AV1)
• Problem: Kaum Content, kaum TVs

VR/AR-Streaming:

• 2× 4K (pro Auge), 90-120 fps
• Latenz <20ms kritisch
• 5G + Edge Computing nötig

Cloud Gaming:

• Spiel im Rechenzentrum, Stream zu Nutzenden
• Input-Lag = Todfeind (<50ms)

Problem: Physik (Lichtgeschwindigkeit!)

---

Nachhaltigkeit

Digitalisierung ≠ Umweltfreundlich

Rechenzentren:

• 2024: 1-2% globaler Stromverbrauch (steigend!)
• Kühlung, Server, Netzwerk

Streaming:

• 1h Netflix (HD): ~3 GB, ~0,1 kWh
• × Milliarden Stunden = massiver CO₂

E-Waste:

• Smartphones: 2-3 Jahre Lebensdauer
• SSDs, HDDs: Nicht ewig

Lösungen:

• Effizientere Codecs (weniger Bandbreite)
• Renewable Energy für Rechenzentren
• Längere Hardware-Lebensdauer (Right to Repair!)

---

Regulierung & Standardisierung

Wer entscheidet?

Standards-Organisationen:

• ISO/IEC (International)
• IETF (Internet-Protokolle)
• W3C (Web-Standards)
• IEEE (Hardware)

Problem: Industrie-Dominanz

• MPEG-LA (Patent-Pools)
• USB-IF (Intel-dominiert)
• HDMI Forum (Consumer-Electronics)

EU-Regulierung:

• USB-C-Pflicht (ab 2024)
• DMA (Digital Markets Act): Interoperabilität
• GDPR: Datenschutz (betrifft Metadaten!)

Zukunft: Mehr Open Standards? Oder Fragmentierung?

---

Fallstudie: Gruppenarbeit

Aufgabe (90 Min, ca. 5 Personen):

Szenario: Mittelständisches Medienunternehmen produziert Videos

Erarbeitet Konzept für:

1. Speichermedien (intern/extern, kurz-/langfristig)
2. Dateiformate (Produktion, Distribution, Archivierung)
3. Dateisysteme (welche für was?)
4. Schnittstellen (SATA, USB, PCIe, Netzwerk)
5. Distributionswege (NAS, Cloud, FTP)
6. Backup-Strategie (3-2-1-Regel!)

Ergebnis: Konzeptpapier (Mindmap, Tabelle, Poster) Präsentation: 5 Min pro Gruppe

---

Alternative Szenarien (Auswahl)

1. Mittelständisches Medienunternehmen (Videos, Streaming)
2. Kommunales Stadtarchiv (Digitalisierung historischer Bestände)
3. Agentur für digitale Kommunikation (internationale Kampagne)
4. Digitale Hochschul-Mediathek (Lehrvideos, Podcasts)
5. Freiberufliche Fotografin (Tausende RAW-Fotos/Jahr)
6. Internationales Reporterteam (investigative Recherche, sensibel)

Jede Gruppe wählt ein Szenario

---

Was wir insgesamt gelernt haben

✓ Bits → Formate: Encoding, Kompression (MP3, JPEG, H.264) ✓ Speicher: HDD, SSD, Dateisysteme, Backup, Archivierung ✓ Schnittstellen: USB-C, HDMI, DisplayPort, Ethernet ✓ Distribution: CDN, P2P, Streaming, APIs ✓ Metadaten: EXIF, ID3, Privacy, Interoperabilität ✓ Zukunft: AI-Kompression, DNA-Storage, Nachhaltigkeit

Kernbotschaft: Digitale Medien sind das Ergebnis von Standards, Politik, Kompromissen & Innovation.

Ihr habt jetzt die Werkzeuge, um die digitale Welt kritisch zu verstehen.

---

Weiterführende Ressourcen

Bücher:

• "Code" – Charles Petzold (Basics)
• "Understanding Digital Signal Processing" – Richard Lyons

Websites:

• IETF RFCs (ietf.org)
• FFmpeg Documentation (ffmpeg.org)
• Protocol Labs (IPFS, Filecoin)

YouTube:

• Computerphile (Kompression, Encoding)
• Branch Education (Hardware-Visualisierungen)

Podcasts:

• Command Line Heroes (Red Hat)

Tools: MediaInfo, exiftool, FFmpeg, Wireshark

---

Abschluss & Dank

Ihr habt gelernt:

• Dateien zu lesen (Hex, Metadaten)
• Formate zu vergleichen (JPEG vs. PNG, H.264 vs. AV1)
• Infrastruktur zu verstehen (CDN, P2P, APIs)
• Kritisch zu denken (Open Standards, Lock-in, Nachhaltigkeit)

Nächste Schritte:

• Fallstudie (falls Prüfungsleistung)
• Feedback willkommen (E-Mail)
• Weiterlernen mit Ressourcen

Vielen Dank für eure Aufmerksamkeit!

---

Fragen & Diskussion

Kontakt: lb-czechowski@hdm-stuttgart.de Folien: Online verfügbar unter https://librete.ch/hdm/223015b

---

Lizenz & Attribution

Diese Präsentation ist lizenziert unter Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

• Erlaubt Teilen & Anpassen mit Namensnennung
• Adaptionen müssen unter gleicher Lizenz geteilt werden

Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/