public/uni
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a955a7636ab50eba3a172f275ae6c7463bf55d55
uni/slides/223015b/02-bild-audio-video.md
Michael Czechowski 61468d2d3a erklaerung: bg entfernen — soll vertiefung sein, nicht klausur 
bug: 'section.erklaerung' hatte '@media print { background }' rule (alle 5
files), was im PDF rosa/blau-klausur-bg setzte. HTML hatte (in c) keinen
bg oder (in b) gradient bg. ergebnis: HTML zeigt erklaerung anders als PDF
— PDF sah aus wie klausurfolie obwohl es nur eine vertiefung ist.

fix: erklaerung behaelt nur 'font-size: 1.1rem' + h1 color/size + table
font-size. KEIN background mehr — weder screen noch print. visuell
unterschieden durch h1-color und font-size, nicht durch bg-farbe.

betroffen: b01, b02, b03, c01, c02 (alle files mit section.erklaerung).
2026-04-27 15:04:45 +02:00

41 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 Dateiformate, Schnittstellen, Speichermedien & Distributionswege
<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 { 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>

bg cover opacity:0.2

Dateiformate, Schnittstellen, Speichermedien & Distributionswege

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

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

bg fit

Teil 2: Bild- & Videoformate

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

bg

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

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.

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:

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

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

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

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

bg contain 50%

bg contain right:34%

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

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

JPEG-Kompression

Sechs Schritte im Detail

bg right:20%

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.

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%

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

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"

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.

bg

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

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.

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

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

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

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              │ │
│  └────────────────────────┘ │
└─────────────────────────────┘

Video-Kompression

Raum und Zeit nutzen

bg fit

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

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

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

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

bg fit

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. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.

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

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

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

bg contain right:28%

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.

bg contain

Fragen & Diskussion

Kontakt: lb-czechowski@hdm-stuttgart.de Folien: librete.ch/hdm/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/

bg contain right:25%

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: