public/uni
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
722a4a9fe8826a218744fa487d5881b9e12617b0
uni/slides/223015b/03-inhalte-bild-audio-video.md
T
libretech 722a4a9fe8 slides: 8 overflow-folien gefixt + fragmented-list-marker eingeführt 
per user-feedback nach QA-render-check aller 493 folien (overflow-detector via PIL bottom-band-darkness):

223015b/01-daten-grundlagen s.036 nyquist:
  H1 'Nyquist-Theorem — warum 2× reicht' → 'Nyquist — warum 2× reicht'
  body text gekürzt, drei fälle als * statt - (marp fragmented list)

223015b/03-inhalte-bild-audio-video s.009 RGB→Y'CbCr:
  H1 verkürzt, bg right 50% → 45% contain, list-marker * (Y/Cb/Cr reveal)
  text 'unabhängig komprimiert werden' eingedampft

223015b/03-inhalte-bild-audio-video s.031 inter-frame:
  H1 'Inter-Frame-Kompression — die zentrale Idee' → 'Inter-Frame — die zentrale Idee'
  bg right 42% → 40% contain
  bullets I/P/B mit * (fragmented reveal)

223015b/05-distribution-metadaten s.012 EXIF-tabelle:
  8 zeilen → 5 zeilen (kamera+linse zusammengelegt, belichtung kompakt, software+bearbeitung zusammengelegt)

223015b/05-distribution-metadaten s.014 EXIF-stripping:
  7 plattform-zeilen → 5 (facebook+iMessage und E-mail+slack+discord zusammen)
  faustregel als italic-zeile statt bold-block

223015c/01-geschichte-grundlagen-html s.006 alan turing:
  bg right 35% (default fill) → 33% contain (verhindert dass composite-bild bis footer reicht)
  3 jahres-zeilen als * bullets (fragmented reveal)

dhbw/01_web_eng s.054 counter:
  in 2 folien gesplittet: 'Counter — Vanilla + React' und 'Counter — Vue + Svelte'
  pointe 'vier frameworks, dasselbe pattern: state → UI re-rendert' am ende der 2. folie

dhbw/08_best_practices s.005 .gitignore:
  code-block gekürzt: 6 sektionen → 5, mehrere lines pro logical group zusammengezogen (pem+key zusammen, vscode+idea zusammen)
  github.com/github/gitignore als markdown-link

bonus: wo pädagogisch sinnvoll - durch * ersetzt (marp progressive-reveal in presenter-modus). nicht überall — nur wo bullets sequenziell aufgedeckt werden sollten.

klausurfolien regeneriert (223015b 27, 223015c 19)
2026-05-14 20:48:38 +02:00

33 KiB
Raw Blame History

marp, theme, paginate, backgroundColor, header, footer, title
marp theme paginate backgroundColor header footer title
true gaia true Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b) Michael Czechowski – HdM Stuttgart – SoSe 2026 Inhalte — Bild, Audio, Video
<style> :root { --color-foreground: #1a1a2e; --color-highlight: #1e5f8a; --color-dimmed: #4a4a6a; } section.invert { --color-foreground: #fff; } section { font-size: 1.7rem; } h1 { color: #1e5f8a; } section.invert h1 { color: #fff; } h2 { color: #1f2937; } pre { background: #0f0f23; color: #5fb3e4; border-radius: 8px; border-left: 3px solid #1e5f8a; } pre code { background: transparent; color: inherit; } code { background: #0f0f23; padding: 0.15em 0.4em; border-radius: 4px; font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; } section code:not(.hljs) { color: #5fb3e4 !important; } section code.hljs { color: #f8f8f8 !important; } a { color: var(--color-highlight); } section.klausur { background: repeating-linear-gradient( 135deg, #e3f2fd, #e3f2fd 40px, #fff 40px, #fff 80px ) !important; } @media print { section.klausur { background: #e3f2fd !important; } } section.aufgabe { background: #e3f2fd !important; } section.aufgabe footer { display: none; } section.erklaerung :not(header), section.erklaerung :not(footer) { font-size: 1.1rem; } section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; } section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; } section.erklaerung p { font-size: 1.0rem; line-height: 1.4; } section.erklaerung table { font-size: 0.9rem; } </style>

Kapitel 3

Inhalte — Bild, Audio, Video

Drei Modalitäten, ein Prinzip

bg fit

Sub-Sektion A: Bilder

bg fit

Raster vs. Vektor

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

JPEG — das Foto-Workhorse seit 1992

bg fit

Schritt 1: RGB → Y'CbCr

bg right:45% contain

Trick: Helligkeit von Farbe trennen.

  • Y = Luminanz (Helligkeit)
  • Cb = blau-gelb-Differenz
  • Cr = rot-grün-Differenz

Auge sieht Y scharf, Cb/Cr grob. Beide werden unabhängig komprimiert.

Schritt 2: Chroma-Subsampling (4:2:0)

bg right:48% contain

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.

Memo: Die 6 JPEG-Schritte

# 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

Nur 2 der 6 Schritte verlieren Information.

bg fit

Andere Bildformate

Bildformate im Überblick

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

Wann welches Bildformat?

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

Patent-Politik — warum WebP, nicht JPEG XL?

WebP (Google, 2010): lizenzfrei. Chrome supportet von Anfang an. Heute überall.

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.

Sub-Sektion B: Audio

Sampling + Bittiefe — Recap aus Kap 1

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?

bg fit

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

Selbstlernen — Spotify-Bitrate live

Auf eurem Handy:

  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.

Was fällt auf? Welche Frequenzen verschwinden zuerst?

Sub-Sektion C: Video

Pixel × Pixel × Hz = Datenflut

Roh-Video 4K @ 60 fps:

3 840 × 2 160 Pixel × 3 Byte × 60 fps = 1,49 GB/s

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.

bg fit

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 — die zentrale Idee

bg right:40% contain

Aufeinanderfolgende Frames sind fast gleich. Statt jedes ganz speichern: nur Differenz.

Drei Frame-Typen:

  • I (Intra) — ganzes Bild
  • P (Predicted) — Diff zum vorigen
  • B (Bidirectional) — Diff zu vorigem + nächstem

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 ö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.

Reference in New Issue View Git Blame Copy Permalink