Dateiformate, Schnittstellen, Speichermedien & Distributionswege

223015b · Modul "Technik 1" · 1. Semester
Digital- und Medienwirtschaft
Hochschule der Medien Stuttgart

https://librete.ch/hdm/223015b/

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Teil 2: Bild- & Videoformate

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Warum verschiedene Dateiformate?

Ein Dateiformat definiert:

  • Ob und wie Daten komprimiert werden
  • Welche Metadaten enthalten sind
  • Wie Daten codiert und decodiert werden (Co·dec)
Ziel Bild Audio Dokument
Kleine Dateien JPEG MP3 —
Perfekte Qualität PNG, RAW FLAC PDF
Animation/Video GIF — —
Skalierbarkeit SVG — PDF
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Digitale Bilder

Raster- und Vektorgrafiken

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026

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

Rastergrafik – Vertiefung

Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.

Speicherberechnung: Breite × Höhe × Bytes pro Pixel

Auflösung Farbtiefe Berechnung Größe
1920×1080 24 Bit (3 B) 2.073.600 × 3 6,2 MB
4K (3840×2160) 24 Bit 8.294.400 × 3 24,9 MB
4K 32 Bit (4 B) 8.294.400 × 4 33,2 MB

Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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
Michael Czechowski – HdM Stuttgart – SoSe 2026

Vektorgrafiken

Speicherung als geometrische Primitive:

  • Pfade (Bézierkurven mit Kontrollpunkten)
  • Grundformen (Rechteck, Ellipse, Polygon)
  • Text (Glyphen als Outlines)

SVG-Beispiel:

<circle cx="50" cy="50" r="40" fill="#ff0000"/>

SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.

Vektorgrafik – Vertiefung

Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.

Bézier-Kurven (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):

  • Definiert durch Ankerpunkte und Kontrollpunkte
  • Kubische Bézier: 2 Anker + 2 Kontrollpunkte
  • Mathematisch exakt reproduzierbar
Aspekt Raster Vektor
Skalierung 10× Pixel sichtbar Perfekt scharf
Foto-Realismus Gut geeignet Unpraktikabel
Dateigröße Logo Wächst mit Auflösung Konstant (~5 KB)
Editierbarkeit Destruktiv Nicht-destruktiv

Rasterisierung: GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Raster- und Vektorgrafiken

Raster Vektor
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
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Menschliche Wahrnehmung

Psychovisuelle Kompression

Michael Czechowski – HdM Stuttgart – SoSe 2026

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

Psychovisuelle Wahrnehmung – Vertiefung

Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.

Räumliche Frequenz beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:

  • Niedrig: Himmel, Wand – große einheitliche Flächen
  • Hoch: Haare, Texturen, Schrift – schnelle Wechsel

Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.

Biologisches Limit Ausnutzung in JPEG
Farbauflösung ~20× geringer Chroma Subsampling (4:2:0)
Hohe Frequenzen unscharf DCT + Quantisierung
Kontrast-Maskierung Artefakte in Texturen versteckt
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Grenzen der Kompression: JPEG-Artefakte

Bei starker Kompression sichtbar:

  • Posterization:
    Farbverläufe werden stufig

  • Blocking:
    8×8-Blöcke werden sichtbar

  • Ringing:
    "Geister" an scharfen Kanten

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

JPEG-Kompression

Sechs Schritte im Detail

Michael Czechowski – HdM Stuttgart – SoSe 2026

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

Farbraumkonversion – Vertiefung

RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:

Y  =  0.299·R + 0.587·G + 0.114·B
Cb = −0.169·R − 0.331·G + 0.500·B + 128
Cr =  0.500·R − 0.419·G − 0.081·B + 128

Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.

Chroma Subsampling – Notation J🅰️b (bezogen auf 4×2 Pixel):

Schema Farbdaten Einsatz
4:4:4 100% Postproduktion, Grafik
4:2:2 50% Broadcast, Pro-Video
4:2:0 25% JPEG, H.264, Streaming

Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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!

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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  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"

Michael Czechowski – HdM Stuttgart – SoSe 2026

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)

Huffman-Coding – Vertiefung

David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.

