Files

T

libretech 8005f8c280 initial project setup for hdm dateiformate slides

2025-12-14 08:19:11 +01:00

88 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 – SoSe 2025	Dateiformate, Schnittstellen, Speichermedien & Distributionswege

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

Medienwissenschaften Hochschule der Medien Stuttgart

Michael Czechowski Wintersemester 2025/26

Kursübersicht

Ziel: Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken

10 Wochen:

Wochen 1-4: Formate & Kompression
Wochen 5-6: Speicher & Schnittstellen
Wochen 7-9: Distribution, APIs & Metadaten
Woche 10: Zukunft & Synthese

Woche 1

Von Bits zu Bedeutung

Mysterium

89 50 4E 47 0D 0A 1A 0A 
00 00 00 0D 49 48 44 52
00 00 01 90 00 00 01 2C

Was ist das?

Das Bit

Kleinste Informationseinheit

0 oder 1
AN oder AUS
Strom fließt oder nicht

Das Byte

8 Bits = 1 Byte

0 1 0 0 1 1 0 1

Wie viele Kombinationen? 2⁸ = 256 Möglichkeiten (0-255)

Was kann man mit 256 Zuständen machen?

256 Zeichen (Buchstaben, Zahlen, Symbole)
256 Graustufen (0 = Schwarz, 255 = Weiß)
256 Lautstärkestufen
Zahlen 0-255 (oder -128 bis +127)

Farben: RGB-Modell

1 Pixel = 3 Bytes

Rot: 0-255
Grün: 0-255
Blau: 0-255

Beispiel: FF 00 00 = Rot 00 FF 00 = Grün FF FF FF = Weiß

Das Problem: Sprachen

Die Welt hat mehr als 256 Zeichen!

Englisches Alphabet: 52 (A-Z, a-z)
- Ziffern: 10 (0-9)
- Sonderzeichen: ~30

≈ 90 Zeichen → passt in 1 Byte

Aber: ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀

→ 1 Byte reicht nicht!

Unicode: Ein Standard für alle

Unicode (1991): Jedes Schriftsystem der Welt

>150.000 Zeichen:

Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch...
Mathematische Symbole, Emoji, historische Schriften

UTF-8: Variable Länge (1-4 Bytes pro Zeichen)

Beispiel: Bytes zählen

Text: "Why the fuck braucht 💩 4 Bytes?!"

W h y   → je 1 Byte (4 Bytes)
t h e   → je 1 Byte (4 Bytes)
f u c k → je 1 Byte (4 Bytes)
        → 1 Byte (Leerzeichen)
b r a u c h t → je 1 Byte (7 Bytes)
        → 1 Byte
💩      → 4 Bytes! (0xF0 9F 92 A9)
        → 1 Byte
4   B y t e s ? ! → je 1 Byte (9 Bytes)

Gesamt: 37 Bytes

Hexadezimal: Lesbarkeit

Binär ist unleserlich: 01001101 01010000 00110011

Hexadezimal (Base 16): 4D 50 33 (= "MP3" in ASCII)

Jede Hex-Ziffer = 4 Bits 0-9, A-F (10=A, 11=B, ..., 15=F)

Magic Numbers

Dateityp-Identifikation durch erste Bytes

Format	Magic Number (Hex)	ASCII
PNG	`89 50 4E 47 0D 0A 1A 0A`	`.PNG`
JPEG	`FF D8 FF`	`ÿØÿ`
PDF	`25 50 44 46`	`%PDF`
ZIP	`50 4B 03 04`	`PK`

Hands-On: Mystery Files

Aufgabe (30 Min):

Drei Dateien ohne Extension: mystery1, mystery2, mystery3
Öffne im Hex-Editor
Lies erste 16 Bytes
Identifiziere Format (Magic Number)
Benenne um und öffne

Tools: hexed.it (online), HxD, Hex Fiend, Bless

Aufgabe bis nächste Woche

Finde eine Datei auf deinem Computer

Öffne im Hex-Editor
Screenshot der ersten 16 Bytes
Identifiziere Magic Number
Poste im Forum: Format + kurze Beschreibung

Bonus: Finde Datei ohne Magic Number in Standard-Listen

Woche 2

Kompression I: Die MP3-Revolution

Das Problem (1990)

1 Minute CD-Audio:

Sample Rate: 44.100 Hz
Bit Depth: 16 Bit
Stereo: 2 Kanäle

