4210 lines
89 KiB
Markdown
4210 lines
89 KiB
Markdown
---
|
||
marp: true
|
||
theme: gaia
|
||
paginate: true
|
||
backgroundColor: #fff
|
||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
---
|
||
|
||
<style>
|
||
section {
|
||
font-size: 1.7rem;
|
||
}
|
||
h2 {
|
||
color: var(--color-dimmed);
|
||
}
|
||
</style>
|
||
|
||
|
||
|
||
<!-- Startbild: Futuristisches Netzwerk, Datenströme, oder digitale Landschaft -->
|
||
|
||
---
|
||
|
||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||
|
||
Modul "Technik 1" – 1. Semester
|
||
Digital- und Medienwirtschaft
|
||
Hochschule der Medien Stuttgart
|
||
|
||
**Wintersemester 2025/26**
|
||
|
||
---
|
||
|
||
# Über mich
|
||
|
||
**Michael Czechowski**
|
||
|
||
- Softwareentwickler & IT-Berater
|
||
- Schwerpunkte: Web-Technologien, Systemarchitektur, Open Source
|
||
- Hintergrund: Philosophie & Informatik
|
||
- Kontakt: czechowski@hdm-stuttgart.de
|
||
|
||
<!--
|
||
Kurze Vorstellung
|
||
Praxisbezug betonen
|
||
Fragen jederzeit willkommen
|
||
-->
|
||
|
||
---
|
||
|
||
# Termine
|
||
|
||
| Datum | Zeit | Thema |
|
||
|-------|------|-------|
|
||
| 19.12.2025 | 14:15 – 17:30 | Grundlagen, Text & Audio |
|
||
| 09.01.2026 | 14:15 – 17:30 | Bild- & Videoformate |
|
||
| 23.01.2026 | 14:15 – 17:30 | Speichermedien & Schnittstellen |
|
||
| 30.01.2026 | 14:15 – 17:30 | Distribution, APIs & Zukunft |
|
||
| TBA | 14:15 – 17:30 | Vertiefung (wird bekannt gegeben) |
|
||
|
||
**Ort:** HdM Stuttgart, Nobelstraße 10
|
||
|
||
---
|
||
|
||
# Kurze Umfrage
|
||
|
||
**Bitte Hand heben:**
|
||
|
||
1. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet?
|
||
2. Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
|
||
3. Wer hat schon mal mit APIs gearbeitet?
|
||
4. Wer weiß, was UTF-8 bedeutet?
|
||
5. Wer hat schon mal ein Video komprimiert/konvertiert?
|
||
|
||
<!--
|
||
Niveau der Gruppe einschätzen
|
||
Keine falschen Antworten
|
||
Zeigt, wo wir starten
|
||
-->
|
||
|
||
---
|
||
|
||
# Kursübersicht
|
||
|
||
**Ziel:** Verstehen, wie digitale Medien technisch funktionieren – von Bits bis zu globalen Distributionsnetzwerken
|
||
|
||
**5 Termine:**
|
||
- **19.12.** Bits, Bytes, Zeichenkodierung & Audio-Kompression
|
||
- **09.01.** Bild- & Video-Kompression
|
||
- **23.01.** Speichermedien & Hardware-Schnittstellen
|
||
- **30.01.** Distribution, APIs, Metadaten & Zukunft
|
||
- **TBA** Vertiefung & offene Fragen
|
||
|
||
<!--
|
||
Medienwissenschaftler:innen, nicht Informatiker:innen
|
||
Fokus: Warum funktionieren Dinge so? Welche Konflikte stecken dahinter?
|
||
Hands-On jede Woche (30-40 Min)
|
||
Narrative statt Faktenlisten
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 1 – 19.12.2025
|
||
## Grundlagen, Text & Audio
|
||
|
||
---
|
||
|
||
|
||
|
||
# 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?**
|
||
|
||
<!--
|
||
Hex-Dump ohne Erklärung auf Bildschirm werfen
|
||
Fragen in den Raum: "Was seht ihr?"
|
||
"Ist das Text? Ein Bild? Code?"
|
||
Überleitung: "Alles digital ist nur Zahlen. Heute lernen wir, sie zu lesen."
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Bit
|
||
|
||
**Kleinste Informationseinheit**
|
||
|
||
- **0 oder 1**
|
||
- AN oder AUS
|
||
- Strom fließt oder nicht
|
||
|
||
|
||
|
||
<!--
|
||
Bit = Binary Digit
|
||
Demonstration: Glühbirne AN/AUS = 1 Bit
|
||
Alles Digitale basiert darauf
|
||
Transistoren in CPUs: Milliarden Bits schalten Millionen Mal pro Sekunde
|
||
-->
|
||
|
||
---
|
||
|
||
# Das Byte
|
||
|
||
**8 Bits = 1 Byte**
|
||
|
||
```
|
||
0 1 0 0 1 1 0 1
|
||
```
|
||
|
||
**Wie viele Kombinationen?**
|
||
2⁸ = **256 Möglichkeiten** (0-255)
|
||
|
||
<!--
|
||
Rechnung gemeinsam: 2×2×2×2×2×2×2×2 = 256
|
||
Jedes Bit kann 0 oder 1 sein
|
||
256 verschiedene Werte mit 8 Bits darstellbar
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
|
||
|
||
<!--
|
||
1 Byte ist extrem limitiert
|
||
Für Farbbild: 3 Bytes pro Pixel (RGB)
|
||
R=0-255, G=0-255, B=0-255 → 256³ = 16,7 Millionen Farben
|
||
-->
|
||
|
||
---
|
||
|
||
# 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ß
|
||
|
||
|
||
|
||
<!--
|
||
RGB = Additive Farbmischung (Bildschirme)
|
||
CMYK = Subtraktive Farbmischung (Druck)
|
||
Hex-Notation: FF = 255 in Dezimal
|
||
CSS-Farben nutzen Hex: #FF0000 = Rot
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!**
|
||
|
||
<!--
|
||
Problem der Zeichenkodierung
|
||
ASCII (1963): 7 Bit = 128 Zeichen (nur Englisch)
|
||
ISO-8859-1 (Latin-1): 8 Bit = 256 Zeichen (Westeuropa)
|
||
Chaos: Verschiedene Standards für verschiedene Sprachen
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
ASCII-Tabelle (1963)
|
||
7 Bit = 128 Zeichen
|
||
Erste 32: Steuerzeichen (nicht druckbar)
|
||
Zeichen 32-126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
|
||
Keine Umlaute, kein ñ, kein é
|
||
"American Standard" → Rest der Welt ausgeschlossen
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Unicode Consortium: Non-Profit seit 1991
|
||
Aktuell: Unicode 16.0 (2024)
|
||
UTF-8 = Unicode Transformation Format, 8-bit
|
||
ASCII-kompatibel: "A" = 1 Byte (rückwärtskompatibel)
|
||
Umlaute: "ä" = 2 Bytes, Chinesisch: 3 Bytes, Emoji: 4 Bytes
|
||
-->
|
||
|
||
---
|
||
|
||
# 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**
|
||
|
||
<!--
|
||
Buchstaben = 1 Byte (ASCII/UTF-8-kompatibel)
|
||
Emoji = 4 Bytes (Unicode-Bereich U+1F4A9)
|
||
Haufen-Emoji: "Pile of Poo" (offizieller Name!)
|
||
UTF-8-Kodierung: Variable Länge spart Speicher bei ASCII
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
|
||
|
||
<!--
|
||
Hex = Shortcut für Menschen, nicht für Computer
|
||
Computer denken binär, wir lesen hex
|
||
1 Byte = 2 Hex-Ziffern (00-FF)
|
||
Hex-Editor: Standard-Tool für Dateianalyse
|
||
-->
|
||
|
||
---
|
||
|
||
# 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` |
|
||
|
||
<!--
|
||
Magic Number = Signature am Dateianfang
|
||
Computer schauen in erste Bytes (nicht auf .jpg/.png)
|
||
"PK" = Phil Katz (Erfinder von PKZip)
|
||
Dateiendungen können lügen, Magic Numbers nicht
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Hex-Editor-Screenshot mit PNG-Datei
|
||
Erste Bytes: 89 50 4E 47 = PNG-Signatur
|
||
IHDR = Image Header (Breite, Höhe, Farbtiefe)
|
||
Zeigen, wie man Magic Number liest
|
||
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Mystery Files
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Drei Dateien ohne Extension: `mystery1`, `mystery2`, `mystery3`
|
||
2. Öffne im Hex-Editor
|
||
3. Lies erste 16 Bytes
|
||
4. Identifiziere Format (Magic Number)
|
||
5. Benenne um und öffne
|
||
|
||
**Tools:** hexed.it (online), HxD, Hex Fiend, Bless
|
||
|
||
<!--
|
||
Praktische Phase: Studierende arbeiten selbst
|
||
Dateien: PNG, JPEG, TXT (vorbereitet)
|
||
Gruppenarbeit: 3-4 Personen
|
||
Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Finde eine Datei auf deinem Computer**
|
||
|
||
1. Öffne im Hex-Editor
|
||
2. Screenshot der ersten 16 Bytes
|
||
3. Identifiziere Magic Number
|
||
4. Poste im Forum: Format + kurze Beschreibung
|
||
|
||
**Bonus:** Finde Datei ohne Magic Number in Standard-Listen
|
||
|
||
<!--
|
||
Selbstständiges Arbeiten
|
||
Forum: Peer-Learning, gegenseitige Hilfe
|
||
Bonus: Spornt Neugierige an
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Die MP3-Revolution
|
||
## Psychoakustik & Audio-Kompression
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Kassette neben iPod
|
||
Visueller Kontrast: Analog vs. Digital
|
||
1980er vs. 2000er
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!
|
||
|
||
<!--
|
||
CD-Qualität = Standard seit 1982
|
||
Ein Album = ganze Festplatte
|
||
Download bei 56k-Modem = Tage!
|
||
Streaming? Unmöglich.
|
||
-->
|
||
|
||
---
|
||
|
||
# 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: Findet Muster, beschreibt effizienter
|
||
Lossy: Wirft "Unwichtiges" weg (Psychoakustik/Psychovisuell)
|
||
Trade-off: Größe vs. Qualität
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossless: Run-Length Encoding
|
||
|
||
**Original:**
|
||
```
|
||
AAAAABBBCCCCCCCC
|
||
```
|
||
|
||
**Komprimiert:**
|
||
```
|
||
5A 3B 8C
|
||
```
|
||
|
||
**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
|
||
|
||
<!--
|
||
RLE = Simplest Compression Algorithm
|
||
Gut für repetitive Daten (Fax, simple Grafiken)
|
||
Schlecht für chaotische Daten (Fotos, Audio)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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**
|
||
|
||
<!--
|
||
Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
|
||
Visuelle Masking: Starker Kontrast überstrahlt Details
|
||
Kompression = Modell der menschlichen Wahrnehmung
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Foto: Karlheinz Brandenburg
|
||
Fraunhofer IIS Erlangen
|
||
"Vater der MP3"
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
MPEG = Moving Picture Experts Group
|
||
Layer III = Dritte Verfeinerungsstufe
|
||
Forschung dauerte 10 Jahre
|
||
Patent lief 2017 aus
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Suzanne Vega – "Tom's Diner" (1987)
|
||
Der erste Song, der als MP3 kodiert wurde
|
||
Karlheinz Brandenburg hörte ihn tausende Male
|
||
-->
|
||
|
||
---
|
||
|
||
# "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
|
||
|
||
<!--
|
||
Brandenburg hörte Song 10.000+ Mal
|
||
A cappella = einfacher zu analysieren (nur Stimme)
|
||
Hohe Frequenzen = Herausforderung für Kompression
|
||
Perfektionismus: Jeder Hörtest musste bestehen
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
FFT = Fast Fourier Transform
|
||
Psychoakustik = Modell des menschlichen Gehörs
|
||
Quantisierung = Wo passiert Datenverlust
|
||
Huffman = Finaler Effizienz-Boost (lossless)
|
||
MP3 ist KEIN einfaches "Kleiner machen" – es simuliert dein Gehirn
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
kbps = Kilobit pro Sekunde
|
||
128 kbps = Standard in 2000ern (Napster-Ära)
|
||
320 kbps = Maximum für MP3
|
||
Höhere Bitrate = mehr Daten = bessere Qualität
|
||
Aber: Diminishing Returns ab 256 kbps
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Spektrogramm-Vergleich
|
||
Original vs. 320 kbps vs. 128 kbps
|
||
Hohe Frequenzen verschwinden bei niedriger Bitrate
|
||
Visuell: Dunkle Bereiche = fehlende Frequenzen
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Fraunhofer verklagte Winamp, andere Tools
|
||
Millionen nutzten unlizenzierte Software
|
||
Das Pferd war aus dem Stall
|
||
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Napster-Screenshot (1999)
|
||
P2P-Filesharing für MP3s
|
||
Shawn Fanning, 19 Jahre alt
|
||
80 Millionen User in 2 Jahren
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
RIAA (Recording Industry Association of America) verklagte Napster
|
||
Urteil: Napster muss schließen (2001)
|
||
Aber: Technologie nicht mehr aufzuhalten
|
||
iPod (2001): "1.000 songs in your pocket"
|
||
iTunes Store (2003): Legale Alternative
|
||
Spotify (2008): Streaming-Ära beginnt
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Walkman (1979): Kassetten
|
||
Discman (1984): CDs
|
||
iPod (2001): MP3s
|
||
Spotify (2008): Streaming
|
||
Künstler-Einkommen: Album-Verkauf → Streaming-Pennies
|
||
Loudness War: Alles wird lauter gemastert (Dynamik verloren)
|
||
Vinyl-Revival: 2020er Gegenbewegung
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: MP3 sezieren
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Lade Lied runter (eigenes oder CC)
|
||
2. Konvertiere in verschiedene Bitraten:
|
||
- 320 kbps, 128 kbps, 64 kbps
|
||
3. Tool: Audacity (kostenlos)
|
||
4. Höre Unterschiede (Kopfhörer!)
|
||
5. Vergleiche Dateigrößen
|
||
|
||
**Optional:** Spektrogramm-Ansicht
|
||
|
||
<!--
|
||
Audacity: FOSS Audio-Editor
|
||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||
Spektrogramm: Analysieren → Spektrogramm
|
||
Hohe Frequenzen verschwinden bei niedriger Bitrate
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Nimm ein Lied (eigenes oder CC)**
|
||
|
||
1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
|
||
2. Notiere: Dateigrößen, Höreindrücke
|
||
3. Poste im Forum: Screenshot + Reflexion
|
||
|
||
**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
|
||
|
||
<!--
|
||
WAV = Unkomprimiert (Referenz)
|
||
Goldenes Ohr: Manche hören Unterschied, manche nicht
|
||
Psychoakustik in Aktion: Subjektive Wahrnehmung
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 2 – 09.01.2026
|
||
## Bild-, Audio- & Videoformate
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Links: Hochauflösend
|
||
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
|
||
Instagram-Effekt
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!**
|
||
|
||
<!--
|
||
Zoom auf Pixel-Ebene zeigen
|
||
Jedes Pixel = RGB-Tripel (3 Bytes)
|
||
6 MB × 10.000 Fotos = 62 GB
|
||
Smartphone-Speicher wäre schnell voll ohne Kompression
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
|
||
Lossless: Originaldaten bleiben erhalten
|
||
Transparenz: Alpha-Kanal (sanfte Übergänge)
|
||
DEFLATE: Gleicher Algorithmus wie ZIP
|
||
-->
|
||
|
||
---
|
||
|
||
# Lossy: JPEG
|
||
|
||
**JPEG = Joint Photographic Experts Group (1992)**
|
||
|
||
**Eigenschaften:**
|
||
- Lossy Kompression
|
||
- 90%+ Platzersparnis möglich
|
||
- Artefakte bei hoher Kompression
|
||
|
||
**6 MB → 500 KB** (typisch)
|
||
|
||
<!--
|
||
JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
|
||
JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
|
||
Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Beispiel: Stark komprimiertes JPEG
|
||
Blocking (8×8-Blöcke sichtbar)
|
||
Ringing (Geister um Kanten)
|
||
Color Banding (Verläufe "treppig")
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
YCbCr = Farbraum-Konversion
|
||
Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
|
||
4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
|
||
Auge merkt's kaum, weil Helligkeitssehen dominiert
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
DCT: Ähnlich wie FFT bei Audio
|
||
8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
|
||
Quantisierung: Quality-Schieberegler steuert genau das
|
||
Huffman: Finale Effizienz (wie bei MP3)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Quality 100 = Minimum Compression (nicht lossless!)
|
||
Quality 85-90 = Standard für Web
|
||
Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
|
||
Photoshop "Save for Web": Standard ist 60
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
GIF-Animation (z.B. Meme)
|
||
256 Farben, aber Animationen möglich
|
||
-->
|
||
|
||
---
|
||
|
||
# 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**
|
||
|
||
<!--
|
||
CompuServe: Früher Online-Dienst (1969-2009)
|
||
LZW = Lempel-Ziv-Welch Compression
|
||
Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
|
||
Community-Reaktion: Boykott, Suche nach Alternative
|
||
Ergebnis: PNG wurde entwickelt (1996)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!
|
||
|
||
<!--
|
||
APNG = Animated PNG (Firefox, Safari support)
|
||
WebP (Google, 2010): Animationen + bessere Kompression
|
||
GIF überlebte kulturell (Meme-Format)
|
||
"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
WebP: Von Google entwickelt, deshalb Skepsis
|
||
AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
|
||
Browser-Support 2024: WebP fast überall, AVIF wachsend
|
||
JPEG bleibt dominant (Kompatibilität!)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Vorher/Nachher: Hochauflösend vs. Instagram-Upload
|
||
Sichtbare Qualitätsverluste
|
||
-->
|
||
|
||
---
|
||
|
||
# Warum Instagram eure Fotos "ruiniert"
|
||
|
||
**Upload-Pipeline:**
|
||
1. Dein Foto: 12 MP, 8 MB
|
||
2. Instagram skaliert: max. 1080px
|
||
3. Re-Kompression: JPEG Quality ~75
|
||
4. Endgröße: 200-400 KB
|
||
|
||
**Warum?**
|
||
- Speicherkosten (Milliarden Fotos!)
|
||
- Ladezeiten (Mobile)
|
||
- Bandbreite (günstiger)
|
||
|
||
<!--
|
||
Instagram ist keine Kunstgalerie
|
||
Optimiert für Geschwindigkeit, nicht Qualität
|
||
Facebook macht dasselbe
|
||
Lösung: Portfolio-Websites (eigene Kontrolle)
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Kompression vergleichen
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
1. Hochauflösendes Foto (eigenes oder CC)
|
||
2. Exportiere:
|
||
- PNG
|
||
- JPEG Q100, Q85, Q50
|
||
- WebP (optional)
|
||
3. Tool: **Squoosh.app** (Google-Tool)
|
||
4. Vergleiche: Dateigrößen, sichtbare Unterschiede
|
||
5. Wo werden Artefakte sichtbar?
|
||
|
||
<!--
|
||
Squoosh.app: Browser-basiert, keine Installation
|
||
Side-by-Side-Vergleich mit Zoom
|
||
Verschiedene Codecs testen
|
||
Studis sollen selbst "Sweet Spot" finden
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Nimm ein Foto (eigenes oder CC)**
|
||
|
||
1. Exportiere: PNG, JPEG Q90, JPEG Q50
|
||
2. Vergleiche Größen & Qualität
|
||
3. Poste im Forum: Screenshot + Reflexion
|
||
|
||
**Fragen:**
|
||
- Welche Quality ist für dich "akzeptabel"?
|
||
- Wo siehst du zuerst Artefakte?
|
||
|
||
**Bonus:** Teste WebP oder AVIF
|
||
|
||
<!--
|
||
Selbstständiges Experimentieren
|
||
Subjektive Wahrnehmung (jeder anders)
|
||
Forum: Austausch über Ergebnisse
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Video
|
||
## Kompression & Codecs
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Netflix 4K-Streaming
|
||
Unmöglich ohne moderne 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!**
|
||
|
||
<!--
|
||
4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
|
||
30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
|
||
Ohne Kompression: Unmöglich zu streamen oder speichern
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Container ≠ Codec (häufiges Missverständnis!)
|
||
MP4 ist KEIN Codec, sondern Container
|
||
Schachtel-Analogie: Container = Karton, Codec = Inhalt
|
||
Ein MP4 kann H.264, H.265 oder AV1 enthalten
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Diagramm: Container mit verschiedenen Streams
|
||
Video-Track (H.264)
|
||
Audio-Track (AAC)
|
||
Untertitel-Track (SRT)
|
||
Metadaten (Titel, Künstler, etc.)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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"
|
||
|
||
<!--
|
||
Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
|
||
Temporal: Zwischen Bildern (zeitliche Redundanz)
|
||
Motion Compensation: Intelligente Vorhersage
|
||
→ 90%+ Effizienz durch temporale Kompression
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
GOP = Group of Pictures (typisch 12-15 Frames)
|
||
I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
|
||
P-Frame: "Pixel X bewegt sich 5px rechts"
|
||
B-Frame: Komplex, aber beste Kompression
|
||
Wenn du vorspulst: Sucht nach nächstem I-Frame
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung: I/P/B-Frame-Abhängigkeiten
|
||
Pfeile zeigen Referenzen
|
||
I-Frame = Anker, P/B-Frames hängen dran
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
AVC = Advanced Video Coding
|
||
MPEG-4 Part 10 = H.264 (gleicher Standard)
|
||
Revolutionierte Video-Streaming
|
||
Hardware-Decoder in CPUs/GPUs → Batterie-schonend
|
||
CABAC = Context-Adaptive Binary Arithmetic 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
|
||
|
||
<!--
|
||
MPEG-LA = Licensing Authority
|
||
Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
|
||
Chromium musste extern linken
|
||
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
|
||
"Free to View" Klausel: YouTube etc. kostenlos
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
HEVC = High Efficiency Video Coding
|
||
Technisch überlegen, aber juristisch Albtraum
|
||
Apple nutzt HEVC (iPhone-Videos)
|
||
Netflix zögert wegen Lizenzkosten
|
||
Fragmentierung verzögert Adoption
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
YouTube VP9-Logo
|
||
Google's Patent-freie Alternative
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
On2 Technologies: Gekauft 2010 für $133M
|
||
VP8 → VP9 → AV1 (Evolution)
|
||
YouTube forciert VP9: 4K-Videos nur VP9/AV1
|
||
Hardware-Decoder erst ab ~2016 (langsame Adoption)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
AV1-Logo
|
||
Alliance for Open Media
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
AOM = Alliance for Open Media (2015 gegründet)
|
||
Alle Big-Tech-Player vereint (historisch!)
|
||
"Fuck you" an Patent-Mafia
|
||
Problem: Encoding SEHR langsam (10-100x vs. H.264)
|
||
Hardware-Encoder kommen (ab 2020er-GPUs)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
DASH = Dynamic Adaptive Streaming over HTTP
|
||
HLS = HTTP Live Streaming (Apple)
|
||
Beide ähnlich, aber inkompatibel
|
||
Manifest-Datei: Liste aller Qualitäten
|
||
Player misst Bandbreite, wechselt live
|
||
→ Warum Netflix plötzlich pixelig wird
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung: Qualitätswechsel während Playback
|
||
Bandbreite schwankt → Player reagiert
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
MP4 = MPEG-4 Part 14 (ISO-Standard)
|
||
Matroska = Russisch: Matrjoschka (Puppen ineinander)
|
||
WebM = Subset von Matroska (HTML5-Video)
|
||
MKV vs. MP4: Offenheit vs. Kompatibilität
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Video analysieren
|
||
|
||
**Aufgabe (40 Min):**
|
||
|
||
**Tool:** FFmpeg (CLI) oder HandBrake (GUI)
|
||
|
||
1. Download: CC-Video (Big Buck Bunny, ~1 Min)
|
||
2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo
|
||
3. Notiere: Container, Codec, Bitrate, Auflösung
|
||
4. Konvertiere:
|
||
- H.264, 1080p, 5 Mbps
|
||
- H.265, 1080p, 2,5 Mbps
|
||
5. Vergleiche: Größen, Encoding-Zeit, Qualität
|
||
|
||
<!--
|
||
Big Buck Bunny: Open-Source-Film (Blender Foundation)
|
||
FFmpeg: Swiss Army Knife für Video
|
||
HandBrake: GUI für FFmpeg (einfacher)
|
||
MediaInfo: Detaillierte Datei-Analyse
|
||
Encoding-Zeit: H.265 deutlich langsamer als H.264
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Nimm kurzes Video (eigenes oder CC, max. 1 Min)**
|
||
|
||
1. Analysiere: Container, Codecs, Bitrate
|
||
2. Konvertiere: H.264 + H.265 (gleiche Qualität)
|
||
3. Poste im Forum:
|
||
- Dateigrößen
|
||
- Encoding-Zeiten
|
||
- Visueller Unterschied?
|
||
|
||
**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
|
||
|
||
<!--
|
||
MediaInfo oder ffprobe für Analyse
|
||
HandBrake für Konvertierung (einfacher als CLI)
|
||
Encoding-Zeit: H.265 ~5x langsamer, AV1 ~50x langsamer
|
||
Qualität: Bei gleicher Bitrate H.265 > H.264
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 3 – 23.01.2026
|
||
## Speichermedien & Schnittstellen
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
HDD aufgeschraubt neben SSD-Platine
|
||
Mechanisch vs. Elektronisch
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Wiederholung aus vorheriger Iteration (falls schon behandelt)
|
||
Oder erste Einführung, falls Woche 5 Startpunkt für Speicher
|
||
HDD: Platter, Lesekopf, 5.400-15.000 RPM
|
||
SSD: NAND-Flash (SLC/MLC/TLC/QLC)
|
||
-->
|
||
|
||
---
|
||
|
||
# Was fehlt? Dateisysteme!
|
||
|
||
**Dateisystem = Bibliothekskatalog für Festplatte**
|
||
|
||
**Aufgaben:**
|
||
- Dateien speichern & finden
|
||
- Metadaten verwalten
|
||
- Speicherplatz effizient nutzen
|
||
- Fehler erkennen & beheben
|
||
|
||
<!--
|
||
Ohne Dateisystem: Rohe Bytes, keine Struktur
|
||
Vergleich: Bibliothek ohne Katalog = Chaos
|
||
Jedes OS hat bevorzugtes Dateisystem
|
||
Windows: NTFS, macOS: APFS, Linux: ext4
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Verzeichnisbaum-Visualisierung
|
||
Root → Ordner → Unterordner → Dateien
|
||
Unix: / (Root), Windows: C:\ (Laufwerk)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Partitionstabelle: MBR (alt) vs. GPT (modern)
|
||
GPT = GUID Partition Table (128 Partitionen möglich)
|
||
EFI System Partition (ESP): Bootloader bei UEFI
|
||
LBA = Logical Block Addressing
|
||
-->
|
||
|
||
---
|
||
|
||
# Formatierung
|
||
|
||
**Schnellformatierung:**
|
||
- Löscht nur Metadaten
|
||
- Daten physisch noch da
|
||
- → Datenrettung möglich!
|
||
|
||
**Vollständige Formatierung:**
|
||
- Überschreibt mit Nullen
|
||
- Dauert länger, aber sicherer
|
||
|
||
<!--
|
||
Formatierung ≠ Löschen!
|
||
Schnellformat: "Inhaltsverzeichnis" wird gelöscht
|
||
Recuva, PhotoRec: Datenrettungssoftware
|
||
Sicheres Löschen: DBAN, shred, eraser
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
FAT = Tabelle am Anfang der Partition
|
||
Verkettete Liste von Clustern
|
||
Fragmentierung: Cluster verstreut → langsam
|
||
USB-Sticks heute meist FAT32 (Kompatibilität!)
|
||
exFAT: Microsoft-Patent, seit 2019 in Linux-Kernel
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Windows NT-Ära (1993)
|
||
Master File Table (MFT): Zentrale Datenbank
|
||
Journaling: Transaktionslog verhindert Datenverlust
|
||
ACL = Access Control List
|
||
EFS = Encrypting File System
|
||
Nachfolger: ReFS (Resilient FS, noch nicht Standard)
|
||
-->
|
||
|
||
---
|
||
|
||
# APFS
|
||
|
||
**Apple File System (2017)**
|
||
|
||
**Features:**
|
||
✓ Copy-on-Write (Speicherersparnis!)
|
||
✓ Snapshots (Time Machine)
|
||
✓ Native Verschlüsselung
|
||
✓ SSD-optimiert
|
||
|
||
**Nachteil:** Nur Apple-Geräte
|
||
|
||
<!--
|
||
Ersetzt HFS+ (1998)
|
||
Copy-on-Write: Datei kopieren = nur Pointer
|
||
Clones: Duplikate ohne Speicherplatz-Verdopplung
|
||
Space Sharing: Volumes teilen dynamisch Partition
|
||
FileVault 2 nutzt APFS-Verschlüsselung
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Evolution: ext (1992) → ext2 → ext3 → ext4
|
||
Extents: Zusammenhängende Blöcke als Einheit
|
||
Delayed Allocation: Schreibvorgänge gebündelt
|
||
fsck: File System Check (Reparatur-Tool)
|
||
Alternativen: btrfs (CoW, Snapshots), XFS, ZFS
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
EB = Exabyte = 1.000.000 TB
|
||
Kompatibilität: FAT32/exFAT für USB-Sticks
|
||
Performance: APFS/ext4 für SSDs
|
||
Sicherheit: APFS/NTFS für Verschlüsselung
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Symbolbild: Kaputte Festplatte, verzweifelter User
|
||
Oder: Ransomware-Warnung auf Bildschirm
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Backblaze: 1-2% jährliche HDD-Ausfallrate
|
||
Ransomware 2023: 300%+ Anstieg (FBI)
|
||
Horror-Story: Pixar verlor fast "Toy Story 2" (1998)
|
||
Rettung: Mitarbeiterin hatte Home-Backup
|
||
3-2-1-Regel kommt gleich
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Vollbackup: Jeden Sonntag (500 GB)
|
||
Inkrementell: Mo-Sa Änderungen (10 GB/Tag)
|
||
Differenziell: Mo-Sa Änderungen seit Sonntag (wächst)
|
||
Wiederherstellung: Full = 1 Schritt, Inkr. = 7, Diff. = 2
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
3-2-1 ist MINIMUM, nicht Maximum!
|
||
Medientypen: SSD, HDD, Optical, Cloud, Tape
|
||
Offsite: Schutz vor lokalem Desaster
|
||
Versionierung: Auch alte Versionen aufbewahren
|
||
Automatisierung: Sonst vergisst man's
|
||
-->
|
||
|
||
---
|
||
|
||
# Backup-Software
|
||
|
||
**macOS:** Time Machine
|
||
**Windows:** Veeam Agent (kostenlos)
|
||
**Linux:** rsync, Borg, Restic
|
||
**Plattformübergreifend:** Duplicati, Syncthing
|
||
**Cloud:** Backblaze, Nextcloud
|
||
|
||
<!--
|
||
Time Machine: Stündliche Snapshots, APFS-Snapshots
|
||
Veeam: Enterprise-Level, kostenlose Version für Endnutzer
|
||
rsync: Unix-Tool seit 1996, extrem effizient
|
||
Borg: Deduplizierung + Verschlüsselung
|
||
Syncthing: P2P-Sync, kein zentraler Server
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Visualisierung: Verfallende Daten
|
||
Oder: Alte Disketten, unlesbar
|
||
-->
|
||
|
||
---
|
||
|
||
# Langzeitarchivierung: Das Problem
|
||
|
||
**Digitale Daten altern:**
|
||
- Bit Rot (Degradation)
|
||
- Format-Obsoleszenz (WordPerfect .wpd)
|
||
- Hardware-Obsoleszenz (Diskettenlaufwerke)
|
||
|
||
**Lösung:**
|
||
Migration + offene Standards
|
||
|
||
<!--
|
||
Bit Rot: Daten verschlechtern sich über Zeit
|
||
HDDs: 10-20 Jahre, SSDs: 5-10 Jahre ohne Strom
|
||
Format-Obsoleszenz: WordPerfect dominant 1980-90er, heute tot
|
||
Hardware: Floppy, ZIP-Disks, heute unmöglich
|
||
Migration: Alle 5-10 Jahre auf neue Medien
|
||
Offene Standards: PDF/A, TIFF, TXT überleben
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
LTO-Kassette + Laufwerk
|
||
Magnetband-Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
LTO = Offener Standard seit 1998
|
||
LTO-9: 400 MB/s, 1 Million Durchläufe
|
||
AWS Snowball nutzt intern Tapes
|
||
Problem: Sequenzieller Zugriff (langsam für einzelne Dateien)
|
||
Cold Storage: Daten, die selten gebraucht werden
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
M-DISC Blu-ray
|
||
Metallschicht statt Farbstoff
|
||
-->
|
||
|
||
---
|
||
|
||
# M-DISC (Millennial Disc)
|
||
|
||
**Eigenschaften:**
|
||
- DVD/Blu-ray-kompatibel
|
||
- Anorganische Metallschicht
|
||
- Haltbarkeit: 1.000 Jahre (Tests)
|
||
- Einsatz: Familienfotos, Archive
|
||
|
||
<!--
|
||
Millenniata entwickelt, 2009
|
||
Normale DVDs: Organischer Farbstoff zersetzt sich (10-25 Jahre)
|
||
M-DISC: Daten "eingraviert" (nicht Farbänderung)
|
||
US-Verteidigungsministerium: Tests bestätigt
|
||
Nachteil: Teurer (~5€ vs. 0,50€ normale Blu-ray)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
DNA-Helix mit Binärcode überlagert
|
||
Futuristische Darstellung
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
DNA = A, T, G, C (4 Basen)
|
||
Kodierung: Binär (00=A, 01=T, 10=G, 11=C)
|
||
Harvard (2017): Wikipedia (11 GB) in DNA
|
||
Problem: Synthese & Sequenzierung extrem langsam/teuer
|
||
Anwendung: Langzeitarchivierung (nicht Live-Daten)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
S.M.A.R.T. = Self-Monitoring, Analysis, Reporting Technology
|
||
Reallocated Sector Count: >0 = Warnsignal!
|
||
Current Pending Sector: Kritisch!
|
||
Power-On Hours: >30.000h = alt
|
||
Backup-Test: Ungetestete Backups sind wertlos!
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Analysiere dein System:**
|
||
|
||
1. Welches Dateisystem nutzt deine Hauptpartition?
|
||
2. Hast du ein Backup? Welche Art? Wo?
|
||
3. Poste im Forum: S.M.A.R.T.-Screenshot + Backup-Strategie
|
||
|
||
**Bonus:** Richte automatisches Backup ein
|
||
|
||
<!--
|
||
Selbstreflexion: 60-70% haben KEIN Backup!
|
||
Forum: Peer-Lernen, gegenseitige Motivation
|
||
Bonus: Wer's macht, hat echten Nutzen
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: Schnittstellen
|
||
## USB-C, HDMI & das Kabel-Chaos
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Kabelsalat: USB-A, USB-C, HDMI, DisplayPort, Lightning
|
||
Chaos der Standards
|
||
-->
|
||
|
||
---
|
||
|
||
# Was ist eine Schnittstelle?
|
||
|
||
**Schnittstelle = Verbindung zwischen Systemen**
|
||
|
||
**Hardware-Schnittstellen:**
|
||
Physischer Anschluss (USB, HDMI, Ethernet)
|
||
|
||
**Software-Schnittstellen:**
|
||
API (nächste Woche!)
|
||
|
||
**Heute:** Hardware-Fokus
|
||
|
||
<!--
|
||
Interface = Berührungspunkt zwischen Systemen
|
||
Definiert: Form, Pins, elektrische Signale, Protokoll
|
||
Ohne Standards: Jedes Gerät braucht eigenes Kabel
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
PC-Rückseite 1990er
|
||
PS/2, Seriell, Parallel, SCSI, VGA – Chaos!
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 1.0: 1996, Intel + Microsoft + Compaq
|
||
Vorher: Jedes Gerät eigener Port
|
||
Hot-Pluggable: Ein-/Ausstecken im laufenden Betrieb
|
||
Plug & Play: Automatische Erkennung
|
||
-->
|
||
|
||
---
|
||
|
||
# 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-IF (Implementers Forum) = Marketing-Wahnsinn
|
||
USB 3.0 umbenannt in "USB 3.2 Gen 1" (2019)
|
||
Verwirrung absichtlich? Konspirations-Theorien...
|
||
USB 4 basiert auf Thunderbolt 3 (Intel spendete Spec)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Identisch aussehende USB-C-Kabel
|
||
Aber: Unterschiedliche Specs!
|
||
-->
|
||
|
||
---
|
||
|
||
# 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-C = "Auto" (sagt nichts über PS, Hubraum)
|
||
Kleingedrucktes lesen!
|
||
Billige Kabel oft nur USB 2.0 (Lade-Kabel)
|
||
Teuer ≠ besser (aber oft ja)
|
||
USB-IF Zertifizierung: Logo zeigt Spec an
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!
|
||
|
||
<!--
|
||
Standard USB: 5V, 0,5A = 2,5W
|
||
USB PD: Variable Spannung (Verhandlung zwischen Geräten)
|
||
Günstige Kabel: Oft nur 60W
|
||
Zertifizierte Kabel: 100W+
|
||
Laptop-Netzteil ersetzbar durch USB-C 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!
|
||
|
||
<!--
|
||
Alt Mode: Andere Protokolle über USB-C-Kabel
|
||
DisplayPort Alt Mode: Häufig (Monitore)
|
||
HDMI Alt Mode: Selten
|
||
Trial & Error beim Kabelkauf
|
||
EU-Regulierung: Beschriftung gefordert (aber nicht umgesetzt)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Thunderbolt-Logo (Blitz-Symbol)
|
||
Intel + Apple Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Thunderbolt 1/2: Mini DisplayPort (2011-2013)
|
||
Thunderbolt 3: USB-C-Stecker, aber nicht jeder USB-C ist Thunderbolt!
|
||
PCIe über Kabel: Externe GPU-Gehäuse möglich
|
||
Daisychaining: Mehrere Geräte verketten (wie SCSI früher)
|
||
Zertifizierung: Blitz-Logo = echt Thunderbolt
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
HDMI-Kabel + Stecker
|
||
Heimkino-Standard
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
HDMI = High-Definition Multimedia Interface
|
||
ARC = Audio Return Channel (TV → Soundbar)
|
||
HDCP = High-bandwidth Digital Content Protection (DRM!)
|
||
CEC = Consumer Electronics Control (TV ein → Receiver ein)
|
||
Lizenzgebühren: ~$10.000 Jahresgebühr + $0,15/Gerät
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
DisplayPort-Kabel + Stecker
|
||
PC-Gaming-Standard
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
VESA = Non-Profit-Organisation
|
||
DisplayPort über USB-C: Häufig bei Laptops
|
||
Adaptive Sync: Synchronisiert Monitor-Refresh mit GPU (kein Tearing)
|
||
AMD FreeSync, NVIDIA G-Sync: Basieren auf DP Adaptive Sync
|
||
PC-Gamer bevorzugen DP (höhere Refresh-Rates)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 |
|
||
|
||
<!--
|
||
HDMI = Heimkino/Konsolen
|
||
DisplayPort = PC-Gaming/Workstations
|
||
Beide können das Gleiche (technisch)
|
||
Politik & Marketing entscheiden
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
HDCP-Fehler auf Bildschirm
|
||
"HDCP-Handshake fehlgeschlagen"
|
||
Schwarzer Bildschirm
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Intel entwickelt (2003)
|
||
HDCP 2.2: Für 4K-Content (Netflix, Amazon)
|
||
Handshake: Gerät authentifiziert sich
|
||
HDCP-Stripper: Hardware, die HDCP entfernt (legal gray area)
|
||
Classic DRM-Problem: Nervt Zahlende, nicht Piraten
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Ethernet-Kabel (RJ45)
|
||
Netzwerkkabel
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Ethernet = IEEE 802.3 Standard
|
||
BASE-T = Baseband, Twisted Pair (Kupfer)
|
||
RJ45: Häufigste Bezeichnung (technisch 8P8C)
|
||
Cat = Category (Kabel-Spezifikation)
|
||
PoE = Power over Ethernet (Strom + Daten)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Alte Anschlüsse: VGA, PS/2, Seriell, Parallel
|
||
Nostalgie-Faktor
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
RS-232: Noch in Industrie (Arduino, Sensoren)
|
||
Parallel: Schneller als Seriell (damals), aber durch USB ersetzt
|
||
PS/2: Color-Coded (Lila = Tastatur, Grün = Maus)
|
||
VGA: Manche Beamer haben's noch
|
||
Museumsbesuch: Diese Fossilien erinnern uns, Standards sterben
|
||
-->
|
||
|
||
---
|
||
|
||
# Hands-On: Schnittstellen identifizieren
|
||
|
||
**Aufgabe (30 Min):**
|
||
|
||
1. Untersuche deinen Laptop/Desktop
|
||
2. Welche Anschlüsse vorhanden?
|
||
3. Für USB-C: Welche Features? (Daten, Video, Laden?)
|
||
4. Teste: Schließe Gerät an verschiedenen Ports an
|
||
5. Dokumentiere: Foto + Beschriftung
|
||
|
||
**Tools:** Systeminfo (Win), System Report (Mac), lsusb (Linux)
|
||
|
||
<!--
|
||
Praktische Exploration
|
||
USB-C-Ports: Oft unterschiedlich (Thunderbolt vs. nur USB)
|
||
Manche Laptops: USB-C nur Laden, keine Daten!
|
||
Dokumentation: Verstehen, was man hat
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Analysiere deine Kabel:**
|
||
|
||
1. Liste alle Kabel (USB, HDMI, etc.)
|
||
2. Identifiziere: Standard, Geschwindigkeit, Features
|
||
3. Ist es beschriftet? Verständlich?
|
||
4. Poste im Forum: Foto + das verwirrendste Kabel
|
||
|
||
**Bonus:** Finde USB-C-Kabel, das nur USB 2.0 kann
|
||
|
||
<!--
|
||
Kabel-Sammlung durchgehen
|
||
Bewusstsein schaffen: Was habe ich eigentlich?
|
||
Viele Lade-Kabel: USB-C, aber nur USB 2.0 (langsam!)
|
||
Forum: Erfahrungsaustausch, lustige Fundstücke
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 4 – 30.01.2026
|
||
## Distribution, APIs & Zukunft
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
LKW voller Festplatten (Symbolbild)
|
||
Sneakernet: Manchmal schneller als Internet!
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Bandbreite vs. Latenz Trade-off
|
||
Internet: Hohe Latenz (9 Tage), aber sofort startbar
|
||
Post: Niedrige Latenz (3 Tage), aber Setup nötig
|
||
AWS Snowball existiert GENAU deswegen
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
AWS Snowmobile: 45-Fuß-Container auf LKW
|
||
100 Petabyte Kapazität
|
||
-->
|
||
|
||
---
|
||
|
||
# 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. Kunde 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
|
||
|
||
<!--
|
||
Snowball: Ruggedized Storage-Gerät
|
||
Snowmobile: Für Exabyte-Scale (Rechenzentrum-Migration)
|
||
Verschlüsselung: 256-Bit AES
|
||
Physical Security: Tamper-resistant, GPS-Tracking
|
||
Use Case: Rechenzentrum-Umzüge, Film-Archive
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
CD, DVD, Blu-ray nebeneinander
|
||
Evolution der optischen Medien
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
CD: Musik-Alben, Software (90er)
|
||
DVD: Filme, PS2-Games
|
||
Blu-ray: HD-Filme, PS3/PS4/PS5-Games
|
||
PS5: Blu-ray-Laufwerk, aber viele Games passen nicht mehr auf eine Disc
|
||
Disc oft nur Installer, Rest kommt aus Netz (Day-One-Patches)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Server unter Last (symbolisch)
|
||
"Hug of Death" – zu viele Anfragen
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
Single Point of Failure
|
||
Keine Skalierbarkeit
|
||
Reddit-Hug-of-Death: Kleine Websites crashen bei Frontpage
|
||
Slashdot-Effekt: Gleiches Problem (2000er)
|
||
CDNs lösen das Problem
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Weltkarte mit CDN-Knoten (Points of Presence)
|
||
Globale Verteilung
|
||
-->
|
||
|
||
---
|
||
|
||
# CDNs: Content Delivery Networks
|
||
|
||
**CDN = Verteiltes Netzwerk weltweit**
|
||
|
||
**Funktionsweise:**
|
||
1. **Origin Server** (Hauptquelle)
|
||
2. **Edge Servers** (geografisch verteilt)
|
||
3. User → 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
|
||
|
||
<!--
|
||
PoP = Point of Presence (Edge-Standort)
|
||
Caching: Zwischenspeicherung beliebter Inhalte
|
||
TTL = Time To Live (wie lange cached?)
|
||
Große CDN-Anbieter: Cloudflare, Akamai, Amazon CloudFront, Fastly
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Static: Logo einer Website (1 Jahr gecached)
|
||
Dynamic: Dein Facebook-Feed (immer aktuell)
|
||
Cache Invalidation: Schwer, weil globale Verteilung
|
||
Versioning: Neue Datei = neuer Cache-Eintrag
|
||
Purge: Manuelles Löschen (teuer, dauert Zeit)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Netflix Open Connect Appliance
|
||
Server in ISP-Rechenzentren
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Open Connect: Kostenlose Appliances für ISPs
|
||
ISPs profitieren: Weniger Backbone-Traffic
|
||
Netflix profitiert: Günstigerer Transit
|
||
Predictive Caching: Neue Season "Stranger Things" → Vorgeladen
|
||
Peering: Direktverbindungen zwischen Netflix & ISPs
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
P2P-Netzwerk-Diagramm
|
||
Dezentral, jeder ist Client & Server
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
P2P vs. Client-Server: Kein zentraler Server
|
||
Last verteilt sich auf alle Teilnehmer
|
||
Je mehr User, desto schneller (umgekehrt zu Client-Server!)
|
||
Zensur-resistent: Kein Single Point of Failure
|
||
Rechtliche Grauzone: Technologie neutral, aber oft illegal genutzt
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
BitTorrent-Swarm-Visualisierung
|
||
Peers tauschen Chunks untereinander
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Bram Cohen: Entwickelte BitTorrent 2001 (Python)
|
||
Tracker: Koordiniert Peers, aber speichert keine Daten
|
||
DHT (Distributed Hash Table): Tracker-loses BitTorrent
|
||
Chunks: Datei in kleine Stücke → Paralleler Download
|
||
Tit-for-tat: Fairness-Mechanismus (Upload = Download-Speed)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
The Pirate Bay Logo (historisch)
|
||
BitTorrent-Index, kontroverser aber wichtiger Teil der Geschichte
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
RIAA verklagte Napster (2001) → Erfolg
|
||
The Pirate Bay: Verklagt, Gründer im Gefängnis, aber Site lebt
|
||
Whack-a-Mole: Domain blocken → neue Domain
|
||
Torrent-Protokoll neutral (wie Messer: Legal, aber Verbrechen möglich)
|
||
Legitime Nutzung: Ubuntu-Download via Torrent (entlastet Server)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
IPFS-Logo
|
||
InterPlanetary File System
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Protocol Labs (Juan Benet, 2014)
|
||
Content-Addressed: URL = Hash (ändert sich bei Änderung → Versionierung automatisch)
|
||
Pinning: Datei dauerhaft verfügbar halten (Knoten müssen hosten)
|
||
Gateway: IPFS über HTTP zugänglich (ipfs.io)
|
||
NFTs: Viele nutzen IPFS (aber nicht alle! Manche nur Links)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Streaming-Pipeline: Encoder → CDN → Player
|
||
HLS/DASH-Segmente
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
HLS = HTTP Live Streaming
|
||
DASH = Dynamic Adaptive Streaming over HTTP
|
||
Adaptive Bitrate: Bandbreite schwankt → Qualität anpassen
|
||
Manifest-Datei: Liste aller Qualitäten & Segmente
|
||
Player-Logik: Misst Bandbreite, wählt beste Qualität
|
||
Latenz-Trade-off: Buffering vs. Real-Time
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Ubuntu-Torrent: Legitim, gut geseeded (schnell)
|
||
qBittorrent: FOSS, keine Ads (im Gegensatz zu uTorrent)
|
||
Swarm beobachten: Peers kommen/gehen
|
||
Upload-Speed: Ihr werdet zum Seeder!
|
||
DevTools: F12, Network-Tab, Seite neu laden
|
||
CDN-Domains: cdn.example.com, cloudfront.net, akamaihd.net
|
||
Headers: Zeigen Cache-Status, CDN-Provider
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Analysiere Streaming-Dienst oder Website:**
|
||
|
||
1. Wähle: Netflix, YouTube, Spotify, News-Seite
|
||
2. DevTools (Network-Tab):
|
||
- Welcher CDN?
|
||
- Wie viele Requests an CDN vs. Origin?
|
||
- Cache-Headers?
|
||
3. Poste im Forum: Screenshot + Erkenntnisse
|
||
|
||
**Bonus:** Linux-ISO via Torrent, poste Peer-Stats
|
||
|
||
<!--
|
||
Selbstständige Exploration
|
||
Netflix: Schwer zu analysieren (verschlüsselt), aber CDN sichtbar
|
||
YouTube: Google CDN (googlevideo.com)
|
||
Spotify: Akamai CDN
|
||
Cache-Control Header: max-age, s-maxage, public/private
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 2: APIs
|
||
## Software-Schnittstellen & Protokolle
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
API-Diagramm mit Pfeilen zwischen Apps
|
||
Software-Kommunikation visualisiert
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
API = Vertrag zwischen Software-Komponenten
|
||
Abstraktion: Implementierung verborgen, nur Interface sichtbar
|
||
Windows API, POSIX, OpenGL = Betriebssystem/Hardware-APIs
|
||
NumPy, React = Library-APIs
|
||
Web-APIs = Heute Fokus
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
HTTP Request/Response-Zyklus
|
||
Client → Server → Client
|
||
-->
|
||
|
||
---
|
||
|
||
# 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 = Tim Berners-Lee (1991, CERN)
|
||
Request-Response-Modell: Client fragt, Server antwortet
|
||
Stateless: Jede Anfrage unabhängig (keine Session am Server)
|
||
HTTPS = HTTP + TLS (Verschlüsselung)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
CRUD: Basis-Operationen für Datenbanken
|
||
RESTful APIs nutzen HTTP-Methods für CRUD
|
||
Idempotenz: GET, PUT, DELETE → mehrfach = gleich
|
||
POST nicht idempotent: 2× POST → 2 neue Einträge
|
||
PATCH: Nur geänderte Felder (effizienter als PUT)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
REST-API-Struktur
|
||
Resources, URLs, HTTP-Methods
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
```
|
||
|
||
<!--
|
||
Roy Fielding: Dissertation 2000 (definierte REST)
|
||
REST = Architektur-Stil,nicht Protokoll
|
||
Stateless: Server speichert keine Session (skalierbar!)
|
||
HATEOAS = Hypermedia as the Engine of Application State (selten implementiert)
|
||
REST-Vorteile: Einfach, cacheable, sprachunabhängig
|
||
REST-Nachteile: Over-/Under-Fetching
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Over-Fetching: Bandbreite-Verschwendung (Mobile!)
|
||
Under-Fetching: Latenz (2 Round-Trips statt 1)
|
||
REST-Workarounds: Query-Parameter (?fields=name,email)
|
||
Aber: Nicht standardisiert, jede API anders
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
GraphQL-Logo
|
||
Facebook-Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# GraphQL: Die REST-Alternative
|
||
|
||
**GraphQL (Facebook, 2015):**
|
||
|
||
**Idee:** Client fragt EXAKT, was er braucht
|
||
|
||
**Query-Beispiel:**
|
||
```graphql
|
||
{
|
||
user(id: 123) {
|
||
name
|
||
email
|
||
posts(limit: 5) {
|
||
title
|
||
createdAt
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
**Vorteile:**
|
||
✓ Kein Over-/Under-Fetching
|
||
✓ Ein Endpoint (`/graphql`)
|
||
✓ Strongly Typed (Schema!)
|
||
|
||
<!--
|
||
Facebook entwickelte GraphQL für Mobile (2012)
|
||
Open-Source 2015
|
||
Schema = Typdefinitionen (wie TypeScript für APIs)
|
||
Introspection: Client kann Schema abfragen (selbst-dokumentierend)
|
||
Nachteile: Komplexer als REST, Caching schwieriger
|
||
-->
|
||
|
||
---
|
||
|
||
# GraphQL Schema
|
||
```graphql
|
||
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)**
|
||
|
||
<!--
|
||
Schema-First-Design: Schema definieren, dann implementieren
|
||
Query: Daten lesen (wie GET)
|
||
Mutation: Daten ändern (wie POST/PUT/DELETE)
|
||
Subscription: Real-Time-Updates (WebSocket-basiert)
|
||
GraphQL Playground: Interactive API Explorer
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
WebSocket-Verbindung: Bidirektional, persistent
|
||
Im Gegensatz zu HTTP Request-Response
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
HTTP: Server antwortet nur auf Anfrage
|
||
Polling: Client fragt jede Sekunde (ineffizient!)
|
||
Long-Polling: Besser, aber Workaround
|
||
WebSocket: Echte bidirektionale Verbindung
|
||
Handshake: HTTP-Upgrade-Request → WebSocket
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!**
|
||
|
||
<!--
|
||
WebSocket-Frames: Text (JSON) oder Binary
|
||
Ping/Pong: Keepalive-Mechanismus
|
||
Protokoll: ws:// (unverschlüsselt), wss:// (verschlüsselt, wie HTTPS)
|
||
Socket.io: JavaScript-Library (vereinfacht WebSocket)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
gRPC-Logo
|
||
Google-Technologie
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
RPC = Remote Procedure Call (wie Funktionsaufruf über Netzwerk)
|
||
Protobuf: Google's Serialisierungsformat (wie JSON, aber binär)
|
||
HTTP/2: Multiplexing = mehrere Requests über eine Connection
|
||
Streaming: Server/Client/Bidirectional möglich
|
||
Use Case: Microservices (interne Kommunikation)
|
||
Browser: gRPC-Web als Workaround (Proxy nötig)
|
||
-->
|
||
|
||
---
|
||
|
||
# gRPC Beispiel
|
||
|
||
**`.proto`-Datei:**
|
||
```protobuf
|
||
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
|
||
|
||
<!--
|
||
.proto = Protocol Buffer Definition
|
||
rpc = Remote Procedure Call (Funktionsdefinition)
|
||
stream = Server-seitige Streaming (Datenstrom)
|
||
Code-Gen: protoc-Compiler generiert Code für Go, Python, Java, C++, etc.
|
||
Type-Safety: Compiler prüft Typen
|
||
-->
|
||
|
||
---
|
||
|
||
# JSON: Das Standard-Format
|
||
|
||
**JSON = JavaScript Object Notation**
|
||
|
||
**Eigenschaften:**
|
||
- Textbasiert, menschenlesbar
|
||
- Schlüssel-Wert-Paare
|
||
- Unterstützt: Objekte, Arrays, Strings, Numbers, Booleans, null
|
||
|
||
**Beispiel:**
|
||
```json
|
||
{
|
||
"name": "Alice",
|
||
"age": 28,
|
||
"posts": [
|
||
{"title": "Hello", "views": 42},
|
||
{"title": "World", "views": 123}
|
||
]
|
||
}
|
||
```
|
||
|
||
<!--
|
||
JSON = Subset von JavaScript (aber sprachunabhängig)
|
||
Überall unterstützt: Jede Programmiersprache
|
||
UTF-8 Encoding (Emojis möglich!)
|
||
Kein Kommentar-Support (Kritikpunkt)
|
||
Alternativen: XML (verbose), YAML (menschenfreundlicher), Protobuf (binär)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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:
|
||
```bash
|
||
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
|
||
|
||
<!--
|
||
JSONPlaceholder: Fake REST API für Testing
|
||
curl: Command-Line HTTP-Tool (Linux/macOS/Windows)
|
||
Postman: GUI-Alternative (einfacher)
|
||
-X POST: HTTP-Method
|
||
-H: Header setzen
|
||
-d: Data (Body)
|
||
WebSocket Echo: Server echot zurück (Test-Server)
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Experimentiere mit öffentlicher API:**
|
||
|
||
1. Wähle:
|
||
- GitHub API (`api.github.com`)
|
||
- OpenWeather (`openweathermap.org/api`)
|
||
- PokéAPI (`pokeapi.co`)
|
||
2. Mache 3-5 Requests (curl, Postman, oder Code)
|
||
3. Poste im Forum:
|
||
- Welche API?
|
||
- Interessante Daten?
|
||
- Rate-Limiting erlebt? (429 Too Many Requests)
|
||
|
||
**Bonus:** Baue kleinen Client (Python, JavaScript, etc.)
|
||
|
||
<!--
|
||
GitHub API: Repositories, Users, Issues (kostenlos, aber Rate-Limit)
|
||
OpenWeather: Wetterdaten (API-Key nötig, Free Tier)
|
||
PokéAPI: Pokémon-Daten (keine Auth nötig)
|
||
Rate-Limiting: 429 Status Code (zu viele Requests)
|
||
Client bauen: Praktische Anwendung (Python requests, JavaScript fetch)
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 3: Metadaten
|
||
## Daten über Daten & Interoperabilität
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Foto mit eingeblendeten GPS-Koordinaten
|
||
EXIF-Daten visualisiert
|
||
Privacy-Albtraum
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
"Data about data" = Standard-Definition
|
||
Metadaten oft wichtiger als Daten selbst (NSA: "We kill people based on metadata")
|
||
Jede Datei hat Metadaten (implizit oder explizit)
|
||
Header in Dateien: Erste Bytes oft Metadaten
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
JEITA = Japan Electronic & Information Technology Industries Association
|
||
EXIF in JPEG, TIFF, WAV, etc.
|
||
GPS: Automatisch von Smartphones hinzugefügt (wenn Location-Services an)
|
||
Software: Zeigt, ob Bild bearbeitet wurde
|
||
Orientation: Landscape/Portrait (für Auto-Rotation)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
John McAfee Guatemala-Story (2012)
|
||
Vice Magazine veröffentlichte Foto mit GPS-EXIF
|
||
Aufenthaltsort verraten
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
EXIF standardmäßig AN (die meisten wissen's nicht)
|
||
Jedes Handy-Foto = potentieller Fingerabdruck
|
||
Whistleblower: Reality Winner (2017) – NSA-Dokument mit Druckerspuren
|
||
Druckerspuren: Gelbe Punkte (Machine Identification Code)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
```bash
|
||
exiftool -all= foto.jpg # Entfernt ALLE Metadaten
|
||
```
|
||
|
||
<!--
|
||
Twitter-Kritik 2015: Journalisten-Fotos verrieten Standorte
|
||
Facebook: GPS entfernt, aber Kamera-Modell bleibt
|
||
Signal: Entfernt EXIF automatisch
|
||
Telegram: Nicht immer (unsicher!)
|
||
Cloud: Originaldatei bleibt unverändert (gut für Backup, schlecht für Privacy)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
ID3-Tag-Editor (Screenshot)
|
||
MP3-Metadaten bearbeiten
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
ID3v1: Ursprünglich (1996), sehr limitiert
|
||
Genre: Fixe Liste (0-255), nicht erweiterbar
|
||
ID3v2: Seit 1998, viel flexibler
|
||
Cover-Art: JPEG embedded in MP3 (APIC-Frame)
|
||
BPM: Beats per Minute (für DJs)
|
||
Composer: Unterschied zu Artist (klassische Musik)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
MusicBrainz-Logo
|
||
Wikipedia für Musik-Metadaten
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
MusicBrainz: Non-Profit, Community-driven
|
||
Gracenote: Sony-Tochter, proprietär, teuer
|
||
CDDB: Ursprünglich frei, dann kommerzialisiert (1998)
|
||
AcoustID: Akustischer Fingerabdruck (wie Shazam)
|
||
Picard: Python-basiert, FOSS
|
||
API: Frei nutzbar (Rate-Limited)
|
||
-->
|
||
|
||
---
|
||
|
||
# Dublin Core: Universelle Metadaten
|
||
|
||
**Dublin Core (1995, Dublin, Ohio):**
|
||
|
||
**15 Kern-Elemente:**
|
||
1. Title, 2. Creator, 3. Subject, 4. Description
|
||
5. Publisher, 6. Contributor, 7. Date, 8. Type
|
||
9. Format, 10. Identifier (ISBN, DOI)
|
||
11. Source, 12. Language, 13. Relation
|
||
14. Coverage, 15. Rights
|
||
|
||
**Anwendung:** Bibliotheken, Archive, Webseiten (HTML `<meta>`)
|
||
|
||
<!--
|
||
Dublin Core Metadata Initiative (DCMI)
|
||
Standard für Ressourcen-Beschreibung (nicht nur Dateien)
|
||
Einfach, aber universell
|
||
HTML: <meta name="DC.title" content="...">
|
||
Erweitert: Qualified Dublin Core (mehr Felder)
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
PDF-Metadaten-Analyse (Screenshot)
|
||
Versteckte Informationen sichtbar
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
XMP = Extensible Metadata Platform (Adobe)
|
||
Company: Windows Office speichert Firmennamen aus Lizenz
|
||
Track Changes: Word → PDF kann History enthalten
|
||
Tony Blair: "Dodgy Dossier" – Copy-Paste aus Student-Arbeit nachgewiesen
|
||
PDF-Redaktion: Adobe Acrobat Pro "Sanitize Document"
|
||
Dangerzone: FOSS-Tool (Freedom of Press Foundation)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Interoperabilität = Zusammenarbeit verschiedener Systeme
|
||
Lock-in: "Gefangene Daten" (nur in Software X öffenbar)
|
||
Firma geht pleite → Format stirbt (WordPerfect-Beispiel)
|
||
Offene Standards: Überlebensfähiger (Community kann implementieren)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
.docx: Heute Open XML (standardisiert), aber viele proprietäre Extensions
|
||
OOXML vs. ODF: Zwei konkurrierende Standards (beide ISO)
|
||
PSD: 30+ Jahre alt, extrem komplex
|
||
GIMP: Free, aber nicht Feature-Parität
|
||
Apple: Export zu Office-Formaten verliert Features
|
||
Lock-in = Business-Strategie
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Format-Tod: Unvermeidlich (30+ Jahre Lebensdauer selten)
|
||
WordPerfect: Marktführer 1980er, heute Museum
|
||
Flash: Adobe kündigte 2020 Support-Ende an
|
||
PDF/A: Archiv-PDF (Subset, keine interaktiven Features)
|
||
TIFF: Unkomprimiert, für Langzeitarchivierung
|
||
Plain Text: Überlebt alles (ASCII/UTF-8)
|
||
Migration alle 5-10 Jahre nötig
|
||
-->
|
||
|
||
---
|
||
|
||
# Metadaten für Accessibility
|
||
|
||
**Alt-Text (Alternative Text):**
|
||
```html
|
||
<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
|
||
|
||
<!--
|
||
Alt-Text: Beschreibt Bild für Blinde (Screen-Reader liest vor)
|
||
Schlechter Alt-Text: "Bild123.jpg" (nutzlos!)
|
||
Guter Alt-Text: Beschreibend, kontextbezogen
|
||
PDF-Tags: "Tagged PDF" vs. "Untagged PDF"
|
||
Untagged: Für Screen-Reader oft unbrauchbar (nur Textstrom)
|
||
WCAG = Web Content Accessibility Guidelines (W3C)
|
||
ADA = Americans with Disabilities Act (USA, rechtlich)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
exiftool: Command-Line, mächtig (alle Metadaten-Formate)
|
||
metapicz.com: Online, einfach
|
||
Dateigröße: EXIF-Daten können 10-50 KB sein
|
||
GPS-Schock: Viele wissen nicht, dass GPS gespeichert wird
|
||
Kid3: GUI, Cross-Platform
|
||
MusicBrainz Picard: Audio-Fingerprinting in Aktion
|
||
-->
|
||
|
||
---
|
||
|
||
# Aufgabe bis nächste Woche
|
||
|
||
**Metadaten-Audit:**
|
||
|
||
1. Wähle 3 Dateitypen:
|
||
- Ein Foto (EXIF)
|
||
- Eine MP3 (ID3)
|
||
- Ein PDF (XMP)
|
||
2. Analysiere: Welche Metadaten?
|
||
3. 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?
|
||
|
||
<!--
|
||
Selbst-Exploration
|
||
Viele entdecken GPS zum ersten Mal
|
||
Alte Dateien: Zeit-Kapsel (alte Software, Kamera-Modelle)
|
||
KB-Ersparnis: Oft gering, aber Prinzip wichtig
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Teil 4: Zukunft
|
||
## Trends & Ausblick
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
Futuristisches Rechenzentrum
|
||
DNA-Helix überlagert
|
||
-->
|
||
|
||
---
|
||
|
||
# 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?
|
||
|
||
<!--
|
||
10 Wochen = Journey durch digitale Medien
|
||
Von Grundlagen (Bits) zu Infrastruktur (CDN)
|
||
Technologie + Geschichte + Politik
|
||
Heute: Zukunft + Abschluss-Projekt
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
AI-Kompression: Neuronale Netze statt handcrafted Algorithmen
|
||
Google: Variational Autoencoders (VAEs) für Kompression
|
||
Generative: "Ein Golden Retriever im Wald" → Neu generiert
|
||
Nicht bit-genau: Akzeptabel für Streaming, nicht für Archivierung
|
||
GPU/NPU nötig: Noch nicht Consumer-ready
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
JPEG XL Logo
|
||
Moderner JPEG-Nachfolger
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
JPEG XL = JXL
|
||
Cloudinary, Facebook testeten JXL (positive Ergebnisse)
|
||
Chrome entfernte Support 2022, Re-Add-Diskussion 2024
|
||
Safari (WebKit): Support seit 2022
|
||
Technisch überlegen, aber Standards sterben an Politik
|
||
-->
|
||
|
||
---
|
||
|
||
# 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?
|
||
|
||
<!--
|
||
AV1: YouTube forciert (8K nur AV1)
|
||
VVC: Technisch brilliant, juristisch Albtraum (wie H.265)
|
||
LCEVC = Low Complexity Enhancement Video Coding
|
||
AV2: Alliance for Open Media arbeitet dran
|
||
ML: Neural Codecs (Google's "Neural Video Coding")
|
||
-->
|
||
|
||
---
|
||
|
||
|
||
|
||
<!--
|
||
DNA-Storage-Konzept
|
||
Futuristisch, aber real
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
DNA = A, T, G, C (4 Basen)
|
||
Kodierung: Binär → DNA (00=A, 01=T, 10=G, 11=C)
|
||
215 PB/g: Gesamte Internet-Daten in Schuhkarton
|
||
Haltbarkeit: Mammut-DNA 10.000+ Jahre alt, lesbar
|
||
Kosten: 2010 = $12.000/MB, 2021 = $3.500/MB (Exponentialfall)
|
||
Twist Bioscience: Kommerzielle DNA-Synthese
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Hologramm: 3D-Information in 2D-Medium
|
||
InPhase Technologies: Bankrott 2010 (zu früh)
|
||
Sony: Forschung läuft weiter
|
||
Terabyte-Discs: Waren Ziel (nie erreicht)
|
||
Konkurrenz: SSDs wurden billiger, schneller
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Qubits: Quantenbits (z.B. Photon-Polarisation, Elektron-Spin)
|
||
Superposition: Kollabiert bei Messung
|
||
Quantencomputer: IBM, Google, D-Wave
|
||
Speicherproblem: Dekohärenz (Qubits verlieren Zustand)
|
||
QKD: Abhör-sichere Kommunikation (Quantenmechanik garantiert)
|
||
"Immer 20 Jahre entfernt" (wie Fusion)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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)
|
||
|
||
<!--
|
||
IPFS: Besprochen in Woche 7
|
||
Filecoin: Incentive-Layer für IPFS (Storage Market)
|
||
Arweave: Endowment-Modell (Zinsen finanzieren Storage)
|
||
Storj: S3-Äquivalent, verschlüsselt & verteilt
|
||
Hype vs. Reality: Viele gescheiterte Projekte
|
||
Legitime Use-Cases: NFT-Storage, Zensur-resistente Archivierung
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!)
|
||
|
||
<!--
|
||
8K: YouTube unterstützt, aber wer hat 8K-Monitor?
|
||
VR: Meta Quest, Apple Vision Pro
|
||
Latenz: Lichtgeschwindigkeit ~300.000 km/s, aber Routing + Processing addiert sich
|
||
Edge Computing: Server näher an User (5G-Masten)
|
||
Cloud Gaming: Stadia gescheitert (2023 †), GeForce Now, Xbox Cloud
|
||
Input-Lag: Fiber ~5ms/1000km, aber Server-Processing + Encoding + Decoding
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!)
|
||
|
||
<!--
|
||
Stromverbrauch: AI-Training + Crypto-Mining steigend
|
||
Netflix: 2019 Studie (umstritten, aber Größenordnung)
|
||
E-Waste: 53,6 Mio. Tonnen/Jahr (2019, UN)
|
||
Right to Repair: EU-Gesetze, Apple-Widerstand
|
||
Effizienz: AV1 spart 30% Bandbreite vs. H.264
|
||
Green Data Centers: Island (Geothermie), Nordics (Wasserkraft)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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?
|
||
|
||
<!--
|
||
ISO/IEC: Internationale Standards (JPEG, MPEG, etc.)
|
||
IETF: RFCs (HTTP, TLS, etc.)
|
||
W3C: HTML, CSS, Web-APIs
|
||
IEEE: Ethernet, Wi-Fi
|
||
Patent-Pools: Kartelle? Oder notwendige Koordination?
|
||
USB-C-Pflicht: EU zwang Apple (iPhone 15)
|
||
DMA: Zwingt Big Tech zu Interoperabilität (Messenger)
|
||
GDPR: Privacy by Design
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Praxisnahe Anwendung aller Themen
|
||
Gruppenarbeit: Peer-Learning
|
||
Szenarien vorgeben (Vorgänger-Skript hatte 6)
|
||
Alternativen: Stadtarchiv, Agentur, Hochschul-Mediathek, Fotografin, Reporterteam
|
||
Bewertung: Technische Korrektheit, Begründung, Kreativität
|
||
-->
|
||
|
||
---
|
||
|
||
# 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**
|
||
|
||
<!--
|
||
Verschiedene Complexity-Level
|
||
Stadtarchiv: Langzeitarchivierung-Fokus
|
||
Agentur: Collaboration-Fokus
|
||
Fotografin: Solo-Workflow
|
||
Reporterteam: Security-Fokus (Verschlüsselung!)
|
||
Gruppen wählen selbst (Interesse)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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.
|
||
|
||
<!--
|
||
10 Wochen = Intensive Journey
|
||
Von Grundlagen zu Zukunft
|
||
Technologie ist nicht neutral (Patent-Kriege, Vendor Lock-in)
|
||
Kritisches Denken: Wer profitiert? Wer wird ausgeschlossen?
|
||
Hands-On: Praktische Fähigkeiten (Hex-Editor, FFmpeg, exiftool)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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
|
||
|
||
<!--
|
||
Petzold "Code": Beste Einführung in Computer-Grundlagen
|
||
Lyons: Für Audio/Video-Kompression (mathematisch)
|
||
IETF RFCs: Primärquellen (HTTP, TLS, etc.)
|
||
Computerphile: Tom Scott, Mike Pound (hervorragend!)
|
||
Branch Education: 3D-Animationen (SSD, CPU...)
|
||
Command Line Heroes: Tech-Geschichte (Spotify, Apple Podcasts)
|
||
-->
|
||
|
||
---
|
||
|
||
# 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!**
|
||
|
||
<!--
|
||
10 Wochen gemeinsame Reise
|
||
Von "Was sind Bits?" zu "DNA-Storage"
|
||
Hands-On jede Woche (Hex-Editor, FFmpeg, exiftool, APIs)
|
||
Narrative statt Faktenlisten (Suzanne Vega, John McAfee, Tony Blair)
|
||
Kritische Perspektive (Patent-Kriege, Vendor Lock-in)
|
||
Evaluation: Feedback ernst nehmen, Kurs verbessern
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Termin 5 – TBA
|
||
## Vertiefung & Offene Fragen
|
||
|
||
---
|
||
|
||
# Ersatztermin
|
||
|
||
**Dieser Termin wird noch bekannt gegeben.**
|
||
|
||
Mögliche Inhalte:
|
||
- Vertiefung von Themen nach Wunsch
|
||
- Praxisübungen & Hands-On
|
||
- Offene Fragen & Diskussion
|
||
- Prüfungsvorbereitung
|
||
|
||
<!--
|
||
Flexibler Termin für Nachholbedarf
|
||
Themen nach Interesse der Studierenden
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _class: lead -->
|
||
|
||
# Fragen & Diskussion
|
||
|
||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||
**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/
|
||
|
||
<!--
|
||
Open Educational Resources (OER)
|
||
Studierende können Folien nutzen, remixen, teilen
|
||
CC BY-SA: Wikipedia-Lizenz (Share-Alike)
|
||
Attribution: "Michaล‚ Czechowski, HdM Stuttgart"
|
||
-->
|
||
|