Algorithmus (Bottom-Up-Baumkonstruktion):

  1. Alle Symbole nach Häufigkeit sortieren
  2. Die zwei seltensten Symbole zu einem Knoten kombinieren
  3. Wiederholen bis nur noch die Wurzel übrig ist
  4. Codes ablesen: links = 0, rechts = 1

Präfixfreiheit: Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.

Eigenschaft Huffman Arithmetisch
Einheit Ganze Bits Fraktionale Bits
Optimalität Optimal für ganze Bits Näher an Entropie
Geschwindigkeit Schneller Langsamer
JPEG-Einsatz Standard (Baseline) Optional (selten)

JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Andere Bildformate

PNG, GIF, WebP, AVIF

15:33 Uhr weiter

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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)

Michael Czechowski – HdM Stuttgart – SoSe 2026

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

WebP & AVIF – Vertiefung

WebP entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.

AVIF basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.

Aspekt WebP AVIF
Basis-Codec VP8/VP9 AV1
Kompression vs. JPEG 25–35% besser 50% besser
HDR/Wide Gamut Nein Ja (10/12 Bit)
Encoding-Geschwindigkeit Schnell Sehr langsam
Browser-Support 2025 97%+ 93%+

Warum JPEG dominiert: Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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)
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Video

Bilder + Zeit + Audio

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026

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

Container vs. Codec – Vertiefung

Container (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.

Codec (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.

Container Entwicklung Typische Codecs Besonderheit
MP4 ISO/MPEG H.264, H.265, AAC Web-Standard, DRM-fähig
MKV Matroska Alle Beliebig viele Streams, Kapitel
WebM Google VP9, AV1, Opus HTML5-optimiert, lizenzfrei
MOV Apple ProRes, H.264 Professionelle Produktion

Metadaten im Container:

  • Timecodes für Frame-genaue Synchronisation
  • Kapitelmarken, Thumbnails
  • Sprach-Tags für Audio/Untertitel
  • HDR-Metadaten (MaxCLL, MaxFALL)

Praktisches Problem: Eine .mp4-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Container + Codec = Video

┌─────────────────────────────┐
│  Container (z.B. MP4)       │
│  ┌────────────────────────┐ │
│  │ Video-Stream (H.264)   │ │
│  ├────────────────────────┤ │
│  │ Audio-Stream (AAC)     │ │
│  ├────────────────────────┤ │
│  │ Untertitel (SRT)       │ │
│  ├────────────────────────┤ │
│  │ Metadaten              │ │
│  └────────────────────────┘ │
└─────────────────────────────┘
Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Video-Kompression

Raum und Zeit nutzen

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Drei Kompressionsprinzipien

1. Spatial Compression (Intra-Frame)
Jedes Bild einzeln komprimieren (wie JPEG)

2. Temporal Compression (Inter-Frame)
Nur Änderungen zwischen Bildern speichern

3. Motion Compensation
Bewegung beschreiben statt Pixel kopieren

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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)"

Michael Czechowski – HdM Stuttgart – SoSe 2026

H.264 / AVC

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)

H.264/AVC – Vertiefung

H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.

Technische Innovationen:

  • Variable Blockgrößen: 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
  • Intra-Prediction: Blöcke werden aus Nachbarn vorhergesagt
  • In-Loop Deblocking: Filter reduziert Blockartefakte vor der Referenzierung
  • CABAC: Arithmetic Coding ersetzt Huffman (10–15% effizienter)
Profile Anwendung Max. Auflösung
Baseline Videotelefonie, ältere Geräte 480p
Main Broadcast, Streaming 1080p
High Blu-ray, professionell 4K

Hardware-Ubiquität: Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.

Patent-Pool (MPEG-LA): ~2.000 Patente von 30+ Unternehmen. Endnutzungs-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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 pro Einheit
  • "Internet Broadcast": Kostenlos (YouTube etc.)

Problem: Open-Source-Projekte in Grauzone

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

H.265 / HEVC: Effizienter, aber...

High Efficiency Video Coding (2013)

50% bessere Kompression als H.264

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

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

VP9: Googles Antwort

VP9 (2013)

Google kaufte On2 Technologies (2010, $133M)
VP8 → VP9 → AV1