Rechnung: 44.100 × 16 × 2 = 1.411.200 Bits/Sekunde ≈ 10,6 MB/Minute ≈ 635 MB für 60-Min-Album

1990: Festplatten hatten 100-500 MB!

Zwei Philosophien

Lossless (Verlustfrei):

Original exakt wiederherstellbar
ZIP, PNG, FLAC
30-50% Ersparnis

Lossy (Verlustbehaftet):

Daten irreversibel verändert
JPEG, MP3, H.264
90%+ Ersparnis

Lossless: Run-Length Encoding

Original:

AAAAABBBCCCCCCCC

Komprimiert:

5A 3B 8C

Ersparnis: 16 → 6 Zeichen (62% Reduktion)

Lossy: Der Trick

Kernidee: Wirf weg, was der Mensch eh nicht wahrnimmt

JPEG: Schwächen des Auges

Helligkeit besser als Farbe wahrgenommen
Große Flächen besser als feine Details

MP3: Schwächen des Ohrs

Mittlere Frequenzen besser als hohe/tiefe
Laute Töne "maskieren" leise Töne

→ Psychoakustik / Psychovisuell

Die Geburt der MP3

1982: Universität Erlangen-Nürnberg Karlheinz Brandenburg, Diplom-Ingenieur

1987: Fraunhofer IIS entwickelt MPEG-1 Audio Layer III

1988: Patentanmeldung

1992: Erste Software-Implementierung

1995: .mp3 Dateiendung offiziell

"Tom's Diner"

Warum dieser Song?

A cappella (keine Instrumente)
Suzanne Vegas Stimme ist "schwierig"
Klare, hohe Frequenzen → Stresstest

"If I could code Suzanne Vega's voice well, I could code anything." — Karlheinz Brandenburg

Wie funktioniert MP3?

1. Frequenz-Analyse (FFT) Audio → Frequenzspektrum

2. Psychoakustisches Modell Welche Töne hört Mensch nicht?

3. Quantisierung Unwichtige Frequenzen reduzieren

4. Huffman-Coding Lossless-Kompression der Restdaten

Bitrate: Der Qualitäts-Knopf

Bitrate	Qualität	Kompression
128 kbps	Hörbar schlechter	~11x
192 kbps	Akzeptabel	~7x
256 kbps	Gut	~5,5x
320 kbps	"CD-Qualität"	~4,4x

Original CD: 1.411 kbps (unkomprimiert)

Der Patentkrieg

1990er: Fraunhofer + Thomson halten MP3-Patente

Lizenzgebühren:

$0,75 pro Decoder
$2,50 pro Encoder

Problem: Napster (1999) → unkontrollierte Verbreitung

2017: Patente laufen aus → MP3 ist frei

Napster & Musikindustrie

1999: Napster startet 2001: 80 Millionen User

Musikindustrie:

CDs kosten $15-20
MP3s gratis (illegal, aber egal)
Einzelne Songs statt Alben

2001: Napster verklagt, geschlossen

Aber: Pandora's Box offen → LimeWire, Kazaa, BitTorrent, später Spotify

Kulturelle Revolution

MP3 veränderte:

✓ Musik wurde portabel (Walkman → iPod) ✓ Alben wurden irrelevant (Playlists) ✓ Musikkonsum explodierte (kostenlos/billig) ✓ Künstler verloren Kontrolle

Aber auch: ❌ Künstler verdienen weniger pro Stream ❌ Audio-Qualität sank (Loudness War) ❌ Physische Medien starben

Hands-On: MP3 sezieren

Aufgabe (30 Min):

Lade Lied runter (eigenes oder CC)
Konvertiere in verschiedene Bitraten:
- 320 kbps, 128 kbps, 64 kbps
Tool: Audacity (kostenlos)
Höre Unterschiede (Kopfhörer!)
Vergleiche Dateigrößen

Optional: Spektrogramm-Ansicht

Aufgabe bis nächste Woche

Nimm ein Lied (eigenes oder CC)

Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
Notiere: Dateigrößen, Höreindrücke
Poste im Forum: Screenshot + Reflexion

Bonus: Niedrigste Bitrate finden, bei der du keinen Unterschied hörst

Woche 3

Kompression II: Bilder & JPEG

Was ist ein Bild?

Digital = Pixelraster

Beispiel: 1920×1080 (Full HD) = 2.073.600 Pixel

