diff --git a/slides/223015b/02-bild-audio-video.md b/slides/223015b/02-bild-audio-video.md index f132c96..0756283 100644 --- a/slides/223015b/02-bild-audio-video.md +++ b/slides/223015b/02-bild-audio-video.md @@ -84,886 +84,580 @@ Hochschule der Medien Stuttgart [https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/) +--- + +![bg fit](./assets/qrcode-1.svg) + +--- + + + +# Teil 1: Einführung +## Grundlagen, Text & Audio + +--- + + + +# Das Problem der Datengröße + +--- + +# Ein konkretes Beispiel + +**Eine Minute Musik in CD-Qualität:** + +44.100 Messungen/Sekunde +× 16 Bit pro Messung +× 2 Kanäle (Stereo) +× 60 Sekunden + += **10,6 MB pro Minute** + --- - - +# Das Problem skaliert -![bg fit](./assets/qr/slides-223015b.png) +| Inhalt | Unkomprimiert | +|--------|-------------:| +| 1 Song (4 Min) | ~42 MB | +| 1 Album (60 Min) | ~635 MB | +| 10.000 Songs | ~420 GB | + +**Kontext 1990er:** +- Festplatte: 100-500 MB +- Modem: 56 kbit/s → 1 Song dauert Stunden + +--- + +# Video eskaliert + +**Eine Minute 4K-Video (unkomprimiert):** + +3840 × 2160 Pixel +× 3 Byte pro Pixel (RGB) +× 30 Bilder pro Sekunde +× 60 Sekunden + += **~45 GB pro Minute** + +Ein 2-Stunden-Film: über **5 Terabyte** + + + +--- + +# Kompressionsraten in der Praxis + +| Medium | Unkomprimiert | Komprimiert | Faktor | +|--------|-------------:|------------:|-------:| +| 1 Song (4 Min) | ~42 MB | ~4 MB (MP3 320) | ~10× | +| 1 Foto (12 MP) | ~36 MB | ~3 MB (JPEG) | ~12× | +| 1 Min 4K-Video | ~45 GB | ~375 MB (H.264) | ~120× | + + --- -# Teil 2: Bild- & Videoformate +# Zwei Philosophien der Kompression --- -# Warum verschiedene Dateiformate? +# Verlustfreie Kompression (Lossless) -**Ein Dateiformat definiert:** -- Ob und wie Daten komprimiert werden -- Welche Metadaten enthalten sind -- Wie Daten *codiert* und *decodiert* werden (*Co·dec*) +**Prinzip:** Redundanz entfernen -| Ziel | Bild | Audio | Dokument | -|------|------|-------|----------| -| Kleine Dateien | JPEG | MP3 | — | -| Perfekte Qualität | PNG, RAW | FLAC | PDF | -| Animation/Video | GIF | — | — | -| Skalierbarkeit | SVG | — | PDF | - - - ---- - - - - -![bg](./assets/photo-comparison.png) - - - ---- - - - -# Digitale Bilder -## Raster- und Vektorgrafiken - - - ---- - -# Was ist ein digitales Bild? - -Ein digitales Bild ist ein Raster aus Farbpunkten (Pixel). -Jeder Pixel speichert einen RGB-Farbwert (3 Bytes). - -**Beispiel: Full HD (1920×1080)** -= 2.073.600 Pixel × 3 Bytes = **6,2 MB** - - - ---- - - - - - - -# Rastergrafiken - -**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array) - -**Speicherbedarf (unkomprimiert):** -Breite × Höhe × Farbtiefe (in Bytes) - -**Beispiele:** JPEG, PNG, WebP - -| Bits (Farbtiefe) | Farben | Anwendung | -|-----:|-------:|-----------| -| 1 | 2 | Schwarz/Weiß (Fax) | -| 8 | 256 | Graustufen, GIF | -| 24 | 16,7 Mio. | True Color (Standard) | -| 32 | 16,7 Mio. + Alpha | Transparenz | - - - ---- - -# Das Problem der Skalierung - -**Vergrößern:** -Fehlende Pixel müssen erfunden werden (Interpolation) - -**Verkleinern:** -Pixel müssen zusammengefasst werden - -**Interpolationsverfahren:** -- Nearest Neighbor: Schnell, pixelig -- Bilinear: Glättet, Standardverfahren -- Bicubic: Hohe Qualität, rechenintensiv -- Lanczos: Beste Qualität, mathematisch komplex - - - ---- - - - - - - -# Vektorgrafiken - -**Speicherung als geometrische Primitive:** -- Pfade (Bézierkurven mit Kontrollpunkten) -- Grundformen (Rechteck, Ellipse, Polygon) -- Text (Glyphen als Outlines) - -**SVG-Beispiel:** -```xml - +**Beispiel Lauflängenkodierung:** +``` +Original: AAAAABBBCCCCCCCC (16 Zeichen) +Komprimiert: 5A3B8C (6 Zeichen) ``` -SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht. +→ 62% kleiner, 100% wiederherstellbar + +**Anwendung:** ZIP, PNG, FLAC, Programmcode --- -# Raster- und Vektorgrafiken +# Verlustbehaftete Kompression (Lossy) -| | Raster | Vektor | +**Prinzip:** Irrelevanz entfernen + +**Die Frage:** Was nimmt ein Mensch nicht wahr? + +- Das Ohr hört nicht alle Frequenzen gleich gut +- Das Auge sieht nicht alle Farbnuancen +- Laute Töne überdecken leise Töne + +→ Warum Daten speichern, die niemand wahrnimmt? + + + +--- + + + + + + +# Verlustfrei vs. Verlustbehaftet + +| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) | |---|---|---| -| **Optimal für** | Fotos, komplexe Bilder | Logos, Icons, Illustrationen | -| **Skalierung** | Qualitätsverlust | Verlustfrei | -| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität | -| **Formate** | JPEG, PNG, WebP | SVG, PDF, AI | -| **Bearbeitung** | Pixel-basiert | Objekt-basiert | +| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen | +| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) | +| **Reduktion** | 30-50% | 80-99% | +| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 | + +**Faustregel:** +- Medien für Endnutzer → Lossy oft akzeptabel +- Quellmaterial, Code, Archive → Lossless nötig --- + + + +![bg fit](./assets/compression-types.png) + + + +--- + + -# Menschliche Wahrnehmung -## Psychovisuelle Kompression - - - ---- - - - - - - -# Die Schwächen des Auges - -**Menschen sehen:** -* Helligkeit besser als Farbe -* Große Flächen besser als feine Details -* Niedrige Frequenzen besser als hohe - -**JPEG nutzt das aus:** -* Farbauflösung reduzieren (Helligkeit behalten) -* Glatte Flächen effizient speichern -* Hohe Frequenzen (feine Details) verwerfen - - +# Die Grundbausteine +## Bits, Bytes und ihre Darstellung --- -![bg contain 50%](./assets/Felis_silvestris_silvestris_small_gradual_decrease_of_quality_-_JPEG_compression.jpg) +![bg](./assets/lightbulb-onoff.png) --- -![bg contain right:34%](./assets/Posterization_example.jpg) +# Das Bit -# Grenzen der Kompression: JPEG-Artefakte +**Kleinste Informationseinheit** -**Bei starker Kompression sichtbar:** - -* **Posterization:** - Farbverläufe werden stufig - -* **Blocking:** - 8×8-Blöcke werden sichtbar - -* **Ringing:** - "Geister" an scharfen Kanten +- **0 oder 1** +- AN oder AUS +- Strom fließt oder nicht --- -# JPEG-Qualität in der Praxis - -| Quality | Typische Größe (12 MP) | Artefakte | -|--------:|----------------------:|-----------| -| 100 | 2–3 MB | Minimal | -| 85–90 | 200–400 KB | Kaum sichtbar | -| 60 | ~100 KB | Bei genauem Hinsehen | -| 30 | ~50 KB | Deutlich sichtbar | - -**Sweet Spot: 85–90** -~10× Kompression, für Menschen kaum unterscheidbar +# Das Byte --- - +# Das Byte -# JPEG-Kompression -## Sechs Schritte im Detail - - - ---- - - - - - - -![bg right:20%](./assets/Barn-yuv.png) - -# JPEG Schritt 1: Farbraumkonversion - -**RGB → Y'CbCr** - -- **Y** = Helligkeit (Luminanz) -- **Cb** = Blau-Gelb-Anteil (Chrominanz) -- **Cr** = Rot-Grün-Anteil (Chrominanz) - -**Warum?** -Y (Helligkeit) behält volle Auflösung -Cb/Cr (Farbe) kann reduziert werden - - - ---- - -# JPEG Schritt 2: Chroma Subsampling - -**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block): -- **J** = Referenzbreite (immer 4) -- **a** = Farbsamples in Zeile 1 -- **b** = Farbsamples in Zeile 2 - -| Schema | Bedeutung | Farbdaten | -|--------|-----------|-----------| -| 4:4:4 | Volle Farbauflösung | 100% | -| 4:2:2 | Halbe horizontale Auflösung | 50% | -| 4:2:0 | Viertel Auflösung (2×2 teilt Farbe) | 25% | - -**4:2:0 ist JPEG-Standard** - - - ---- - - - - -![bg contain 70%](./assets/Common_chroma_subsampling_ratios_YCbCr_CORRECTED.svg.png) - - - ---- - -# JPEG Schritt 3: Block-Aufteilung - -**Das Bild wird in 8×8-Pixel-Blöcke zerlegt** - -Jeder Block wird unabhängig verarbeitet. -Bei 1920×1080: 240 × 135 = **32.400 Blöcke** - -**Level Shift:** -Pixelwerte um −128 verschieben -- Vorher: 0 bis 255 -- Nachher: −128 bis +127 - -**Warum?** -DCT arbeitet besser mit Werten um Null - - - ---- - -# JPEG Schritt 4: DCT (Discrete Cosine Transform) - -**Jeder 8×8-Block wird transformiert:** -64 Pixelwerte → 64 Frequenzkoeffizienten - -**Die 64 Koeffizienten:** - -| Position | Name | Bedeutung | -|----------|------|-----------| -| (0,0) | DC | Durchschnittshelligkeit | -| Rest | AC | Helligkeitsänderungen | - -**Energy Compaction:** -90% der Information in den ersten 10–15 Koeffizienten -DCT selbst ist **verlustfrei** und reversibel! - - - ---- - -# JPEG Schritt 5: Quantisierung - -**Hier passiert der Datenverlust!** - -Die DCT hat sortiert – jetzt wird aufgeräumt: -- Wichtige Werte (niedrige Frequenz) → präzise behalten -- Unwichtige Werte (hohe Frequenz) → vergröbern oder Null setzen - -**Ergebnis:** -Von 64 Werten pro Block bleiben oft nur 5–15 übrig -Rest wird zu Nullen → extrem gut komprimierbar - -**Quality-Einstellung:** -Hoch = mehr Werte behalten = größere Datei -Niedrig = mehr Nullen = kleinere Datei, mehr Artefakte - - - ---- - -![bg fit](./assets/quantized-image-8-colors.jpg) - - - - - - ---- - -# JPEG Schritt 5b: Zigzag & RLE - -**Nach Quantisierung:** Viele Nullen (v.a. bei hohen Frequenzen) - -**Zigzag-Scan:** Matrix diagonal durchlaufen -→ Nullen sammeln sich am Ende +**1 Byte = 8 Bits** ``` -┌────────────────┐ -│ 1 2 6 7 ... │ Niedrig → Hoch -│ 3 5 8 ... │ (diagonal) -│ 4 9 ... │ -└────────────────┘ -``` - -**RLE (Run-Length Encoding):** -`0 0 0 0 0 0 0 0` → `(8, 0)` = "acht Nullen" - - - ---- - - - - - - -# JPEG Schritt 6: Huffman-Coding - -**Verlustfreie Kompression der Restwerte** - -**Idee:** Variable Bitlänge statt fester 8 Bit -Häufige Werte → kurze Codes - -| Zeichen | Häufigkeit | Code | -|---------|------------|------| -| e | 40% | `0` (1 Bit) | -| a | 25% | `10` (2 Bit) | -| i | 20% | `110` (3 Bit) | -| o | 10% | `1110` (4 Bit) | -| u | 5% | `1111` (4 Bit) | - - - - - - - - - - - ---- - - - - -![bg](./assets/jpeg-artifacts.png) - - - ---- - - - -# Andere Bildformate -## PNG, GIF, WebP, AVIF - -15:33 Uhr weiter - - - ---- - -# PNG: Verlustfrei mit Transparenz - -**PNG = Portable Network Graphics (1996)** - -**Entstehung:** GIF-Patent-Streit → Community entwickelt Alternative - -**Features:** -- Verlustfrei (Lossless) -- Alpha-Transparenz (8-Bit, 256 Stufen) -- Millionen Farben (24/48 Bit) -- Patent-frei - -**Ideal für:** Grafiken, Screenshots, Text, Logos - - - ---- - -# GIF: Der Meme-Veteran - -**GIF = Graphics Interchange Format (1987)** - -**Features:** -- 256 Farben (8-Bit Palette) -- Verlustfrei (innerhalb der Palette) -- Animationen - -**Das Patent-Drama (1994):** -Unisys fordert Lizenzgebühren für LZW-Kompression -→ "Burn All GIFs!"-Kampagne -→ PNG als Alternative - -**Heute:** Kulturell unsterblich (Memes, Reaktionen) - - - ---- - - - - - - -# WebP & AVIF: Moderne Alternativen - -**WebP (Google, 2010):** -- Lossy und Lossless -- Transparenz und Animationen -- 25–35% kleiner als JPEG - -**AVIF (2019):** -- Basiert auf AV1-Video-Codec -- 50% kleiner als JPEG -- HDR-Unterstützung, patent-frei - -**Browser-Support 2025:** WebP universell, AVIF wächst - - - ---- - -# Formatwahl in der Praxis - -| Anwendung | Format | -|-----------|--------| -| Fotos fürs Web | JPEG (85), WebP | -| Screenshots | PNG | -| Logos, Icons | SVG, PNG | -| Animationen | GIF, WebP, APNG | -| Archivierung | TIFF, PNG, RAW | -| Social Media | Was die Plattform erlaubt | - - - ---- - - - - -![bg](./assets/instagram-quality-loss.png) - - - ---- - -# Warum Instagram eure Fotos "ruiniert" - -**Die Upload-Pipeline:** -1. Euer Foto: 12 MP, 8 MB -2. Instagram skaliert: max. 1080px Breite -3. Re-Kompression: JPEG Quality ~75 -4. Ergebnis: 200–400 KB - -**Warum?** -- Speicherkosten (Milliarden Fotos) -- Ladezeiten (Mobile-First) -- Bandbreite (günstiger für alle) - - - ---- - - - -# Video -## Bilder + Zeit + Audio - - - ---- - -# Das Größenproblem bei Video - -**4K-Video (3840×2160), unkomprimiert:** - -3840 × 2160 × 3 Bytes = **24,8 MB pro Frame** - -× 30 fps = **744 MB/Sekunde** - -× 60 Sekunden = **44,6 GB pro Minute** - -**Ein 2-Stunden-Film: über 5 Terabyte** - - - ---- - - - - - - -# Container und Codec - -**Container = Dateiformat (z.B. MP4)** -Die "Box", die verschiedene Streams zusammenpackt: -- Video-Stream -- Audio-Stream(s) -- Untertitel -- Metadaten - -**Codec = Kompressionsalgorithmus (z.B. H.264)** -Bestimmt, WIE komprimiert wird - - - ---- - -# Gängige Container - -| Container | Verwendung | -|-----------|------------| -| **MP4** (.mp4) | Web, Streaming, universell | -| **MKV** (.mkv) | Archiv, viele Streams, offen | -| **MOV** (.mov) | Apple-Ökosystem | -| **WebM** (.webm) | Web, nur VP9/AV1 + Opus | -| **AVI** (.avi) | Legacy, veraltet | - - - ---- - -# Video-Codecs im Überblick - -| Codec | Jahr | Status | -|-------|------|--------| -| **H.264/AVC** | 2003 | Universal, überall | -| **H.265/HEVC** | 2013 | Effizienter, Patent-Chaos | -| **VP9** | 2013 | YouTube, patent-frei | -| **AV1** | 2018 | Zukunft, patent-frei | - - - ---- - -# Container + Codec = Video - -``` -┌─────────────────────────────┐ -│ Container (z.B. MP4) │ -│ ┌────────────────────────┐ │ -│ │ Video-Stream (H.264) │ │ -│ ├────────────────────────┤ │ -│ │ Audio-Stream (AAC) │ │ -│ ├────────────────────────┤ │ -│ │ Untertitel (SRT) │ │ -│ ├────────────────────────┤ │ -│ │ Metadaten │ │ -│ └────────────────────────┘ │ -└─────────────────────────────┘ +0 1 0 0 1 1 0 1 ``` + +--- + +# Das Byte + +**1 Byte = 8 Bits** + +``` +0 1 0 0 1 1 0 1 +``` + +2⁸ = **256 Möglichkeiten** (0-255) + + + +--- + + + + +»256 Shades of Gray« + +![bg fit](./assets/grayscale-gradient.png) + + + +--- + +# Was kann man mit 256 Zuständen machen? + +* **256 Zeichen** (Buchstaben, Zahlen, Symbole) +* **256 Helligkeit bzw. Luminanz** (0 = Schwarz/Dunkel, 255 = Weiß/Hell) +* **256 Lautstärkestufen** +* **Zahlen 0-255** (oder -128 bis +127) + + + +--- + + + + +![bg fit](./assets/rgb-color-model.png) + + + +--- + + + + +![bg fit](./assets/rgb-color-model-with-title.png) + + + +--- + +![bg right:50%](./assets/addaptive-substractive-colors.jpg) + +# Farben: RGB-Modell + +**1 Pixel = 3 Bytes** + +- **Rot:** 0-255 +- **Grün:** 0-255 +- **Blau:** 0-255 + +**Beispiele:** +`FF 00 00` = Rot +`00 FF 00` = Grün +`00 00 FF` = Blau +`00 00 00` = Schwarz +`FF FF FF` = Weiß + + + +--- + + + + +![bg fit](./assets/hex-dec-lookup-table.png) + +--- + +# Das Problem: Sprachen + +**Die Welt hat mehr als 256 Zeichen!** + +- Englisches Alphabet: 52 (A-Z, a-z) +- + Ziffern: 10 (0-9) +- + Sonderzeichen: ~30 + +**≈ 90 Zeichen → passt in 1 Byte** + +**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀 + +→ **1 Byte reicht nicht!** + + + +--- + +# Unicode: Ein Standard für alle (8 Bit) + +**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) +- **Zeichen 0-127: identisch mit ASCII** (Abwärtskompatibilität!) +- 1.112.064 gültige Zeichen +- Umlaute: 2 Bytes · CJK: 3 Bytes · Emoji: 4 Bytes + + + +--- + +# Beispiel: Bytes zählen + +**Text:** `"Hello·🌸·こんにちは·(Kon-ni-chi-wa)"` + +| Zeichen | Bytes | +|---------|-------| +| `Hello·` | 6 × 1 = **6 Bytes** (ASCII) | +| `🌸` | **4 Bytes** (Emoji) | +| `·` | **1 Byte** | +| `こんにちは` | 5 × 3 = **15 Bytes** (Hiragana) | +| `·(Kon-ni-chi-wa)` | **16 Bytes** (ASCII) | + +**Gesamt: 42 Bytes** für 29 sichtbare Zeichen + + --- -# Video-Kompression -## Raum und Zeit nutzen +# Hexadezimal +## Die Sprache der Datei-Analyse + +--- + +# Hexadezimal: Lesbarkeit + +**Binär ist unleserlich:** +`01010000 01001110 01000111` + +**Hexadezimal (Base 16):** +`50 4E 47` (= "PNG" in ASCII) + +**Jede Hex-Ziffer = 4 Bits (ein "Nibble")** +0-9, A-F (10=A, 11=B, ..., 15=F) + +**ASCII Tabelle (0-127):** +[https://www.asciitable.com](https://www.asciitable.com) + +--- + + + + + +# ASCII +## One *Zeichensatz* to rule them all + + --- @@ -971,104 +665,98 @@ KLAUSURRELEVANT: -![bg fit](./assets/ipb-compression-canon.jpg) + +![bg fit](./assets/ascii-table-colored.png) --- -# Drei Kompressionsprinzipien +![bg right:40%](./assets/matrix-code.png) -**1. Spatial Compression (Intra-Frame)** -Jedes Bild einzeln komprimieren (wie JPEG) +# WTF!? -**2. Temporal Compression (Inter-Frame)** -Nur Änderungen zwischen Bildern speichern +``` +89 50 4E 47 0D 0A 1A 0A +00 00 00 0D 49 48 44 52 +00 00 01 90 00 00 01 2C +``` -**3. Motion Compensation** -Bewegung beschreiben statt Pixel kopieren +--- + +![bg right:30%](./assets/matrix-code.png) + +# What the HEX-Code + +``` +89 50 4E 47 ... +``` + +| Binär | Hex | Dez | ASCII | +|-------|-----|-----|-------| +| `1000 1001` | `89` | 137 | ✗ (> 127) | +| `0101 0000` | `50` | 80 | **P** | +| `0100 1110` | `4E` | 78 | **N** | +| `0100 0111` | `47` | 71 | **G** | + +→ **PNG**-Signatur! (Das `89` markiert: "Ich bin binär, kein Text!") --- -# Spatial Compression (Intra-Frame) + + + -**Jedes Bild einzeln komprimieren – wie JPEG** - -Analysiert Redundanz *innerhalb* eines Frames: -- DCT (Frequenzanalyse) -- Quantisierung -- Entropie-Coding - -**→ I-Frame (Keyframe)** -Vollständiges Bild, unabhängig dekodierbar +![bg fit](./assets/hex-code-hidden.png) --- -# Temporal Compression (Inter-Frame) + + + -**Nur Änderungen zwischen Bildern speichern** - -| Frame-Typ | Referenziert | Typische Größe | -|-----------|--------------|----------------| -| **I-Frame** | Nichts (Keyframe) | 100% | -| **P-Frame** | Vorherige Frames | ~30% | -| **B-Frame** | Vorherige + zukünftige | ~15% | - -**GOP (Group of Pictures):** -I - B - B - P - B - B - P - B - B - I +![bg fit](./assets/hex-code.png) - ---- - -# Motion Compensation - -**Bewegung beschreiben statt Pixel kopieren** - -**Beispiel:** Ein 16×16 Pixel-Block - -Frame 1: Block an Position (100, 200) -Frame 2: Block an Position (120, 200) - -**Statt Block zweimal speichern:** -→ Motion Vector: "verschiebe um (+20, 0)" - - --- @@ -1076,13 +764,45 @@ Frame 2: Block an Position (120, 200) -![bg fit](./assets/ipb-compression-canon.jpg) +![bg fit](./assets/8bit-P-character.png) + +--- + +# Magic Numbers + +**Dateityp-Identifikation durch erste Bytes** + +| Format | Magic Number (Hex) | Lesbar? | +|--------|-------------------|---------| +| PNG | `89 50 4E 47` | ✗ P N G | +| JPEG | `FF D8 FF` | ✗ ✗ ✗ | +| PDF | `25 50 44 46` | % P D F ✓ | +| ZIP | `50 4B 03 04` | P K ✗ ✗ | + +**Wichtig:** ASCII = nur 0-127! Werte darüber (z.B. `89` = 137) sind **nicht druckbar** (non-printable). *Hex-Editoren zeigen dafür `.` oder `ÿ` als Platzhalter.* --- @@ -1092,144 +812,776 @@ Frame 2: Block an Position (120, 200) -# H.264 / AVC +# Dateneinheiten -**Advanced Video Coding (2003)** - -**Warum dominant?** -- Exzellente Kompression (~100:1 möglich) -- Hardware-Decoder in jedem Gerät seit ~2010 -- YouTube, Netflix, Blu-ray – alles H.264 - -**Features:** -- Variable Block-Größen (16×16 bis 4×4) -- Deblocking-Filter (reduziert Artefakte) +| Einheit | Bytes | Potenz | Beispiel | +|---------|------:|:------:|----------| +| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels | +| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode | +| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument | +| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD | +| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K | +| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv | +| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag | +| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 | --- -# Das Patent-Problem +# Datenwachstum der Menschheit -**H.264 ist nicht frei** +| Jahr | Datenmenge | Kontext | +|------|------------|---------| +| **100.000 v. Chr.** | 0 | Erste Menschen, nur Sprache | +| **3.000 v. Chr.** | ~wenige KB | Keilschrift, Hieroglyphen | +| **1450** | ~wenige GB | Gutenberg, Buchdruck | +| **1986** | **2,6 EB** | 99% analog (Bücher, Vinyl, VHS) | +| **2007** | **295 EB** | 94% digital | +| **2025** | **181 ZB** | 90% unstrukturiert | -**MPEG-LA (Patent Pool):** -- 2.000+ Patente von ~30 Unternehmen -- Apple, Microsoft, Sony, Panasonic... + + +--- + + + + + + +# Der digitale Wendepunkt + +| Jahr | Analog | Digital | Digital-Anteil | +|------|--------|---------|----------------| +| **1986** | 2,6 EB | 0,02 EB | **1%** | +| **2002** | — | — | **50%** (Wendepunkt) | +| **2007** | 18 EB | 277 EB | **94%** | + +**Perspektive:** +- 1986: "Petabyte" war ein theoretisches Konzept +- 2025: ~181 Zettabyte jährlich produziert + +**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium +(AWS Glacier, Film-Archive, Rechenzentren) + + + +--- + + + + + +![bg fit](./assets/2011-hilbert.png) + + +--- + +# 181 Zettabyte – Was bedeutet das? + +**2025:** Welt erzeugt **181 ZB** pro Jahr + +- **2,5 Quintillionen Bytes** täglich +- **29 Terabyte** pro Sekunde +- **90%** davon: unstrukturiert (Videos, Bilder, Audio) +- **70%** davon: von NutzerInnen generiert + +**Zum Vergleich:** +- 1 ZB = 250 Milliarden DVDs +- 181 ZB = Jeder Mensch erzeugt ~23 TB/Jahr + + + +--- + + + + + + +![bg fit](./assets/growth of big data.png) + +--- + +# AI-generierte Inhalte 2025 + +**Wie viel Content ist heute synthetisch?** + +| Bereich | AI-Anteil | +|---------|-----------| +| **Neue Webseiten** | ~74% enthalten AI-Content | +| **Web-Text gesamt** | ~30-40% AI-generiert | +| **Neue Artikel** | ~52% von AI geschrieben | +| **Social-Media-Bilder** | ~71% AI-generiert | + +**Prognose 2026:** 90% des Online-Contents synthetisch + + + +--- + + + +# Teil 2: Die MP3-Revolution +## Psychoakustik & Audio-Kompression + +--- + + + + +![bg](./assets/cassette-ipod.png) + + + +--- + + + + + + +# Analoge Medien +### Distribution: physisch (Kauf, Verleih, Kopie) + +* **Text** + - Bücher, Zeitungen, Zeitschriften, Lochkarten +* **Bild** + - Fotografie (Negativ, Dia, Polaroid), Mikrofilm +* **Audio:** + - Schallplatte (Vinyl, Schellack), Tonband, Musikkassette +* **Video:** + - Film (35mm, Super 8), VHS, Betamax + +--- + +# Analoge Medien: Vor- und Nachteile + +| Vorteile | Nachteile | +|----------|-----------| +| Kein Abspielgerät nötig (Buch, Foto) | Qualitätsverlust bei jeder Kopie | +| Haptisches Erlebnis | Physischer Verschleiß | +| Unabhängig von Strom/Internet | Begrenzte Haltbarkeit | +| Keine Formatkonvertierung | Platzbedarf bei Lagerung | +| Eindeutiges Original | Aufwendige Durchsuchbarkeit | + + + +--- + +# Von Analog zu Digital: Die Kopier-Revolution + +**Das Problem analoger Kopien:** +Kassette → Kassette → Kassette = immer schlechter + +**Was Digital anders macht:** +- **Identische Kopien** – kein Qualitätsverlust, nie +- **Einfache Massenproduktion** – Copy & Paste +- **Perfekte Archivierung** – Bits verändern sich nicht + +**Daher: "Raubkopien"** +Der Begriff entstand, weil digitale Kopien *tatsächlich identisch* mit dem Original waren – nicht wie bei Kassetten eine schlechtere Version. + +Quelle: [c64-wiki.de/wiki/Raubkopie](https://www.c64-wiki.de/wiki/Raubkopie) + + + +--- + + + + + + +# Digitale Medien +### Distribution: Datenträger (CD, USB), Download, Streaming, P2P + +* **Text** + - E-Book (PDF, EPUB), Dokumente (TXT, DOCX) +* **Bild** + - Digitalfoto (JPEG, PNG, RAW, WebP, GIF) +* **Audio** + - Audiodatei (MP3, FLAC, WAV, AAC, OGG) +* **Video** + - Videodatei (MP4, MKV, AVI, WebM) + +--- + + + + + + +# Digitale Speichermedien + +* **Optische Speicher** + - CD, DVD, Blu-ray +* **Magnetische Speicher** + - Festplatte (HDD), Magnetband (LTO) +* **Flash-Speicher** + - SSD, USB-Stick, SD-Karte +* **Cloud-Speicher** + - Dropbox, Google Drive, iCloud, AWS S3 + +--- + +# Das Speicherproblem der Digitalisierung + + +**Ziel: Analoge Schallwelle möglichst originalgetreu rekonstruieren** + +*CD-Qualität (1982): 44.100 Hz × 16 Bit × 2 Kanäle = 10,584 MB/Minute* + + + +| Inhalt | Größe | Problem (1990er) | +|--------|-------|------------------| +| 1 Song (4 Min) | ~42 MB | Ausreichend Speicher | +| 1 Album (60 Min) | ~635 MB | Gesamte Festplatte | + + + + +--- + + + + +![bg cover](./assets/spectogram-chet-baker.png) + + + +--- + +# Die Abtastrate (Sample Rate) +**Analog → Digital ≙ Kontinuierlich → Diskret** +``` + Analog (Vinyl): Digital (CD): + ~~~~~~~~~~~~~~~ • • • • • • • • + Kontinuierliche 44.100 Messpunkte + Wellenform pro Sekunde +``` +**Nyquist-Theorem:** + +> Um eine Frequenz zu rekonstruieren, braucht man mindestens **2× so viele Samples**. +44.100 Hz ÷ 2 = **22.050 Hz** max. darstellbare Frequenz +(Mensch hört: ~20 Hz bis ~20.000 Hz → passt!) + + + +--- + +# Die Bittiefe (Bit Depth) + +**Wie genau messen wir jeden Punkt?** + +| Bittiefe | Stufen | Dynamikumfang | +|----------|--------|---------------| +| 8 Bit | 256 | ~48 dB | +| 16 Bit (CD) | 65.536 | ~96 dB | +| 24 Bit (Studio) | 16.777.216 | ~144 dB | + +**16 Bit = 2¹⁶ = 65.536 Lautstärkestufen** +(von absoluter Stille bis maximaler Lautstärke) + + + +--- + +# Abtastrate (Sample Rate) × Bittiefe (Bit Depth) + +**Zwei Dimensionen der Digitalisierung:** + +| Dimension | Was bedeutet es? | CD-Qualität | +|-----------|------------------|-------------| +| **Abtastrate** (Sample Rate) | Messungen pro Sekunde (horizontal) | 44.100 Hz | +| **Bittiefe** (Bit Depth) | Genauigkeit pro Messung (vertikal) | 16 Bit | + +**44.100 Hz × 16 Bit** × 2 Kanäle = 10,584 MB/Minute + + + +--- + + + +# Kompression +## Weniger Daten, gleiche(?) Information + +--- + +# Wo liegt der Hebel für Kompression? + +**CD-Qualität:** 44.100 Hz × 16 Bit × 2 Kanäle = **10,6 MB/Min** +**MP3 (128 kbps):** = **~1 MB/Min** (Faktor 10!) + +**Container-Parameter (das Raster):** + +| Parameter | Reduzieren → | Konsequenz | +|-----------|--------------|------------| +| Abtastrate | Weniger Messpunkte/Sek | Max. Frequenz sinkt | +| Bittiefe | Weniger Lautstärkestufen | Mehr Rauschen | +| Kanäle | Mono statt Stereo | Kein Raumklang | + + + +--- + +# Psychoakustik: Der MP3-Trick + +**Inhalt (was durchs Raster geht):** + +| Methode | Reduzieren → | Konsequenz | +|---------|--------------|------------| +| Psychoakustik | Unhörbare Frequenzen | Kaum wahrnehmbar | + +→ **MP3 nutzt hauptsächlich Psychoakustik** +→ Container bleibt ähnlich, Inhalt wird "ausgedünnt" + + + +--- + +# 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 + + + +--- + +![bg right:40%](./assets/karlheinz-brandenburg.jpg) + +# Karlheinz Brandenburg + +**"Vater der MP3"** + +- Diplom-Ingenieur, Universität Erlangen-Nürnberg +- Fraunhofer IIS (Institut für Integrierte Schaltungen) +- Forschung ab 1982, Patent 1988 + + + +--- + +![bg right:50%](./assets/suzanne-vega.jpg) + +# Suzanne Vega + +**"Tom's Diner" (1987)** + +- Der erste Song, der als MP3 kodiert wurde +- A cappella (keine Instrumente) +- Klare, hohe Frequenzen +- Perfekter Stresstest für Kompression +- Brandenburg hörte "Tom's Diner" über 10.000 Mal + + + + +--- + +# Wie funktioniert MP3? + +Ein Zusammenspiel aus vielen Faktoren: + +* **1. Frequenz-Analyse (FFT)** + Audio → Frequenzspektrum + +* **2. Psychoakustisches Modell** + Welche Töne hört Mensch nicht? + +* **3. Quantisierung** + Unwichtige Frequenzen reduzieren + +* **4. Huffman-Coding** + Lossless-Kompression der Restdaten + + + +--- + +# Bitrate: Der Qualitäts-Knopf + +| Bitrate | Qualität | Kompression | +|---------|----------|-------------| +| **128 kbps** | Hörbar schlechter | ~11x | +| **192 kbps** | Akzeptabel | ~7x | +| **256 kbps** | Gut | ~5,5x | +| **320 kbps** | "CD-Qualität" | ~4,4x | + +**Original CD:** 1.411 kbps (unkomprimiert) + + + + + + + + +--- + +# Der Patentkrieg + +**1990er:** Fraunhofer + Thomson halten MP3-Patente **Lizenzgebühren:** -- Hardware-Decoder: $0,20 pro Einheit -- "Internet Broadcast": Kostenlos (YouTube etc.) +- $0,75 pro Decoder +- $2,50 pro Encoder -**Problem:** Open-Source-Projekte in Grauzone +**Problem:** Napster (1999) → unkontrollierte Verbreitung + +**2017:** Patente laufen aus → MP3 ist frei --- -# H.265 / HEVC: Effizienter, aber... +![bg right:50% fit](./assets/napster-2001.png) -**High Efficiency Video Coding (2013)** +# Napster (1999) -50% bessere Kompression als H.264 +**P2P-Filesharing für MP3s** -**Das Problem: Patent-Chaos** - -Drei konkurrierende Patent-Pools: -- MPEG-LA -- HEVC Advance -- Velos Media - -Unklare Kosten, rechtliche Unsicherheit -→ Viele bleiben bei H.264 oder wechseln zu AV1 +- Shawn Fanning, 19 Jahre alt +- 80 Millionen User in 2 Jahren +- Musikindustrie verklagt (2001) +- Pandora's Box: Nicht mehr aufzuhalten --- -# VP9: Googles Antwort +![bg right:40% contain](./assets/bittorrent.png) -**VP9 (2013)** +# Napster & Musikindustrie -Google kaufte On2 Technologies (2010, $133M) -VP8 → VP9 → AV1 +**1999:** Napster startet +**2001:** 80 Millionen User -**Eigenschaften:** -- Ähnliche Effizienz wie H.265 -- Patent-frei (laut Google) -- YouTube nutzt VP9 für 4K +**Musikindustrie:** +- CDs kosten $15-20 +- MP3s gratis (illegal, aber yolo) +- Einzelne Songs statt Alben -**Nachteil:** Höherer CPU-Aufwand als H.264 +**2001:** Napster wird verklagt und schließt + +**Aber:** Pandora's Box offen +→ LimeWire, Kazaa, BitTorrent, später Spotify --- -![bg contain right:28%](./assets/AV1.png) +# Kulturelle Revolution - - - - +**MP3 veränderte:** -# AV1: Die offene Zukunft +✓ Musik wurde portabel (Walkman → iPod) +✓ Alben wurden irrelevant (Playlists) +✓ Musikkonsum explodierte (kostenlos/billig) +✓ KünstlerInnen verloren Kontrolle -**AV1 (2018)** - -**Alliance for Open Media:** -Google, Netflix, Amazon, Microsoft, Apple, Mozilla... - -**Eigenschaften:** -- 30% besser als H.265 -- Royalty-free, Open Source -- 8K, HDR, hohe Frame-Rates - -**Stand 2025:** -YouTube, Netflix nutzen AV1 für 4K/8K -Hardware-Encoder in aktuellen GPUs +**Aber auch:** +❌ KünstlerInnen verdienen weniger pro Stream +❌ Audio-Qualität sank (Loudness War) +❌ Physische Medien starben - ---- - - - - -![bg contain](./assets/av1-grammy.png) - - --- @@ -1239,13 +1591,7 @@ KLAUSURRELEVANT: # Fragen & Diskussion **Kontakt:** lb-czechowski@hdm-stuttgart.de -**Folien:** [librete.ch/hdm/223015b](https://librete.ch/hdm/223015b/) - - +**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b --- @@ -1256,12 +1602,27 @@ Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAli - Erlaubt Teilen & Anpassen mit Namensnennung - Adaptionen müssen unter gleicher Lizenz geteilt werden -Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/) +Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/ + +--- + + + + +# Selbstlernen: Audio-Spektrogram + +**Aufgabe (30 Min):** + +- Live Spektrogram untersuchen https://borismus.github.io/spectrogram/ +- Mit Effekten experimentieren https://audiomass.co/ +- Spektrogramme vergleichen Audacity (kostenloser Download nötig) [https://manual.audacityteam.org/man/spectrogram_view.html](https://manual.audacityteam.org/man/spectrogram_view.html) --- @@ -1269,47 +1630,26 @@ Vollständige Lizenz: [creativecommons.org/licenses/by-sa/4.0/](https://creative -![bg contain right:25%](./assets/qr/squoosh.png) +![bg contain right:22%](./assets/qr/hexed-it.png) -# Selbstlernen: Bildkompression +# Selbstlernen: HEX Files -1. Öffne [squoosh.app](https://squoosh.app) -2. Lade ein Foto hoch -3. Vergleiche: JPEG (verschiedene Quality) vs. WebP vs. AVIF -4. Beobachte: Dateigröße, Artefakte, Ladezeit - -**Fragen zum Erkunden:** -- Ab welcher Quality werden Artefakte sichtbar? -- Wie viel kleiner ist WebP bei gleicher Qualität? - - - ---- - - - - -# Selbstlernen: Video analysieren - -1. Video herunterladen (z.B. Big Buck Bunny) -2. Mit MediaInfo analysieren: Container, Codec, Bitrate -3. Optional: Mit HandBrake konvertieren - - H.264 vs. H.265 bei gleicher Qualität - - Größe und Encoding-Zeit vergleichen +1. Drei Dateien ohne Dateiendung: + `hex1` `hex2` `hex3` +3. Lies erste 16 Bytes aus und identifiziere Dateiformat (Magic Number) +5. *Optional: Datei umbenennen und korrekte Dateiendung anhängen (bspw. `.jpg`)* **Tools:** -- [MediaInfo](https://mediaarea.net/MediaInfoOnline) (Online oder Desktop) -- [HandBrake](https://handbrake.fr) (Desktop) +- Hex-Editor: [hexed.it](https://hexed.it) +- Magic Numbers: [en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) +