Eigenschaften:

  • Ähnliche Effizienz wie H.265
  • Patent-frei (laut Google)
  • YouTube nutzt VP9 für 4K

Nachteil: Höherer CPU-Aufwand als H.264

Michael Czechowski – HdM Stuttgart – SoSe 2026

AV1: Die offene Zukunft

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

AV1 – Vertiefung

Die Alliance for Open Media (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.

Gründungsmitglieder: Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.

Technische Innovation Beschreibung
Superblocks Bis 128×128 Pixel (H.264: max 16×16)
Prediction Modes 56 Intra-Modi (H.264: 9)
Transform 10 verschiedene Transformtypen
Film Grain Synthesis Filmkorn wird als Parameter übertragen

Encoding-Performance: Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.

Adoption 2025: YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.

Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

Fragen & Diskussion

Kontakt: lb-czechowski@hdm-stuttgart.de
Folien: librete.ch/hdm/223015b

Michael Czechowski – HdM Stuttgart – SoSe 2026
Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)

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: creativecommons.org/licenses/by-sa/4.0/

Michael Czechowski – HdM Stuttgart – SoSe 2026

Selbstlernen: Bildkompression

  1. Öffne 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

Tools:

- Willkommen, kurze Vorstellung - Heute: Teil 2 – Bilder und Video - Ziel: Verstehen, WARUM Formate so funktionieren, nicht nur WAS sie tun - Frage zum Einstieg: "Wer hat schon mal ein Bild für Instagram hochgeladen und sich gewundert, warum es danach schlechter aussieht?"

- QR-Code scannen für Folien-Link - Folien sind CC BY-SA lizenziert – dürft ihr nutzen und teilen

- Drei große Blöcke heute: 1. Digitale Bilder (Raster vs. Vektor) 2. JPEG im Detail (die Magie der Kompression) 3. Video (warum es nochmal komplizierter ist) - Interaktive Demos zwischendurch

- Kernfrage: Warum nicht EIN Format für alles? - Antwort: Jedes Format ist ein Kompromiss - Frage an Studierende: "Was wäre wichtiger – kleine Datei oder perfekte Qualität?" → Kommt drauf an! - Analogie: Werkzeugkasten – Hammer für Nägel, Schraubenzieher für Schrauben

- Links: Original (hochauflösend) - Rechts: Stark komprimiert - Frage: "Wer sieht die Unterschiede?" - Auf Blockartefakte und Unschärfe hinweisen - Das ist der Preis für kleine Dateien

- Zwei fundamental verschiedene Ansätze - Raster: "Malen nach Zahlen" – jeder Punkt einzeln - Vektor: "Bauanleitung" – Formen beschreiben

- Pixel = Picture Element - RGB = Rot, Grün, Blau (je 0-255) - Rechenbeispiel gemeinsam durchgehen - Frage: "Wie viele Fotos passen auf ein 64GB Smartphone?" → ca. 10.000 unkomprimiert - Pointe: Ohne Kompression wäre Smartphone-Fotografie unmöglich

KLAUSURRELEVANT: - Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes - Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB - Farbtiefe: 2^n Farben bei n Bit - 24 Bit = 8 Bit pro Kanal (R, G, B) - 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)

- Kernproblem: Rasterbilder haben EINE native Auflösung - Alles darüber = Schätzung, Erfindung - Demo-Idee: Bild in Photoshop/GIMP stark vergrößern - Nearest Neighbor gut für Pixel-Art (soll pixelig bleiben) - Frage: "Warum wird mein Profilbild manchmal unscharf?" → Plattform skaliert

KLAUSURRELEVANT: - Vektor = Beschreibung (deklarativ) - Raster = Pixel für Pixel (imperativ) - Rendering-Pipeline: Vektordaten → Rasterisierung → Display - Skalierung = Koordinaten multiplizieren → keine Information geht verloren - SVG = Scalable Vector Graphics (Web-Standard)

- Entscheidungsregel: - Foto → immer Raster - Logo → immer Vektor - Screenshot → meist Raster - Konvertierung: - Vektor → Raster: trivial (Rasterisierung) - Raster → Vektor: schwierig, oft unbefriedigend (Tracing) - Frage: "Warum verschickt euch der Grafiker das Logo als .ai oder .svg?"