Jedes Pixel = 3 Bytes (RGB) 2.073.600 × 3 = 6,2 MB

Für EIN Foto!

Lossless: PNG

PNG = Portable Network Graphics (1996)

Funktionsweise:

Vorhersage (Pixel ähneln Nachbarn)
Differenz-Encoding
DEFLATE-Algorithmus (wie ZIP)

Kompression: 20-50% Ersparnis

Gut für: Screenshots, Logos, Text Schlecht für: Fotos

Lossy: JPEG

JPEG = Joint Photographic Experts Group (1992)

Eigenschaften:

Lossy Kompression
90%+ Platzersparnis möglich
Artefakte bei hoher Kompression

6 MB → 500 KB (typisch)

Wie funktioniert JPEG? (1/2)

Schritt 1: RGB → YCbCr

Y = Helligkeit (Luminanz)
Cb/Cr = Farbe (Chrominanz)

Warum? Menschen sehen Helligkeit besser als Farbe

Schritt 2: Chroma Subsampling Farbauflösung reduzieren (4:2:0) → 50% Datenmenge weg, kaum sichtbar

Wie funktioniert JPEG? (2/2)

Schritt 3: DCT (Discrete Cosine Transform) Bild in 8×8-Blöcke → Frequenzspektrum

Schritt 4: Quantisierung Hohe Frequenzen (Details) stark reduzieren → Hier passiert Datenverlust!

Schritt 5: Huffman-Coding Lossless-Kompression der Restdaten

JPEG Quality

Quality	Dateigröße	Artefakte
100	≈2-3 MB	Kaum
85-90	≈200-400 KB	Minimal
50	≈100 KB	Sichtbar

Sweet Spot: 85-90 10x Kompression, für Menschen kaum unterscheidbar

Die GIF-Geschichte

GIF = Graphics Interchange Format (1987) CompuServe (US-Online-Dienst)

Features:

256 Farben max (8-bit Palette)
Lossless (für Palette)
Animationen!

1994 Twist: Unisys hält Patent auf LZW-Kompression → Fordert Lizenzgebühren

→ "Burn All GIFs!" Kampagne

PNG vs. GIF

GIF: ✓ Animationen ✓ Breite Unterstützung ❌ Nur 256 Farben ❌ Patent-Probleme (bis 2003)

PNG: ✓ Millionen Farben ✓ Alpha-Transparenz ✓ Patent-frei ❌ Keine Animationen (bis APNG, 2004)

Ergebnis: PNG für Grafiken, GIF für Memes!

WebP & AVIF

WebP (Google, 2010):

Lossy UND Lossless
Animationen
25-35% kleiner als JPEG

AVIF (2019):

Basiert auf AV1-Video-Codec
50% kleiner als JPEG
HDR-Unterstützung
Patent-frei

Problem: Browser-Support dauert Jahre

Warum Instagram eure Fotos "ruiniert"

Upload-Pipeline:

Dein Foto: 12 MP, 8 MB
Instagram skaliert: max. 1080px
Re-Kompression: JPEG Quality ~75
Endgröße: 200-400 KB

Warum?

Speicherkosten (Milliarden Fotos!)
Ladezeiten (Mobile)
Bandbreite (günstiger)

Hands-On: Kompression vergleichen

Aufgabe (40 Min):

Hochauflösendes Foto (eigenes oder CC)
Exportiere:
- PNG
- JPEG Q100, Q85, Q50
- WebP (optional)
Tool: Squoosh.app (Google-Tool)
Vergleiche: Dateigrößen, sichtbare Unterschiede
Wo werden Artefakte sichtbar?

Aufgabe bis nächste Woche

Nimm ein Foto (eigenes oder CC)

Exportiere: PNG, JPEG Q90, JPEG Q50
Vergleiche Größen & Qualität
Poste im Forum: Screenshot + Reflexion

Fragen:

Welche Quality ist für dich "akzeptabel"?
Wo siehst du zuerst Artefakte?

Bonus: Teste WebP oder AVIF

Woche 4

Video-Kompression & Codecs

Das Problem: Video ist RIESIG

1 Minute 4K-Video (3840×2160):

30 fps (Bilder/Sekunde)
Jedes Bild: 24,8 MB (unkomprimiert)

Rechnung: 30 × 24,8 MB = 744 MB/Sekunde × 60 Sekunden = 44,6 GB/Minute

2-Stunden-Film: 5,3 TB!

