split index.md into modular slide files
- extract _frontmatter.md, _intro.md, _outro.md as shared components - create separate files per termin with date-topic naming convention: 2025-12-19-termin-1-grundlagen-text-audio.md 2026-01-09-termin-2-bild-audio-video.md 2026-01-23-termin-3-speichermedien-schnittstellen.md 2026-01-30-termin-4-distribution-apis-zukunft.md 2026-xx-xx-termin-5-vertiefung-offene-fragen.md - keep index.md.bak as backup (gitignored)
This commit is contained in:
@@ -0,0 +1,634 @@
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,686 @@
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,918 @@
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,24 @@
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
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>
|
||||
|
||||
@@ -0,0 +1,83 @@
|
||||
|
||||
|
||||
<!-- 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
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
|
||||
<!-- _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"
|
||||
-->
|
||||
|
||||
Reference in New Issue
Block a user