- Jetzt wird's spannend: Wie können wir 90% der Daten wegwerfen, ohne dass es auffällt? - Antwort: Das menschliche Auge ist kein perfekter Sensor - Wir nutzen seine Schwächen aus

KLAUSURRELEVANT: - Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge - "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit? - Niedrig = langsame Änderung = große gleichmäßige Fläche - Hoch = schnelle Änderung = feine Details, Kanten - Analogie zur Psychoakustik bei MP3 (letztes Mal)

- Kompressionsvergleich am Beispiel - Von links nach rechts: zunehmende Kompression - Frage: "Ab wo seht ihr deutliche Qualitätsverluste?" - Zeigt: Viel Spielraum für "unsichtbare" Kompression

- Artefakte = sichtbare Spuren der Kompression - Blocking: Benachbarte 8×8-Blöcke unabhängig komprimiert - Ringing: DCT hat Probleme mit harten Kanten (Gibbs-Phänomen) - Posterization: Zu wenig Bits für feine Farbabstufungen - Demo: Stark komprimiertes JPEG zoomen

- Quality 100 ≠ unkomprimiert (immer noch lossy!) - Für Web/Social Media: 60–80 oft ausreichend - Für Archivierung: 90–100 oder besser PNG/RAW - Faustregel: Quality 85 = guter Kompromiss

- Jetzt: Unter die Haube schauen - JPEG = Joint Photographic Experts Group (1992) - Sechs Schritte, davon einer verlustbehaftet - Interaktive Demo: https://claude.ai/public/artifacts/452e62f1-8525-442d-aa88-bf3795cab2c5

KLAUSURRELEVANT: - YCbCr = auch 3 Werte pro Pixel, aber anders organisiert - Statt R-G-B: Helligkeit + 2 Farbdifferenzen - Umrechnung ist reversibel (mathematische Transformation) - Vorteil: Helligkeit und Farbe getrennt behandelbar - Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)

- Beispiel 4:2:0: 4 Pixel teilen sich einen Farbwert, aber jeder hat eigene Helligkeit - Auge merkt es kaum → psychovisuelle Kompression - Bereits hier: 50% Datenreduktion ohne sichtbaren Verlust - In Video noch wichtiger (weniger Bandbreite)

- Visualisierung der Subsampling-Schemata - Obere Reihe: Luminanz (Y) – immer voll - Untere Reihen: Chrominanz (Cb, Cr) – reduziert - 4:2:0 am häufigsten (JPEG, Video)

- 8×8 = historischer Kompromiss (Rechenleistung 1992) - Unabhängige Verarbeitung = Grund für Blocking-Artefakte - Level Shift: Mathematische Vorbereitung für DCT - Bei nicht durch 8 teilbaren Dimensionen: Padding am Rand

- DCT = Herzstück von JPEG - Ähnlich wie Fourier-Transformation, aber nur Cosinus - Sortiert Information nach "Wichtigkeit" - Niedrige Frequenzen (oben links) = wichtig - Hohe Frequenzen (unten rechts) = Details, oft verzichtbar - NICHT hier passiert der Verlust!

KLAUSURRELEVANT: - Quantisierung = Division durch Quantisierungsmatrix + Runden - Einziger verlustbehafteter Schritt! - Quality 100 ≠ verlustfrei, nur "wenig wegwerfen" - Quantisierungstabellen basieren auf Wahrnehmungsforschung

- Visualisierung von Quantisierung (hier: Farbreduktion) - Prinzip gilt auch für DCT-Koeffizienten - Weniger Stufen = weniger Daten = weniger Qualität

- Zigzag: Clever – sortiert so, dass Nullen am Ende stehen - RLE: Klassische verlustfreie Kompression - Lange Nullsequenzen → sehr kurze Codes - Beispiel: "00000000" (8 Byte) → "(8,0)" (2 Byte)

KLAUSURRELEVANT: - Huffman = verlustfrei, optimal für bekannte Häufigkeiten - Präfix-frei: Kein Code ist Anfang eines anderen - Häufigstes Zeichen = kürzester Code - Auch in ZIP, PNG, MP3 verwendet