Container vs. Codec

Container = Die Box Verpackt Video, Audio, Untertitel, Metadaten

Beispiele: MP4, MKV, AVI, MOV

Codec = Kompressionsalgorithmus Entscheidet, WIE Daten komprimiert werden

Video-Codecs: H.264, H.265, VP9, AV1 Audio-Codecs: AAC, MP3, Opus

Video-Kompression: Drei Prinzipien

1. Spatial Compression (Intra-Frame) Jedes Bild einzeln (wie JPEG) → I-Frames

2. Temporal Compression (Inter-Frame) Nur Änderungen zwischen Bildern → P-Frames, B-Frames

3. Motion Compensation "Ball bewegt sich von A nach B"

I-Frames, P-Frames, B-Frames

I-Frame (Intra): Vollständiges Bild (wie JPEG) Groß, aber unabhängig

P-Frame (Predicted): Referenziert vorherige Frames Viel kleiner

B-Frame (Bi-directional): Referenziert vorherige UND zukünftige Frames Am effizientesten

GOP: I - B - B - P - B - B - P - B - B - I

H.264: Der König

H.264 / AVC (2003)

Warum dominant? ✓ Exzellente Kompression (100:1 möglich) ✓ Hardware-Support (jedes Gerät seit ~2010) ✓ YouTube, Netflix, Blu-ray – alles H.264

Features:

Variable Block-Größen (16×16 bis 4×4)
Deblocking-Filter
CABAC-Coding

Das Patent-Problem

H.264 ist NICHT frei!

MPEG-LA (Patent Pool):

2.000+ Patente von ~30 Unternehmen
Apple, Microsoft, Sony, Panasonic...

Lizenzgebühren:

Hardware-Decoder: $0,20/Einheit
Content-Distribution: Kostenlos für "Internet Broadcast"

Problem: Open-Source-Projekte in Grauzone

H.265 / HEVC

H.265 (2013): 50% bessere Kompression als H.264

ABER: Patent-Desaster

Drei (!) konkurrierende Patent-Pools:

MPEG-LA
HEVC Advance
Velos Media

→ Viele bleiben bei H.264 oder suchen Alternativen

VP9: Googles Antwort

VP9 (2013): Entwickelt von Google (On2-Akquisition)

Eigenschaften: ✓ Ähnlich H.265-Kompression ✓ KOSTENLOS, patent-frei (laut Google) ✓ YouTube nutzt VP9 für 4K

Nachteile: ❌ Hardware-Support langsam ❌ Höherer CPU-Aufwand ❌ Nicht universell wie H.264

AV1: Die Open-Source-Revolution

AV1 (2018): Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...

Ziel: Patent-freier, moderner Codec

Features: ✓ 30% besser als H.265 ✓ Royalty-free, Open Source ✓ 8K, HDR, hohe Frame-Rates

Stand 2025: YouTube, Netflix nutzen AV1 für 4K/8K

Adaptive Bitrate Streaming

Problem: Internet-Geschwindigkeit variiert

Lösung: Mehrere Qualitäten parallel

MPEG-DASH / HLS:

4K (20 Mbps)
1080p (5 Mbps)
720p (2,5 Mbps)
480p (1 Mbps)
240p (0,5 Mbps)

Segmente: 2-10 Sekunden Player wählt dynamisch

Container im Detail

MP4:

Standard für Web, Mobile
H.264, H.265, AV1
DRM-fähig

MKV (Matroska):

Open Source, extrem flexibel
Beliebig viele Audio-/Untertitel-Spuren
Fast jeden Codec

WebM:

Google, Web-optimiert
Nur VP9/AV1 + Opus/Vorbis

Hands-On: Video analysieren

Aufgabe (40 Min):

Tool: FFmpeg (CLI) oder HandBrake (GUI)

Download: CC-Video (Big Buck Bunny, ~1 Min)
Analysiere: ffmpeg -i video.mp4 oder MediaInfo
Notiere: Container, Codec, Bitrate, Auflösung
Konvertiere:
- H.264, 1080p, 5 Mbps
- H.265, 1080p, 2,5 Mbps
Vergleiche: Größen, Encoding-Zeit, Qualität

Aufgabe bis nächste Woche

Nimm kurzes Video (eigenes oder CC, max. 1 Min)

Analysiere: Container, Codecs, Bitrate
Konvertiere: H.264 + H.265 (gleiche Qualität)
Poste im Forum:
- Dateigrößen
- Encoding-Zeiten
- Visueller Unterschied?

