public/uni

Files

Michael Czechowski 3db80be669 add diagonal stripe pattern to klausur and aufgabe class across b course

- update klausur class with 135deg diagonal stripes
- add aufgabe class with solid background
- apply to all termin slides (0-5)

2026-01-05 17:18:27 +01:00

42 KiB

Raw Blame History

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

marp	theme	paginate	backgroundColor	header	footer	title
true	gaia	true		Dateiformate, Schnittstellen, Speichermedien & Distributionswege	Michael Czechowski – HdM Stuttgart – WS 2025/26	Dateiformate, Schnittstellen, Speichermedien & Distributionswege

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

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

Wintersemester 2025/26

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

Termin 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:

AWS schickt verschlüsseltes Gerät
Kunde kopiert Daten lokal (schnell!)
Gerät zurück an AWS
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 User 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:

Origin Server (Hauptquelle)
Edge Servers (geografisch verteilt)
User → nächster Edge Server
Erste Anfrage: Edge holt von Origin, cached
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:

User-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 User = mehr Bandbreite!)

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

BitTorrent: Wie funktioniert's?

BitTorrent (Bram Cohen, 2001):

Komponenten:

.torrent-Datei: Metadaten (Hashes, Tracker-URL)
Tracker: Vermittelt Peers
Seeders: Haben komplette Datei
Leechers: Laden noch
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)

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

Teil 2: CDN-Analyse (20 Min)

Öffne populäre Website (z.B. nytimes.com)
Browser DevTools → Network-Tab
Schaue auf Requests: Welche CDN-Domains?
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:

Stateless: Jede Anfrage eigenständig
Resource-Based: URLs = Ressourcen (/users/123)
HTTP-Methods: CRUD-Operationen
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:

Alice öffnet Chat → WebSocket-Connection
Bob öffnet Chat → Eigene Connection
Alice tippt: "Hi Bob!"
Client sendet: {"type": "message", "text": "Hi Bob!", "to": "bob"}
Server leitet an Bobs Connection weiter
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)

Öffentliche API: jsonplaceholder.typicode.com
Tool: curl (Terminal) oder Postman (GUI)
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}'

Analysiere: Status-Code, Headers, Body

Teil 2: WebSocket (20 Min)

Öffne: websocket.org/echo.html
Verbinde, sende Nachrichten
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ünstler, Album, Jahr, Genre, Cover
PDF: Autor, 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

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ünstler, 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:

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

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

PDF-Metadaten: Hidden Dangers

PDF-Metadaten (XMP):

Gespeichert:

Titel, Autor, 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ützen 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

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:

Migration: Regelmäßig in aktuelle Formate konvertieren
Emulation: Alte Software in VM
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)

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

Teil 2: ID3 (20 Min)

Nimm MP3-Datei
Analysiere: Kid3, mp3tag, oder exiftool
Ändere Tags (z.B. falscher Artist)
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:

Neuronale Bild-Kompression:
- Deep Learning lernt Kompression/Dekompression
- Google's "Learned Image Compression" (2018)
- Outperforms JPEG bei gleicher Größe
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
User 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 User
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:

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

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

Alternative Szenarien (Auswahl)

Mittelständisches Medienunternehmen (Videos, Streaming)
Kommunales Stadtarchiv (Digitalisierung historischer Bestände)
Agentur für digitale Kommunikation (internationale Kampagne)
Digitale Hochschul-Mediathek (Lehrvideos, Podcasts)
Freiberufliche Fotografin (Tausende RAW-Fotos/Jahr)
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: mail@librete.ch 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/

42 KiB Raw Blame History Unescape Escape

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

Termin 4 – 30.01.2026

Distribution, APIs & Zukunft

Das Problem: Daten müssen reisen

AWS Snowball

Physische Distribution

Zentralisierte Distribution

CDNs: Content Delivery Networks

CDN-Strategien

Netflix: Fallstudie CDN

P2P: Peer-to-Peer

BitTorrent: Wie funktioniert's?

BitTorrent & Piraterie

IPFS: Dezentrales Web?

Streaming: Real-Time-Distribution

Hands-On: Torrent & CDN

Dateitransfer-Protokolle

Teil 2: APIs

Software-Schnittstellen & Protokolle

Was ist eine API?

HTTP: Das Fundament

HTTP-Methods: CRUD

REST: Representational State Transfer

REST-Probleme

GraphQL: Die REST-Alternative

GraphQL Schema

WebSockets: Real-Time

WebSocket: Chat-Beispiel

gRPC: Google's Approach

gRPC Beispiel

JSON: Das Standard-Format

Hands-On: API abfragen

Teil 3: Metadaten

Daten über Daten & Interoperabilität

Was sind Metadaten?

EXIF: Exchangeable Image File Format

EXIF: Privacy-Albtraum

Social Media & EXIF-Stripping

ID3-Tags: Musik-Metadaten

MusicBrainz: Offene Musik-Datenbank

Dublin Core: Universelle Metadaten

PDF-Metadaten: Hidden Dangers

Interoperabilität: Offene vs. Proprietäre

Vendor Lock-in: Beispiele

Datenmigration & Langzeitarchivierung

Metadaten für Accessibility

Hands-On: Metadaten analysieren & entfernen

Teil 4: Zukunft

Trends & Ausblick

AI-basierte Kompression

JPEG XL: Der moderne JPEG

AV1 & VVC: Codec-Krieg

DNA-Storage

Holografischer Speicher

Quantum Storage?

Web3 & Dezentraler Speicher

Streaming-Zukunft

Nachhaltigkeit

Regulierung & Standardisierung

Fallstudie: Gruppenarbeit

Alternative Szenarien (Auswahl)

Was wir insgesamt gelernt haben

Weiterführende Ressourcen

Abschluss & Dank

Fragen & Diskussion

Lizenz & Attribution

42 KiB

Raw Blame History