# Huffman-Coding: Beispiel **Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit) **Häufigkeitsanalyse:** A=5, B=2, R=2, C=1, D=1 **Huffman-Baum → Codes:** | Zeichen | Häufigkeit | Code | |---------|------------|------| | A | 5 | `0` | | B | 2 | `10` | | R | 2 | `110` | | C | 1 | `1110` | | D | 1 | `1111` | **Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit** **Kompression:** 88 → 23 Bit = **74% gespart** - Beispiel Schritt für Schritt durchrechnen - Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code - Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar - Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis - In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert

- Zusammenfassung: Typische JPEG-Artefakte - Blocking: 8×8-Struktur sichtbar - Ringing: Geister um Kanten - Color Banding: Farbverläufe werden stufig - Alles Folgen der Quantisierung

- JPEG ist nicht für alles geeignet - Jetzt: Alternativen und ihre Stärken

- PNG entstand als Reaktion auf GIF-Lizenzprobleme - "PNG is Not GIF" (rekursives Akronym) - DEFLATE-Kompression (wie ZIP) - Keine Qualitätsverluste, aber größer als JPEG für Fotos - Transparenz mit 256 Stufen (nicht nur an/aus wie GIF)

- CompuServe entwickelte GIF 1987 - LZW = Lempel-Ziv-Welch Kompression - Patent lief 2004 aus, aber PNG war da längst etabliert - GIF überlebte wegen Animationen - Aussprache: "GIF" vs. "JIF" – ewiger Streit (Erfinder sagt "JIF")

KLAUSURRELEVANT: - WebP: VP8-Kompression (Google Video-Codec) - AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla) - Beide besser als JPEG, aber Kompatibilität bleibt Problem - JPEG bleibt dominant: alte Kameras, Software, Workflows

- Kompatibilität schlägt oft Effizienz - TIFF für Archivierung: Unkomprimiert oder verlustfrei - RAW für FotografInnen: Maximale Bearbeitungsfreiheit - Frage: "Was passiert, wenn ihr ein PNG auf Instagram hochladet?"

- Vorher/Nachher: Original vs. Instagram-Upload - Sichtbare Qualitätsverluste - Warum? → Nächste Folie

- Instagram ist keine Kunstgalerie, sondern Massenplattform - Optimiert für Geschwindigkeit, nicht Qualität - Facebook, Twitter, TikTok – alle machen das - Tipp für FotografInnen: Portfolio auf eigener Website - Diskussion: Ist das fair? Trade-off Nutzende vs. Plattform

- Jetzt wird's richtig interessant - Video = viele Bilder + Ton + Synchronisation - Das Größenproblem potenziert sich - Interaktive Demo: https://claude.ai/public/artifacts/fd58ac94-6b64-4d93-82be-ffb648ed9897

- Rechnung gemeinsam durchgehen - Frage: "Wie groß ist ein Netflix-Film typischerweise?" → 3–7 GB - Das ist Faktor 1000 Kompression! - Ohne Video-Kompression: Kein Streaming, kein YouTube, keine Blu-rays

KLAUSURRELEVANT: - Container ≠ Codec (häufiges Missverständnis!) - MP4 kann H.264, H.265 oder AV1 enthalten - Gleiche Endung, unterschiedlicher Inhalt - Tool-Tipp: MediaInfo zeigt beides an

- MP4 = MPEG-4 Part 14, ISO-Standard - MKV = Matroska (russische Matrjoschka-Puppen) - WebM = Subset von Matroska für HTML5 - MKV beliebt für Filme mit mehreren Sprachen - AVI: Bitte nicht mehr verwenden

- H.264: De-facto-Standard seit 20 Jahren, Hardware-Decoder überall - H.265: 50% besser, aber drei konkurrierende Patent-Pools - VP9: Google kaufte On2 Technologies, forciert über YouTube - AV1: Alliance for Open Media – die Tech-Giganten vereint

- Container = Verpackung - Codec = wie der Inhalt komprimiert ist - Ein MP4 mit H.264 und ein MP4 mit H.265 haben dieselbe Endung - Wichtig für Kompatibilität: Player muss Codec unterstützen