Bonus: AV1-Encoding (Warnung: SEHR langsam!)

Woche 5

Speichermedien, Dateisysteme & Backup

Rückblick: HDD vs. SSD

HDD:

Mechanisch, magnetisch
Langsam (~150 MB/s)
Günstig (~20€/TB)
Empfindlich (Stöße!)

SSD:

Elektronisch, Flash
Schnell (~500-7.000 MB/s)
Teuer (~80-150€/TB)
Write-Zyklen begrenzt

Was fehlt? Dateisysteme!

Dateisystem = Bibliothekskatalog für Festplatte

Aufgaben:

Dateien speichern & finden
Metadaten verwalten
Speicherplatz effizient nutzen
Fehler erkennen & beheben

Partitionen & Volumes

Partition: Zusammenhängender Bereich auf Festplatte

Volume: Logische Einheit mit Dateisystem

Beispiel: 1 TB HDD → 2 Partitionen

500 GB Windows (NTFS)
500 GB Daten (exFAT)

Formatierung

Schnellformatierung:

Löscht nur Metadaten
Daten physisch noch da
→ Datenrettung möglich!

Vollständige Formatierung:

Überschreibt mit Nullen
Dauert länger, aber sicherer

FAT (File Allocation Table)

Geschichte: 1977, Microsoft

Versionen:

FAT16: Max. 2 GB
FAT32: Max. 4 GB Dateien, 2 TB Partitionen
exFAT: Keine 4 GB-Grenze

Vorteil: Universelle Kompatibilität

Nachteil: Keine Rechte, kein Journaling

NTFS

NTFS = New Technology File System (1993)

Features: ✓ Dateien >4 GB (bis 16 EB) ✓ Zugriffsrechte (ACLs) ✓ Journaling (Crash-Schutz) ✓ Kompression & Verschlüsselung ✓ Shadow Copies

Nachteil: Proprietär (nur Windows nativ)

APFS

Apple File System (2017)

Features: ✓ Copy-on-Write (Speicherersparnis!) ✓ Snapshots (Time Machine) ✓ Native Verschlüsselung ✓ SSD-optimiert

Nachteil: Nur Apple-Geräte

ext4

Fourth Extended File System (2008) Linux-Standard

Features: ✓ Journaling ✓ Extents (schneller) ✓ Max. 16 TB Dateien, 1 EB Partitionen ✓ Online-Defragmentierung

Nachteil: Windows/macOS können nicht nativ lesen

Dateisysteme: Vergleich

FS	OS	Max. Datei	Features
FAT32	Alle	4 GB	Kompatibilität
exFAT	Alle	16 EB	Flash-optimiert
NTFS	Win	16 EB	Journaling, ACLs
APFS	macOS	8 EB	Snapshots, CoW
ext4	Linux	16 TB	Journaling

Backup: Warum?

Realität:

Festplatten sterben ohne Vorwarnung
Ransomware verschlüsselt Daten
Versehentliches Löschen
Diebstahl, Brand, Wasserschaden

Faustregel: 3-2-1 Mindestens 3 Kopien, auf mindestens 2 unterschiedlichen Speichermedien und mindestens 1 an einem anderen Ort

Backup-Arten

Vollständig (Full): Kompletter Datenbestand Langsam, aber einfach

Inkrementell: Nur Änderungen seit letztem Backup Schnell, aber Wiederherstellung komplex

Differenziell: Änderungen seit letztem Voll-Backup Mittelweg

3-2-1-Regel

3 Kopien (Original + 2 Backups)

2 verschiedene Medientypen (SSD + HDD)

1 Offsite-Backup (Cloud, externes Lager)

Beispiel: Laptop + externe Festplatte + Cloud

Backup-Software

macOS: Time Machine Windows: Veeam Agent (kostenlos) Linux: rsync, Borg, Restic Plattformübergreifend: Duplicati, Syncthing Cloud: Backblaze, Nextcloud

Langzeitarchivierung: Das Problem

Digitale Daten altern:

Bit Rot (Degradation)
Format-Obsoleszenz (WordPerfect .wpd)
Hardware-Obsoleszenz (Diskettenlaufwerke)

Lösung: Migration + offene Standards

Magnetbänder (LTO)

Linear Tape-Open:

