From 636e7e021e3ce11b1a3b2cb3aa48594aae6a7610 Mon Sep 17 00:00:00 2001 From: Michael Czechowski Date: Thu, 14 May 2026 11:59:18 +0200 Subject: [PATCH] =?UTF-8?q?223015b=20phase=204:=20kap3=20slide-MD=20(filen?= =?UTF-8?q?ame=20misleading:=2003-speichermedien-schnittstellen.md=20h?= =?UTF-8?q?=C3=A4lt=20jetzt=20kap=20'inhalte=20=E2=80=94=20bild,=20audio,?= =?UTF-8?q?=20video').=2040=20slides=20nach=20bogen=20(gek=C3=BCrzt=20von?= =?UTF-8?q?=2049=20weil=20JPEG-6-schritte=20teilweise=20konsolidiert=20+?= =?UTF-8?q?=20weniger=20marketing-folien)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit struktur: - 3 intro: cover, 'drei modalitäten ein prinzip', kap03-eroeffner als advance organizer - 20 BILDER: lead, raster-vs-vektor-demo, klausur-tabelle, lead JPEG, jpeg-pipeline-demo, einzel-folien für jeden schritt (Y'CbCr farbraum mit Barn-yuv reuse, chroma-subsampling mit Common_chroma_ reuse, 8x8+DCT kombiniert, quantisierung detail mit DCT-koeffizienten beispiel, huffman+zigzag+RLE), klausur memo 6 schritte tabelle, JPEG-artefakte felis-katze reuse, lead andere bildformate, übersicht-tabelle PNG/GIF/WebP/AVIF/SVG, klausur wann-welches, patent-politik WebP vs JPEG XL - 8 AUDIO: lead, sampling-bittiefe recap aus kap1, psychoakustik-grafik reuse für maskierung, bitrate-tabelle 64/128/192/320/1411, audio-format-landschaft WAV/FLAC/MP3/AAC/Opus, klausur format-wahl, selbstlernen spotify-bitrate - 14 VIDEO: lead, datenflut-rechnung 4K@60fps = 1.49 GB/s, container-ungleich-codec mit container-codec-diagram reuse, container-anatomie text, inter-frame-kompression mit iframe-pframe-diagram reuse, klausur I/P/B-frames, motion-compensation, lead codec-landschaft, H.264 workhorse, H.265 patent-chaos, VP9+AV1 offene antwort, klausur patent-vs-open, 4K-bitrate vs heim-bandbreite tabelle - 3 selbstlernen + 1 summary: 3-übungen-folie (squoosh/spotify/mediainfo), zusammenfassung-tabelle drei modalitäten reuse-demos: kap03-eroeffner, raster-vs-vektor, jpeg-pipeline, psychoakustik-grafik reuse-assets: Barn-yuv.png, Common_chroma_subsampling.png, Felis_silvestris.jpg, container-codec-diagram.png, iframe-pframe-diagram.png klausur-marker (5 stück, fragmentiert): raster-vs-vektor (8), 6-schritte-memo (18), wann-welches-bildformat (22), audio-format-wahl (30), container-ungleich-codec (34), I/P/B-frames (38), patent-vs-open AV1 (44) build geht durch --- .../03-speichermedien-schnittstellen.md | 1442 +++++++++-------- 1 file changed, 801 insertions(+), 641 deletions(-) diff --git a/slides/223015b/03-speichermedien-schnittstellen.md b/slides/223015b/03-speichermedien-schnittstellen.md index 6cd4c6d..32bfd57 100644 --- a/slides/223015b/03-speichermedien-schnittstellen.md +++ b/slides/223015b/03-speichermedien-schnittstellen.md @@ -5,7 +5,7 @@ paginate: true backgroundColor: #fff header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)" footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026" -title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege +title: Inhalte — Bild, Audio, Video --- - - - + -![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg) +# Kapitel 3 +## Inhalte — Bild, Audio, Video -# Dateiformate, Schnittstellen, Speichermedien & Distributionswege + - - -![bg fit](./assets/qr/slides-223015b.png) +Bogen: +1. Bilder (Raster vs Vektor, JPEG-Pipeline, weitere Formate) +2. Audio (MP3-Pipeline-Recap, Format-Wahl) +3. Video (Container ≠ Codec, I/P/B-Frames, H.264 vs H.265 vs AV1) +--> --- -# Kapitel 3 – 23.01.2026 -## Speichermedien & Schnittstellen +# Drei Modalitäten, ein Prinzip + + --- -![bg](./assets/hdd-ssd-comparison.png) +![bg fit](./assets/demos/kap03-eroeffner.png) --- -# Speicherkapazität: KB vs. KiB + -**Das Problem:** Hersteller vs. Betriebssysteme - -| Dezimal (SI) | Binär (IEC) | -|--------------|-------------| -| 1 KB = 1.000 Bytes | 1 KiB = 1.024 Bytes | -| 1 MB = 1.000 KB | 1 MiB = 1.024 KiB | -| 1 GB = 1.000 MB | 1 GiB = 1.024 MiB | -| 1 TB = 1.000 GB | 1 TiB = 1.024 GiB | - -**1 TB Festplatte → Windows zeigt ~931 GB!** +# Sub-Sektion A: Bilder --- -# HDD: Aufbau & Struktur + + -**Komponenten:** -- **Platter:** Magnetisch beschichtete Scheiben -- **Spindel:** Dreht mit 5.400-7.200 RPM -- **Schreib-Lese-Kopf:** Schwebt nm-dünn über Platter -- **Aktuator:** Bewegt Kopf zur richtigen Spur - -**Logische Struktur:** -- **Spuren:** Konzentrische Kreise auf Platter -- **Sektoren:** Unterteilung der Spuren (512 Bytes) -- **Zylinder:** Gleiche Spuren aller Platter +![bg fit](./assets/demos/raster-vs-vektor.png) +Zwei fundamentale Bild-Modelle: ---- +**Raster:** Bild = Gitter aus Pixel-Farbwerten. Jede Position fest belegt. +- Beispiele: PNG, JPEG, GIF, WebP, RAW +- Vorteil: kann Fotos darstellen (kontinuierliche Tonwerte) +- Nachteil: feste Auflösung. Beim Vergrößern wird es pixelig. -# NVMe: Die SSD-Revolution +**Vektor:** Bild = mathematische Anweisungen ("Punkt 30,110 → Punkt 90,170 → Punkt 250,30, Strichbreite 14"). +- Beispiele: SVG, PDF, Schriftarten, Adobe Illustrator +- Vorteil: scharf bei jeder Größe (wird neu berechnet) +- Nachteil: kann keine Fotos (keine analytischen Beschreibungen für Megapixel von Pixeln) -**NVMe = Non-Volatile Memory Express (2011)** - -**Unterschied zu SATA-SSD:** -- SATA: Max. ~550 MB/s (AHCI-Protokoll) -- NVMe: Bis zu 7.000+ MB/s (PCIe direkt) - -**Form-Faktoren:** -2,5" (SATA), M.2 (SATA oder NVMe), PCIe-Karte - - - ---- - -# HDD vs. SSD: Vergleich - -| Aspekt | HDD | SSD (NVMe) | -|--------|----:|----------:| -| Sequentiell | ~150 MB/s | ~3.500 MB/s | -| Random Read | ~1 MB/s | ~500 MB/s | -| Latenz | ~10 ms | ~0,02 ms | -| Preis/TB | ~15€ | ~60€ | -| Max. Kapazität | 24 TB | 8 TB (Consumer) | -| Haltbarkeit | 3-5 Jahre | 5-10 Jahre | - - --- - - - -# Wann HDD, wann SSD? +# Raster vs. Vektor -| Anwendung | Empfehlung | -|-----------|------------| -| Betriebssystem | SSD (NVMe) | -| Anwendungen, Spiele | SSD | -| Video-Editing (Projekte) | SSD | -| Foto-Archiv | HDD oder SSD | -| Backup | HDD | -| NAS / Server | HDD (oder Mix) | -| Cold Storage | HDD oder Band | +| | Raster | Vektor | +|--|--------|--------| +| Was | Gitter aus Pixel-Werten | Mathematische Anweisungen | +| Speicher | wächst mit Auflösung | wächst mit Komplexität | +| Skalierung | pixelig beim Zoom | scharf bei jeder Größe | +| Geeignet für | Fotos, Screenshots | Logos, Icons, Schrift | +| Formate | PNG · JPEG · GIF · WebP | SVG · PDF · Schriftarten | - ---- - - - - - -# HDD vs. SSD – Vertiefung - -**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor). - -**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles). - -| Aspekt | HDD | SATA SSD | NVMe SSD | -|--------|-----|----------|----------| -| Latenz | 5–10 ms | 0,1 ms | 0,02 ms | -| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s | -| IOPS (4K random) | 100 | 90.000 | 1.000.000 | -| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW | - -**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke. - -**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden. - ---- - - - -# Dateisysteme -## Die Organisation der Daten - ---- - -# Was macht ein Dateisystem? - -**Aufgaben:** -- Dateien in Blöcke aufteilen -- Speicherort verwalten (Allokation) -- Verzeichnisstruktur pflegen -- Metadaten speichern (Name, Datum, Rechte) -- Integrität sichern (Journaling) - -**Ohne Dateisystem:** -Nur eine Folge von Bytes ohne Struktur. - - - ---- - -# FAT32: Der Kompatibilitätskönig - -**File Allocation Table, 32-bit (1996)** - -**Vorteile:** -- Überall lesbar (Windows, Mac, Linux, Kameras, Fernseher...) -- Einfach, robust - -**Nachteile:** -- Max. 4 GB pro Datei -- Max. 2 TB pro Volume -- Keine Berechtigungen -- Kein Journaling - -**Ideal für:** USB-Sticks, SD-Karten (Kompatibilität) - - - ---- - -# exFAT: FAT32 ohne Limits - -**Extended FAT (2006, Microsoft)** - -**Vorteile:** -- Keine praktischen Dateigrößen-Limits -- Breite Unterstützung (seit 2019 auch Linux-Kernel) -- Für Flash-Speicher optimiert - -**Nachteile:** -- Kein Journaling -- Weniger robust als NTFS/APFS/ext4 - -**Ideal für:** Große Dateien auf portablen Medien - - - ---- - -# NTFS: Windows-Standard - -**New Technology File System (1993)** - -**Features:** -- Journaling (Crash-Sicherheit) -- Dateirechte (ACLs) -- Kompression, Verschlüsselung -- Große Dateien und Volumes - -**Nachteile:** -- Nur Windows schreibt nativ -- macOS: Nur lesen -- Linux: Über ntfs-3g (langsamer) - - - ---- - -# APFS: Apple-Modern - -**Apple File System (2017)** - -**Features:** -- Snapshots (Zeitpunkt-Kopien) -- Copy-on-Write (CoW) -- Native Verschlüsselung -- Optimiert für SSDs - -**Nachteile:** -- Nur Apple-Geräte -- Nicht abwärtskompatibel mit HFS+ - - - ---- - -# ext4: Linux-Standard - -**Fourth Extended File System (2008)** - -**Features:** -- Journaling -- Extents (effiziente große Dateien) -- Online-Defragmentierung -- Bewährt und stabil - -**Nachteile:** -- Windows/macOS können nicht nativ lesen -- Weniger Features als btrfs/ZFS - - - ---- - -# Dateisysteme: Übersicht - -| FS | Max. Datei | Journaling | Ideal für | -|----|----------:|:----------:|-----------| -| FAT32 | 4 GB | ❌ | Kompatibilität | -| exFAT | 16 EB | ❌ | Große portable Dateien | -| NTFS | 16 EB | ✓ | Windows | -| APFS | 8 EB | ✓ | macOS, iOS | -| ext4 | 16 TB | ✓ | Linux | - - --- -# Backup & Archivierung +# JPEG — das Foto-Workhorse seit 1992 + + --- -![bg](./assets/backup-disaster.png) +![bg fit](./assets/demos/jpeg-pipeline.png) --- -# Warum Backup? +# Schritt 1: Farbraum-Konversion (RGB → Y'CbCr) -**Realitäten:** -- HDDs haben 1-2% jährliche Ausfallrate -- SSDs können ohne Vorwarnung sterben -- Ransomware verschlüsselt Daten -- Versehentliches Löschen passiert -- Diebstahl, Brand, Wasserschaden +![bg right:50% contain](./assets/Barn-yuv.png) -**Die Frage ist nicht ob, sondern wann.** +**Trick:** Helligkeit von Farbe **trennen**. + +- **Y** (Luminanz) = wie hell ist der Pixel +- **Cb** = blau-gelb-Differenz +- **Cr** = rot-grün-Differenz + +Das Auge sieht **Luminanz scharf**, **Chrominanz grob**. +Durch Trennung können beide unabhängig komprimiert werden. + +--- + +# Schritt 2: Chroma-Subsampling (4:2:0) + +![bg right:48% contain](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png) + +**Y bleibt voll.** **Cb und Cr werden auf 1/4 reduziert** (2×2 Pixel teilen sich einen Farbwert). + +- 4:4:4 = keine Reduktion +- 4:2:2 = horizontal halbiert +- **4:2:0 = JPEG-Standard, beide Richtungen halbiert** + +**Lossy.** Speichermenge halbiert, sichtbarer Unterschied: null. + + + +--- + +# Schritt 3 & 4: 8×8 Blöcke + DCT + +Das Bild wird in **8×8-Pixel-Blöcke** zerlegt. *Jeder Block einzeln* weiterverarbeitet. + +**DCT** (Diskrete Kosinus-Transformation) zerlegt jeden Block in **Frequenz-Komponenten:** + +- niedrige Frequenz = grobe Helligkeitsänderungen (Hintergrund) +- hohe Frequenz = feines Detail (Kanten, Rauschen) + +Beide Schritte sind **verlustfrei**. Sie bereiten Schritt 5 vor. + + + +--- + +# Schritt 5: Quantisierung — *hier* wird weggeworfen + +Jeder DCT-Koeffizient wird durch einen Wert aus der **Quantisierungs-Tabelle** geteilt und gerundet. + +**Niedrige Frequenzen** (wichtig): kleine Tabellen-Werte → wenig Rundung → bleiben erhalten. +**Hohe Frequenzen** (Detail): große Tabellen-Werte → starke Rundung → werden Null. + +**Quality-Slider 100 → 1** ist nichts anderes als „aggressiver multiplizieren". + + + +--- + +# Schritt 6: Huffman-Coding (verlustfrei) + +Die quantisierten Koeffizienten sind voller **Nullen** (die hohen Frequenzen). + +**Huffman:** häufige Werte (= Nullen) bekommen **kurze Codes**, seltene Werte lange Codes. + +Plus **Zigzag-Scan + RLE**: lange Null-Sequenzen → ein einziges Symbol. + +**Resultat:** finale JPEG-Datei. Verlustfrei aus quantisierten Werten rekonstruierbar. + + --- - - - -# Die 3-2-1-Regel +# Memo: Die 6 JPEG-Schritte -**3** Kopien eurer Daten -(Original + 2 Backups) +| # | Schritt | Lossless / Lossy | +|---|---------|------------------| +| 1 | RGB → Y'CbCr (Farbraum) | Lossless | +| 2 | Chroma-Subsampling 4:2:0 | **Lossy** | +| 3 | 8×8 Blöcke | Lossless | +| 4 | DCT (Frequenz-Zerlegung) | Lossless | +| 5 | Quantisierung | **Lossy** (Haupt-Reduktion) | +| 6 | Huffman + Zigzag + RLE | Lossless | -**2** verschiedene Medientypen -(z.B. SSD + HDD, oder lokal + Cloud) - -**1** Kopie an anderem Ort -(Offsite: Cloud, anderes Gebäude) +Nur **2** der 6 Schritte verlieren Information. --- - -# 3-2-1-Backup-Regel – Vertiefung - -Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien: - -| Bedrohung | Schutz durch | Beispiel | -|-----------|--------------|----------| -| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden | -| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System | -| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher | - -**Moderne Erweiterung 3-2-1-1-0:** -- **+1** Air-Gapped (offline, nicht verbunden) -- **+0** Verifizierte Backups (regelmäßig Restore testen) - -**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind. - -**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots. - ---- - -# Backup-Arten - -**Vollständig (Full):** -Kompletter Datenbestand jedes Mal. -Einfach, aber langsam und platzhungrig. - -**Inkrementell:** -Nur Änderungen seit dem letzten Backup. -Schnell, aber Wiederherstellung komplex (Kette). - -**Differenziell:** -Änderungen seit dem letzten Voll-Backup. -Mittelweg zwischen beiden. +![bg fit](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg) +Links: kaum komprimiert (Quality ~100). +Mitte: mittlere Quality (~50). +Rechts: extreme Kompression (Quality ~10) → 8×8-Blöcke sichtbar, Farbsäume, Detail-Verlust. ---- - -# Backup in der Praxis - -**macOS:** Time Machine -**Windows:** Veeam Agent (kostenlos), Windows Backup -**Linux:** rsync, Borg, Restic -**Cloud:** Backblaze, iCloud, Google Drive - -**Wichtig:** -- Automatisieren (manuell wird vergessen) -- Regelmäßig testen (Backup nützt nichts, wenn Restore nicht funktioniert) - - - ---- - -# Langzeitarchivierung - -**Probleme:** -- Bit Rot (Daten degradieren) -- Format-Obsoleszenz (wer öffnet .wpd?) -- Hardware-Obsoleszenz (Diskettenlaufwerk?) - -**Lösungen:** -- Migration alle 5-10 Jahre auf neue Medien -- Offene Standards (PDF/A, TIFF, Plain Text) -- Redundante Kopien - - - ---- - -# Archivmedien - -**LTO-Tapes:** -- 18 TB pro Band (LTO-9) -- ~5€/TB -- 30 Jahre Haltbarkeit -- Für Cold Storage ideal - -**M-DISC:** -- Spezielle DVD/Blu-ray -- 1.000+ Jahre Haltbarkeit (Herstellerangabe) -- Für kleine, wichtige Daten - -**Cloud:** -- Glacier, Backblaze B2 -- Günstig für Langzeit - - --- -# Schnittstellen - ---- - -# USB: Die Universal-Schnittstelle - -| Version | Jahr | Geschwindigkeit | -|---------|------|----------------:| -| USB 1.1 | 1998 | 12 Mbit/s | -| USB 2.0 | 2000 | 480 Mbit/s (~60 MB/s) | -| USB 3.0 | 2008 | 5 Gbit/s (~625 MB/s) | -| USB 3.1 Gen 2 | 2013 | 10 Gbit/s | -| USB 3.2 Gen 2×2 | 2017 | 20 Gbit/s | -| USB4 | 2019 | 40 Gbit/s | +# Andere Bildformate --- -# USB-C: Der Stecker, nicht die Geschwindigkeit +# Bildformate im Überblick -**USB-C ist ein Steckertyp, kein Protokoll!** - -Ein USB-C-Kabel kann sein: -- USB 2.0 (480 Mbit/s) -- USB 3.2 (bis 20 Gbit/s) -- USB4 (40 Gbit/s) -- Thunderbolt 3/4 (40 Gbit/s) - -**Am Stecker nicht erkennbar.** -→ Kabel-Spezifikation prüfen! +| Format | Typ | Loss | Transparenz | Animation | Stärke | +|--------|-----|------|------------|-----------|--------| +| **JPEG** | Raster | Lossy | ✗ | ✗ | Fotos | +| **PNG** | Raster | Lossless | ✓ | ✗ | Logos, Screenshots | +| **GIF** | Raster | Lossless | 1-bit | ✓ | Memes, Sticker | +| **WebP** | Raster | beides | ✓ | ✓ | Modern Web | +| **AVIF** | Raster | beides | ✓ | ✓ | Höchste Qualität bei kleinster Datei | +| **SVG** | Vektor | Lossless | ✓ | ✓ (mit JS/CSS) | Logos, Icons | --- -# Thunderbolt + -**Thunderbolt 3/4 (2015/2020):** -- 40 Gbit/s -- PCIe über Kabel (externe GPUs möglich) -- DisplayPort integriert -- USB-C-Stecker +# Wann welches Bildformat? -**Vorteile:** -- Sehr schnell -- Vielseitig (Daten, Video, Strom) - -**Nachteile:** -- Teure Kabel -- Nicht alle USB-C-Ports sind Thunderbolt +| Anwendung | Format | Warum | +|-----------|--------|-------| +| Foto im Web (Insta, News) | **JPEG** oder **WebP** | klein, Foto-optimiert | +| Foto-Archiv (RAW) | **RAW**, **TIFF**, **DNG** | nichts verlieren | +| Logo, Icon (skalierbar) | **SVG** | wird neu berechnet | +| Logo als Raster | **PNG** | Transparenz + scharfe Kanten | +| Screenshot mit Text | **PNG** | scharfe Buchstaben | +| Animiertes Sticker | **GIF** oder **WebP** | beide animierbar | +| Foto in höchster Modern-Qualität | **AVIF** oder **WebP** | bessere Kompression als JPEG | --- -# Video-Schnittstellen +# Patent-Politik — warum WebP, nicht JPEG XL? -| Schnittstelle | Max. Auflösung | Features | -|---------------|---------------:|----------| -| HDMI 2.0 | 4K/60Hz | ARC, CEC | -| HDMI 2.1 | 8K/60Hz, 4K/120Hz | VRR, eARC | -| DisplayPort 1.4 | 8K/60Hz | Daisy-Chain | -| DisplayPort 2.0 | 16K/60Hz | Mehr Bandbreite | +**WebP** (Google, 2010): lizenzfrei. Chrome supportet von Anfang an. Heute überall. -**HDMI:** Consumer-Geräte (TV, Konsolen) -**DisplayPort:** Computer, Monitore +**JPEG XL** (2021): technisch überlegen — bessere Kompression, lossless+lossy in einem Format, JPEG-kompatibel. Sollte JPEG ablösen. + +**Google entfernte Chrome-Support für JPEG XL im Februar 2023.** Begründung: „nicht genug ökosystem-traction". Inoffiziell: WebP ist Google's eigenes Format. + +→ **Patent-Politik schlägt technische Überlegenheit.** Wer den Browser kontrolliert, kontrolliert das Format. --- -# Netzwerk + -**Ethernet:** -| Standard | Geschwindigkeit | -|----------|----------------:| -| Fast Ethernet | 100 Mbit/s | -| Gigabit | 1 Gbit/s | -| 2.5 Gigabit | 2,5 Gbit/s | -| 10 Gigabit | 10 Gbit/s | - -**WiFi:** -| Generation | Standard | Geschwindigkeit | -|------------|----------|----------------:| -| WiFi 5 | 802.11ac | ~1,3 Gbit/s | -| WiFi 6 | 802.11ax | ~9,6 Gbit/s | -| WiFi 7 | 802.11be | ~46 Gbit/s | +# Sub-Sektion B: Audio --- -# Welche Schnittstelle für was? +# Sampling + Bittiefe — Recap aus Kap 1 -| Anwendung | Empfehlung | -|-----------|------------| -| Externe SSD | USB 3.2 Gen 2 oder Thunderbolt | -| USB-Stick | USB 3.0 reicht | -| Monitor | DisplayPort oder HDMI 2.0+ | -| NAS im Heimnetz | Gigabit Ethernet | -| Backup-Platte | USB 3.0 | -| Video-Editing extern | Thunderbolt | +**Sampling Rate** (Hz): wie oft messen wir pro Sekunde. +**Bittiefe** (bit): wie fein jede Messung. +**Datenrate** = Sample Rate × Bittiefe × Kanäle. + +**CD-Audio:** 44,1 kHz × 16 bit × 2 = **1,4 Mbit/s** → ~10 MB/Min. + +**Wir wollen:** ~1 MB/Min (10× kleiner). *Wie?* -NVMe-SSD über USB 2.0? -Verschwendung, USB ist der Flaschenhals. +--- + + + + +![bg fit](./assets/demos/psychoakustik-grafik.png) + + + +--- + +# Bitrate — der Qualitäts-Knopf + +| Bitrate | Anwendung | Hörbar? | +|---------|-----------|---------| +| **64 kbit/s** | Sprachnachricht WhatsApp | dumpf, hörbar schlechter | +| **128 kbit/s** | YouTube-Audio, frühe MP3s | mittel, viele hören Unterschied | +| **192 kbit/s** | Spotify Free | gut für Alltag | +| **320 kbit/s** | Spotify Premium „sehr hoch" | praktisch CD-Qualität | +| **1 411 kbit/s** | CD (unkomprimiert) | Referenz | + +**Faustregel:** je höher die Bitrate, desto mehr Detail bleibt erhalten — *aber Diminishing Returns ab ~256 kbit/s.* + + + +--- + +# Audio-Format-Landschaft + +| Format | Loss | Anwendung | Bitrate | +|--------|------|-----------|---------| +| **WAV** | Lossless | Studio-Master, Wave-Editor | 1.411 kbit/s (CD) | +| **FLAC** | Lossless | Audiophile, Archiv | ~700 kbit/s (CD-Kompression) | +| **MP3** | Lossy | Universalformat, älter | 128-320 kbit/s | +| **AAC** | Lossy | Apple, YouTube, modern | 128-256 kbit/s | +| **OGG / Vorbis** | Lossy | Open-Source, Spotify (alt) | 128-320 kbit/s | +| **Opus** | Lossy | WhatsApp Call, Zoom | 6-510 kbit/s | + + + +--- + + + +# Audio-Format-Wahl + +| Anwendung | Format | Warum | +|-----------|--------|-------| +| Spotify-Stream | **AAC** oder **MP3 192+** | Kompression, breite Unterstützung | +| Studio-Master | **WAV** oder **FLAC** | Bit-genau erhalten | +| Sprachnachricht | **Opus** oder **AAC-LD** | für Sprache optimiert, niedrige Bitrate | +| Podcast-Distribution | **MP3 128 kbit/s** | universelle Unterstützung | +| HiFi-Audiophile | **FLAC** | lossless, kleiner als WAV | +| Archiv eigener Aufnahmen | **FLAC** oder **WAV** | nichts verlieren | + + --- -# Hands-On: Eigene Speicher analysieren +# Selbstlernen — Spotify-Bitrate live -**Aufgabe (30 Min):** +Auf eurem Handy: -1. Welche Laufwerke habt ihr? (SSD, HDD, extern) -2. Welches Dateisystem nutzt ihr? -3. Wie ist eure Backup-Situation? -4. Welche Schnittstellen nutzt ihr? +1. Spotify Premium-Setting auf **Niedrig (24 kbit/s)** umstellen +2. Lieblings-Track mit **Kopfhörer** anhören. Auf Höhen achten. +3. Auf **Sehr hoch (320 kbit/s)** umstellen +4. Gleicher Track. Vergleichen. -**Tools:** -- Windows: Datenträgerverwaltung -- macOS: Festplattendienstprogramm -- Linux: `lsblk`, `df -h` +**Was fällt auf?** Welche Frequenzen verschwinden zuerst? --- -# Fragen & Diskussion +# Sub-Sektion C: Video -**Kontakt:** lb-czechowski@hdm-stuttgart.de -**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/) + --- -# Lizenz & Attribution +# Pixel × Pixel × Hz = Datenflut -Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)** +**Roh-Video 4K @ 60 fps:** -- Erlaubt Teilen & Anpassen mit Namensnennung -- Adaptionen müssen unter gleicher Lizenz geteilt werden +``` +3 840 × 2 160 Pixel × 3 Byte × 60 fps = 1,49 GB/s +``` -Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) +**Pro Minute:** ~90 GB. *Pro Stunde:* ~5,3 TB. +Eine 1-TB-SSD wäre nach **~11 Minuten** voll. + +→ **Ohne Kompression ist Streaming unmöglich.** + + + +--- + + + +# Container ≠ Codec + +![bg right:40% contain](./assets/container-codec-diagram.png) + +**Container** = die *Verpackung*: hält Video-Spur, Audio-Spur, Untertitel, Metadaten zusammen. +*Beispiele:* MP4, MKV, WebM, AVI + +**Codec** = der *Komprimierer*: wie wird Bild/Audio gespeichert? +*Beispiele:* H.264, H.265, AV1, VP9 (Video) · AAC, MP3, Opus (Audio) + +**Eine `.mp4`-Datei kann verschiedene Codecs enthalten.** + + + +--- + +# Was ist in einem Container? + +``` +MP4-Container +├── Video-Spur (H.264, codec: avc1) +├── Audio-Spur (AAC, codec: mp4a) +├── Untertitel-Spur (TTML, optional) +└── Metadaten (Titel, Erstellungsdatum, Bitrate, GOP-Struktur, ...) +``` + +Container regelt: +- **Sync** zwischen Spuren (Audio passt zum Bild) +- **Seeking** (Springen im Video) +- **Streaming-Sicherheit** (Header früh genug) + + + +--- + +# Inter-Frame-Kompression — die zentrale Idee + +![bg right:42% contain](./assets/iframe-pframe-diagram.png) + +Aufeinanderfolgende Frames sehen sich **sehr ähnlich** (Kamera bewegt sich kaum, Person redet — Hintergrund bleibt fast gleich). + +**Statt jedes Frame komplett zu speichern**, speichere nur die *Differenz* zum vorigen. + +Drei Frame-Typen: +- **I-Frame** (Intra): ganzes Bild als JPEG-ähnliches Standalone +- **P-Frame** (Predicted): Differenz zum vorigen Frame +- **B-Frame** (Bidirectional): Differenz zu vorigem UND nächstem Frame + + + +--- + + + +# I, P, B — Frame-Typen + +| Typ | Vollname | Was drin | Größe | +|-----|----------|----------|-------| +| **I** | Intra-coded | Komplettes Bild (wie JPEG) | groß | +| **P** | Predicted | „Was hat sich seit voriges I/P geändert" | mittel | +| **B** | Bidirectional | „Was zwischen vorigem und nächstem I/P" | klein | + +Typische GOP: `I B B P B B P B B P B B I ...` (alle 1–3 Sekunden ein I-Frame). + + + +--- + +# Motion Compensation + +Ein Block aus dem vorigen Frame wird **verschoben** — nicht neu kodiert. + +P-Frame speichert: +1. Bewegungsvektor (z.B. „Block A: +5 Pixel rechts, +2 Pixel runter") +2. Differenz zum verschobenen Block + +**Resultat:** Auto-Fahrt vor stehender Kamera → P-Frames mini-klein. + + + +--- + + + +# Die Codec-Landschaft + + + +--- + +# H.264 / AVC — der Workhorse + +**2003** • dominierender Video-Codec seit Smartphone-Ära. + +Wo überall verwendet: +- YouTube (Hauptcodec) +- Zoom, Teams, Meet +- Netflix (HD-Streams) +- Smartphones (alle iOS-Aufnahmen, viele Android) + +Patente: MPEG-LA-Pool. Lizenzkosten **moderat**, viele Hersteller decken die Kosten in der Hardware ab. + + + +--- + +# H.265 / HEVC — Patent-Chaos + +**2013** • technisch ~50 % effizienter als H.264. + +**Aber:** drei separate Patent-Pools, intransparente Lizenzkosten. + +Resultat: +- **Apple** macht alles in H.265 (HEIC-Fotos, iOS-Video) — bezahlt Lizenzen +- **YouTube, Netflix** verzichten weitgehend — zu teuer + risikoreich +- **Industrie-Reaktion:** Allianz für Open Media (AOMedia) gegründet, baut AV1 + + + +--- + +# VP9 + AV1 — die offene Antwort + +**VP9** (Google, 2013): lizenzfrei, ähnlich effizient wie H.265. +- YouTube nutzt es für 4K-Streams (Chrome, Firefox). + +**AV1** (Alliance for Open Media, 2018): Konsortium aus Google, Mozilla, Netflix, Amazon, Apple, ARM, Microsoft, Cisco, Intel, NVIDIA... +- **Lizenzfrei.** **30 % effizienter als H.265.** +- Hardware-Decoder seit ~2021 verfügbar (M1, Snapdragon 888+). +- YouTube, Netflix, Twitch streamen schon AV1. + + + +--- + + + +# Patent vs. Open — warum AV1? + +| Codec | Effizienz | Patent | Adoption (2026) | +|-------|-----------|--------|-----------------| +| H.264 | Baseline | Lizenz (MPEG-LA) | ~80 % aller Videos | +| H.265 | +50 % | 3 Patent-Pools, chaotisch | nur Apple | +| VP9 | ~H.265 | lizenzfrei (Google) | YouTube 4K | +| **AV1** | **+30 % über H.265** | **lizenzfrei (Allianz)** | **YouTube, Netflix, Twitch** | + +**Die Lektion:** technisch beste Lösung gewinnt nicht. *Lizenz-klare* beste Lösung gewinnt. + + + +--- + +# 4K-Stream vs. Heim-Bandbreite + +| Auflösung | Bitrate (H.265/AV1) | Heim-Bandbreite nötig | +|-----------|---------------------|----------------------| +| 480p (SD) | 1 Mbit/s | jeder Anschluss | +| 720p (HD) | 3 Mbit/s | DSL ausreichend | +| 1080p (Full HD) | 8 Mbit/s | DSL-25 + | +| **4K (UHD)** | **25 Mbit/s** | **Glasfaser oder Kabel** | +| 4K HDR | 35 Mbit/s | Kabel-Premium | +| 8K | ~100 Mbit/s | Glasfaser-200 | + +**Spotify-Audio dagegen:** Highest = 320 kbit/s = 0,3 Mbit/s. *80× weniger als ein 4K-Stream.* + + + +--- + + + +# Selbstlernen — drei Übungen + +**Bild:** +[Squoosh.app](https://squoosh.app) öffnen. Eigenes Foto in JPEG vs WebP vs AVIF konvertieren. Größe + Qualität vergleichen. + +**Audio:** +Spotify Premium-Bitrate von 24 auf 320 kbit/s wechseln. Lieblings-Track anhören. Was fällt auf? + +**Video:** +`mediainfo` (CLI oder GUI) auf eine eigene Video-Datei. Welcher Container? Welcher Codec? Welche Bitrate? + + + +--- + +# Zusammenfassung + +**Drei Modalitäten, ein Prinzip:** Wahrnehmungs-Lücken als Hebel. + +| | **Bild** | **Audio** | **Video** | +|--|----------|-----------|-----------| +| Lossy-Trick | Chroma-Subsampling + DCT-Quantisierung | Maskierung + Hörschwelle | Inter-Frame + JPEG-pro-Frame | +| Standardformat | JPEG | MP3/AAC | H.264 / AV1 | +| Reduktion | ~10× | ~10× | ~100× | +| Format-Politik | WebP > JPEG XL (Google) | MP3-Patent → AAC | H.265-Chaos → AV1 | + +**In Kap 4** schauen wir uns an, *wie* diese Daten zu eurem Gerät kommen — und welche Schnittstelle dabei der Engpass ist. + +