- Video hat zwei Dimensionen der Redundanz: 1. Räumlich (innerhalb eines Frames) – wie bei JPEG 2. Zeitlich (zwischen Frames) – neu! - Die zeitliche Redundanz ist der Schlüssel

- Visualisierung: I/P/B-Frame-Abhängigkeiten - I-Frame = Vollbild (Keyframe) - P-Frame = Vorwärts-Referenz - B-Frame = Bidirektionale Referenz - Mehr dazu auf den nächsten Folien

- Spatial = räumlich, innerhalb eines Bildes - Temporal = zeitlich, zwischen Bildern - Motion Compensation = Bewegungsvektoren - 90% eines Frames oft identisch mit dem vorherigen! - Kernidee: Warum zweimal speichern, was sich nicht ändert?

- I = Intra = innerhalb - I-Frames sind groß, aber wichtig für: - Seeking (Springen im Video) - Fehlerkorrektur - Schnitt - Typisch alle 1–2 Sekunden ein I-Frame

KLAUSURRELEVANT: - I = Intra (vollständig) - P = Predicted (vorhergesagt aus Vergangenheit) - B = Bi-directional (Vergangenheit + Zukunft) - B-Frames sind am kleinsten, aber brauchen mehr Rechenleistung - GOP-Länge beeinflusst Seeking-Geschwindigkeit

- Macroblocks: Typisch 16×16 oder variable Größen - Motion Vectors beschreiben Verschiebung - Funktioniert gut bei: Kameraschwenks, bewegte Objekte - Funktioniert schlecht bei: Szenenwechsel, Konfetti, Feuerwerk - Demo: Video Frame für Frame durchgehen

- Nochmal das Bild mit dem neuen Wissen betrachten - Pfeile zeigen Abhängigkeiten - B-Frames referenzieren in beide Richtungen - Frage: "Was passiert, wenn ein I-Frame beschädigt ist?"

KLAUSURRELEVANT: - H.264 revolutionierte Video-Streaming - Ohne H.264 kein Netflix, kein YouTube HD - Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain - Selbst billigste Smartphones können H.264 abspielen

- MPEG-LA = Licensing Authority - Firefox weigerte sich lange, H.264 zu unterstützen - "Free to View" gilt nur für Endnutzungs-Streaming - Diskussion: Sollten Standards patent-frei sein?

- Technisch überlegen, aber Lizenz-Albtraum - 4K-Streaming wäre ohne H.265/VP9/AV1 nicht praktikabel - Apple nutzt HEVC (iPhone-Videos) - Netflix zögerte lange - Lehre: Technische Überlegenheit reicht nicht

- YouTube forciert VP9: 4K-Videos nur in VP9 oder AV1 - Hardware-Decoder ab ~2016 in GPUs - Google's Strategie: Eigene Infrastruktur als Hebel - Frage: Ist es gut, wenn ein Konzern Standards setzt?

KLAUSURRELEVANT: - AOM gegründet 2015 – historisch: Konkurrenten vereint - Ziel: Nie wieder Patent-Chaos wie bei H.265 - Problem: Encoding sehr langsam (10–100× vs. H.264) - Hardware-Encoder lösen das zunehmend - AV1 gewann 2024 einen Emmy für technische Innovation

- AV1 gewann 2024 einen Emmy für technische Innovation - Anerkennung für offene Standards - Zeigt: Open Source kann Industriestandard werden

- Offene Fragen? - Welches Thema war am überraschendsten? - Hinweis auf Selbstlernaufgaben (nächste Folien)

- Folien dürfen verwendet und angepasst werden - Bedingung: Namensnennung und gleiche Lizenz - Fragen zur Lizenz? → Creative Commons Website

- Squoosh: Google-Tool zum Vergleichen von Bildformaten - Live-Vergleich mit Schieberegler - Ziel: Gefühl für Kompressionsraten entwickeln - Bonus: Eigene Fotos testen

- Big Buck Bunny: Open-Source-Film der Blender Foundation - Frei verfügbar, ideal zum Experimentieren - MediaInfo zeigt alle technischen Details - HandBrake: GUI für FFmpeg, einfacher zu bedienen - Experiment: Gleiches Video, verschiedene Codecs vergleichen