LTO-9 (2021): 18 TB nativ, 45 TB komprimiert
Haltbarkeit: 30 Jahre
Kosten: ~5€/TB (Laufwerk ~5.000€)
Nutzung: Rechenzentren, Archive

Air-Gap-Sicherheit: Offline-Band kann nicht von Ransomware verschlüsselt werden

M-DISC (Millennial Disc)

Eigenschaften:

DVD/Blu-ray-kompatibel
Anorganische Metallschicht
Haltbarkeit: 1.000 Jahre (Tests)
Einsatz: Familienfotos, Archive

DNA-Storage (Zukunft)

Konzept: Daten in DNA-Sequenzen

Eigenschaften:

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

Beispiele: Microsoft + Twist Bioscience Netflix "Biohackers"-Episode (2021)

Hands-On: S.M.A.R.T. & Backup

Aufgabe 1 (20 Min): S.M.A.R.T.-Daten auslesen

Windows: CrystalDiskInfo
macOS/Linux: smartctl -a /dev/sda
Notiere: Health, Power-On Hours, Temp

Aufgabe 2 (20 Min): Test-Backup erstellen

rsync (Linux/macOS) oder Robocopy (Windows)
Simuliere Datenverlust → Wiederherstellung

Aufgabe bis nächste Woche

Analysiere dein System:

Welches Dateisystem nutzt deine Hauptpartition?
Hast du ein Backup? Welche Art? Wo?
Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie

Bonus: Richte automatisches Backup ein

Woche 6

Schnittstellen: USB-C-Chaos & HDMI-Kriege

Was ist eine Schnittstelle?

Schnittstelle = Verbindung zwischen Systemen

Hardware-Schnittstellen: Physischer Anschluss (USB, HDMI, Ethernet)

Software-Schnittstellen: API (nächste Woche!)

Heute: Hardware-Fokus

USB: Die Idee

Universal Serial Bus (1996)

Ziel: Ein Kabel für alles

Vorher:

PS/2 (Maus, Tastatur)
Seriell (Modem)
Parallel (Drucker)
SCSI (Festplatten)

USB-Versprechen: ✓ Ein Stecker, Hot-Pluggable, Stromversorgung

USB-Versionen: Chaos

Version	Jahr	Geschwindigkeit	Marketing-Name
USB 1.0	1996	12 Mbps	–
USB 2.0	2000	480 Mbps	Hi-Speed
USB 3.0	2008	5 Gbps	USB 3.2 Gen 1
USB 3.1	2013	10 Gbps	USB 3.2 Gen 2
USB 3.2	2017	20 Gbps	USB 3.2 Gen 2×2
USB 4	2019	40 Gbps	USB4

NIEMAND versteht das mehr!

USB-C: Stecker ≠ Geschwindigkeit

USB-C = Physischer Stecker (2014)

Eigenschaften: ✓ Reversibel (beide Seiten gleich) ✓ 24 Pins (vs. 4 bei USB-A) ✓ Unterstützt: Daten, Strom, Video, Audio

ABER: USB-C sagt NICHTS über Geschwindigkeit!

Ein USB-C-Kabel kann sein:

USB 2.0 (480 Mbps) 😱
USB 3.2 Gen 2 (10 Gbps)
USB 4 (40 Gbps)
Thunderbolt 3/4 (40 Gbps)
Oder nur Power Delivery (Laden, keine Daten!)

USB Power Delivery

USB PD (über USB-C):

Profile: 5V bis 20V
Max. 5A
Bis zu 240W (USB PD 3.1, 2021)

Anwendungen:

Laptop-Ladung (60-100W)
Monitor mit Stromversorgung
Docking-Stations

Problem: Nicht jedes Kabel unterstützt volles PD!

USB-C: Das Wirrwarr

Was ein USB-C-Kabel KÖNNEN KANN:

Daten: USB 2.0 bis USB4 (40 Gbps)

Strom: 5W bis 240W

Video: DisplayPort Alt Mode, HDMI Alt Mode

Audio: USB Audio Class

Problem: Am Kabel steht's oft NICHT drauf!

Thunderbolt: Premium-Schnittstelle

Thunderbolt (Intel + Apple):

Thunderbolt 3/4 (2015/2020): USB-C, 40 Gbps
PCIe über Kabel → externe GPUs!
Daisychaining (bis 6 Geräte)
100W Power Delivery garantiert

Nachteile: ❌ Teuer (Kabel: 30-80€) ❌ Lizenzgebühren (Intel) ❌ Nur High-End-Geräte

HDMI: Der Heimkino-Standard

HDMI (2002): Entwickelt von Sony, Panasonic, Toshiba...

Versionen:

HDMI 1.4 (2009): 4K @ 30 Hz, ARC
HDMI 2.0 (2013): 4K @ 60 Hz, HDR
HDMI 2.1 (2017): 8K @ 60 Hz, 4K @ 120 Hz, VRR

Features: ✓ Audio + Video in einem Kabel ✓ HDCP (Copy Protection) ✓ CEC (Gerätesteuerung)

Nachteile: ❌ Proprietär, Lizenzgebühren ❌ Keine Daisychaining

DisplayPort: Die PC-Alternative

DisplayPort (2006): VESA (Video Electronics Standards Association)

Versionen:

DP 1.4 (2016): 8K @ 60 Hz, HDR
DP 2.0 (2019): 16K @ 60 Hz, 8K @ 120 Hz

Vorteile: ✓ Lizenzfrei (keine Gebühren!) ✓ Daisychaining (Multi-Monitor) ✓ Adaptive Sync (FreeSync, G-Sync) ✓ USB-C Alt Mode

Nachteil: Weniger verbreitet in TVs

HDMI vs. DisplayPort

Feature	HDMI 2.1	DisplayPort 2.0
Max. Auflösung	8K @ 60 Hz	16K @ 60 Hz
Lizenz	Ja (~$10k/Jahr)	Nein
Daisychaining	Nein	Ja
Adaptive Sync	VRR (neu)	Ja (nativ)
USB-C	Alt Mode (selten)	Alt Mode (häufig)
Verbreitung	TVs dominant	PCs/Monitore

HDCP: Copy Protection

HDCP = High-bandwidth Digital Content Protection

Was ist das?

DRM für Video-Signale
Verschlüsselt zwischen Quelle und Display
Verhindert "Man-in-the-Middle"-Aufnahme

Problem:

Alte Monitore: Kein HDCP 2.2 → 4K-Netflix funktioniert nicht!
Capture-Cards oft blockiert
"HDCP-Handshake-Fehler" → Schwarzer Bildschirm

Kritik: Schikaniert ehrliche Nutzer, Piraten umgehen es leicht

Ethernet: Das Netzwerkkabel

Ethernet (1980er):

Versionen:

100BASE-TX (1995): 100 Mbps
1000BASE-T (1999): 1 Gbps (Gigabit)
10GBASE-T (2006): 10 Gbps

Kabel-Kategorien:

Cat5e: bis 1 Gbps (veraltet)
Cat6: bis 10 Gbps (55m)
Cat6a: bis 10 Gbps (100m)

Stecker: RJ45 (8P8C)

Veraltete Schnittstellen

Seriell (RS-232): 1960er, 115,2 kbps, Modems Parallel (LPT): Drucker, 8 Bits gleichzeitig PS/2: Maus + Tastatur (1987-2010er) VGA: Analoges Video (1987-2010er)

Heute: Manchmal noch auf Mainboards (Legacy-Support)

Hands-On: Schnittstellen identifizieren

Aufgabe (30 Min):

Untersuche deinen Laptop/Desktop
Welche Anschlüsse vorhanden?
Für USB-C: Welche Features? (Daten, Video, Laden?)
Teste: Schließe Gerät an verschiedenen Ports an
Dokumentiere: Foto + Beschriftung

Tools: Systeminfo (Win), System Report (Mac), lsusb (Linux)

Aufgabe bis nächste Woche

Analysiere deine Kabel:

Liste alle Kabel (USB, HDMI, etc.)
Identifiziere: Standard, Geschwindigkeit, Features
Ist es beschriftet? Verständlich?
Poste im Forum: Foto + das verwirrendste Kabel

Bonus: Finde USB-C-Kabel, das nur USB 2.0 kann

Woche 7

Distributionswege: CDN, P2P & Streaming

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

Aufgabe bis nächste Woche

Analysiere Streaming-Dienst oder Website:

Wähle: Netflix, YouTube, Spotify, News-Seite
DevTools (Network-Tab):
- Welcher CDN?
- Wie viele Requests an CDN vs. Origin?
- Cache-Headers?
Poste im Forum: Screenshot + Erkenntnisse

Bonus: Linux-ISO via Torrent, poste Peer-Stats

Woche 8

Software-Schnittstellen: APIs & 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

Aufgabe bis nächste Woche

Experimentiere mit öffentlicher API:

Wähle:
- GitHub API (api.github.com)
- OpenWeather (openweathermap.org/api)
- PokéAPI (pokeapi.co)
Mache 3-5 Requests (curl, Postman, oder Code)
Poste im Forum:
- Welche API?
- Interessante Daten?
- Rate-Limiting erlebt? (429 Too Many Requests)

Bonus: Baue kleinen Client (Python, JavaScript, etc.)

Woche 9

Metadaten & 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)

Aufgabe bis nächste Woche

Metadaten-Audit:

Wähle 3 Dateitypen:
- Ein Foto (EXIF)
- Eine MP3 (ID3)
- Ein PDF (XMP)
Analysiere: Welche Metadaten?
Poste im Forum:
- Screenshots (OHNE sensible Infos!)
- Überraschungen?
- Wie viel KB gespart nach Entfernung?

Bonus: Finde alte Datei (>5 Jahre) – was verraten Metadaten über damaliges Setup?

Woche 10

Zukunft & Synthese

Rückblick: 9 Wochen

Woche 1: Bits → Bytes → Bedeutung (Encoding) Woche 2: MP3 & Psychoakustik Woche 3: JPEG & GIF-Kriege Woche 4: H.264 vs. AV1 Woche 5: HDD vs. SSD, Dateisysteme, Backup Woche 6: USB-C-Chaos, HDMI vs. DisplayPort Woche 7: CDN, P2P, Streaming Woche 8: REST, GraphQL, WebSockets Woche 9: EXIF, Vendor Lock-in

Heute: Wohin geht die Reise?

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 (Forum, E-Mail)
Weiterlernen mit Ressourcen

Vielen Dank für eure Aufmerksamkeit!

Fragen & Diskussion

Kontakt: m.czechowski@librete.ch Folien: Online verfügbar unter https://hdm.librete.ch

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/

88 KiB Raw Blame History Unescape Escape

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

Kursübersicht

Woche 1

Von Bits zu Bedeutung

Mysterium

Das Bit

Das Byte

Was kann man mit 256 Zuständen machen?

Farben: RGB-Modell

Das Problem: Sprachen

Unicode: Ein Standard für alle

Beispiel: Bytes zählen

Hexadezimal: Lesbarkeit

Magic Numbers

Hands-On: Mystery Files

Aufgabe bis nächste Woche

Woche 2

Kompression I: Die MP3-Revolution

Das Problem (1990)

Zwei Philosophien

Lossless: Run-Length Encoding

Lossy: Der Trick

Die Geburt der MP3

"Tom's Diner"

Wie funktioniert MP3?

Bitrate: Der Qualitäts-Knopf

Der Patentkrieg

Napster & Musikindustrie

Kulturelle Revolution

Hands-On: MP3 sezieren

Aufgabe bis nächste Woche

Woche 3

Kompression II: Bilder & JPEG

Was ist ein Bild?

Lossless: PNG

Lossy: JPEG

Wie funktioniert JPEG? (1/2)

Wie funktioniert JPEG? (2/2)

JPEG Quality

Die GIF-Geschichte

PNG vs. GIF

WebP & AVIF

Warum Instagram eure Fotos "ruiniert"

Hands-On: Kompression vergleichen

Aufgabe bis nächste Woche

Woche 4

Video-Kompression & Codecs

Das Problem: Video ist RIESIG

Container vs. Codec

Video-Kompression: Drei Prinzipien

I-Frames, P-Frames, B-Frames

H.264: Der König

Das Patent-Problem

H.265 / HEVC

VP9: Googles Antwort

AV1: Die Open-Source-Revolution

Adaptive Bitrate Streaming

Container im Detail

Hands-On: Video analysieren

Aufgabe bis nächste Woche

Woche 5

Speichermedien, Dateisysteme & Backup

Rückblick: HDD vs. SSD

Was fehlt? Dateisysteme!

Partitionen & Volumes

Formatierung

FAT (File Allocation Table)

NTFS

APFS

ext4

Dateisysteme: Vergleich

Backup: Warum?

Backup-Arten

3-2-1-Regel

Backup-Software

Langzeitarchivierung: Das Problem

Magnetbänder (LTO)

M-DISC (Millennial Disc)

DNA-Storage (Zukunft)

88 KiB

Raw Blame History