add 223015b course: dateiformate, schnittstellen, speichermedien
6 termine covering file formats, interfaces, storage media, and distribution
This commit is contained in:
860
courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
Normal file
860
courses/223015b/slides/2026-01-09-termin-2-bild-audio-video.md
Normal file
@@ -0,0 +1,860 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #5da9e9;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h2 {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
color: #5da9e9;
|
||||
border-radius: 8px;
|
||||
border-left: 3px solid #5da9e9;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
code {
|
||||
background: #1a1a2e;
|
||||
color: #5da9e9;
|
||||
padding: 0.15em 0.4em;
|
||||
border-radius: 4px;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
|
||||
[https://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 2 – 09.01.2026
|
||||
## Bild-, Audio- & Videoformate
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Links: Hochauflösend
|
||||
Rechts: Stark komprimiert (JPEG-Artefakte sichtbar)
|
||||
Instagram-Effekt
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Was ist ein Bild?
|
||||
|
||||
**Digital = Pixelraster**
|
||||
|
||||
**Beispiel: 1920×1080 (Full HD)**
|
||||
= 2.073.600 Pixel
|
||||
|
||||
**Jedes Pixel = 3 Bytes (RGB)**
|
||||
2.073.600 × 3 = **6,2 MB**
|
||||
|
||||
**Für EIN Foto!**
|
||||
|
||||
<!--
|
||||
Zoom auf Pixel-Ebene zeigen
|
||||
Jedes Pixel = RGB-Tripel (3 Bytes)
|
||||
6 MB × 10.000 Fotos = 62 GB
|
||||
Smartphone-Speicher wäre schnell voll ohne Kompression
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Rastergrafiken (Bitmaps)
|
||||
|
||||
**Pixelraster:** Jeder Bildpunkt hat Koordinate + Farbwert
|
||||
|
||||
**Eigenschaften:**
|
||||
- Je größer das Bild → größere Datei
|
||||
- **Verkleinern:** Meist ohne Qualitätsverlust
|
||||
- **Vergrößern:** Wird unscharf/pixelig!
|
||||
|
||||
**Formate:** JPEG, PNG, GIF, BMP, TIFF, WebP
|
||||
|
||||
**Verwendung:** Fotos, Screenshots, komplexe Bilder
|
||||
|
||||
<!--
|
||||
Bitmap = Bit-mapped graphics
|
||||
Digitalkameras erzeugen immer Rastergrafiken
|
||||
Kompression nötig wegen Dateigrößen (PNG, JPEG, GIF)
|
||||
Skalierungsproblem: Interpolation erzeugt Unschärfe
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Vektorgrafiken
|
||||
|
||||
**Mathematische Beschreibung statt Pixel**
|
||||
|
||||
**Kreis speichern:**
|
||||
- Rastergrafik: Tausende Pixel
|
||||
- Vektorgrafik: Mittelpunkt + Radius (2 Werte!)
|
||||
|
||||
**Gespeichert werden:**
|
||||
- Form (Kreis, Linie, Pfad...)
|
||||
- Position, Farbe, Strichstärke, Füllung
|
||||
|
||||
**Vorteil:** Beliebig skalierbar ohne Qualitätsverlust!
|
||||
|
||||
**Formate:** SVG, PDF, AI, EPS
|
||||
|
||||
<!--
|
||||
Vektorgrafik = geometrische Primitive + Attribute
|
||||
SVG = Scalable Vector Graphics (Web-Standard)
|
||||
AI = Adobe Illustrator
|
||||
Ideal für Logos, Icons, Infografiken
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Raster vs. Vektor
|
||||
|
||||
| | Rastergrafik | Vektorgrafik |
|
||||
|---|---|---|
|
||||
| **Basis** | Pixelraster | Mathematische Objekte |
|
||||
| **Skalierung** | Qualitätsverlust | Verlustfrei |
|
||||
| **Dateigröße** | Abhängig von Auflösung | Abhängig von Komplexität |
|
||||
| **Gut für** | Fotos | Logos, Icons, Text |
|
||||
| **Formate** | JPEG, PNG, GIF | SVG, PDF, AI |
|
||||
|
||||
**Rasterung:** Vektorgrafik → Rastergrafik (für Bildschirm/Druck)
|
||||
|
||||
<!--
|
||||
Bildschirme sind Rastergeräte (Framebuffer)
|
||||
Jede Vektorgrafik muss gerastert werden zur Anzeige
|
||||
Browser rastert SVG in Echtzeit
|
||||
Firmenlogos: Immer als Vektor anlegen!
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Lossless: PNG
|
||||
|
||||
**PNG = Portable Network Graphics (1996)**
|
||||
|
||||
**Funktionsweise:**
|
||||
- Vorhersage (Pixel ähneln Nachbarn)
|
||||
- Differenz-Encoding
|
||||
- DEFLATE-Algorithmus (wie ZIP)
|
||||
|
||||
**Kompression:** 20-50% Ersparnis
|
||||
|
||||
**Gut für:** Screenshots, Logos, Text
|
||||
**Schlecht für:** Fotos
|
||||
|
||||
<!--
|
||||
PNG wurde entwickelt als GIF-Alternative (Patent-Probleme)
|
||||
Lossless: Originaldaten bleiben erhalten
|
||||
Transparenz: Alpha-Kanal (sanfte Übergänge)
|
||||
DEFLATE: Gleicher Algorithmus wie ZIP
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Lossy: JPEG
|
||||
|
||||
**JPEG = Joint Photographic Experts Group (1992)**
|
||||
|
||||
**Eigenschaften:**
|
||||
- Lossy Kompression
|
||||
- 90%+ Platzersparnis möglich
|
||||
- Artefakte bei hoher Kompression
|
||||
|
||||
**6 MB → 500 KB** (typisch)
|
||||
|
||||
<!--
|
||||
JPEG-Norm beschreibt nur Kompression, nicht Speicherformat
|
||||
JFIF = JPEG File Interchange Format (das eigentliche Dateiformat)
|
||||
Dateierweiterungen: .jpg, .jpeg, .jfif (alle gleich)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Beispiel: Stark komprimiertes JPEG
|
||||
Blocking (8×8-Blöcke sichtbar)
|
||||
Ringing (Geister um Kanten)
|
||||
Color Banding (Verläufe "treppig")
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Wie funktioniert JPEG? (1/2)
|
||||
|
||||
**Schritt 1: RGB → YCbCr**
|
||||
- Y = Helligkeit (Luminanz)
|
||||
- Cb/Cr = Farbe (Chrominanz)
|
||||
|
||||
**Warum?** Menschen sehen Helligkeit besser als Farbe
|
||||
|
||||
**Schritt 2: Chroma Subsampling**
|
||||
Farbauflösung reduzieren (4:2:0)
|
||||
→ 50% Datenmenge weg, kaum sichtbar
|
||||
|
||||
<!--
|
||||
YCbCr = Farbraum-Konversion
|
||||
Y = Brightness, Cb = Blue-Yellow, Cr = Red-Green
|
||||
4:2:0 Subsampling: Farbe nur jedes 2. Pixel horizontal & vertikal
|
||||
Auge merkt's kaum, weil Helligkeitssehen dominiert
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Wie funktioniert JPEG? (2/2)
|
||||
|
||||
**Schritt 3: DCT (Discrete Cosine Transform)**
|
||||
Bild in 8×8-Blöcke → Frequenzspektrum
|
||||
|
||||
**Schritt 4: Quantisierung**
|
||||
Hohe Frequenzen (Details) stark reduzieren
|
||||
→ **Hier passiert Datenverlust!**
|
||||
|
||||
**Schritt 5: Huffman-Coding**
|
||||
Lossless-Kompression der Restdaten
|
||||
|
||||
<!--
|
||||
DCT: Ähnlich wie FFT bei Audio
|
||||
8×8 Blöcke: Warum JPEG "blocky" wird bei hoher Kompression
|
||||
Quantisierung: Quality-Schieberegler steuert genau das
|
||||
Huffman: Finale Effizienz (wie bei MP3)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# JPEG Quality
|
||||
|
||||
| Quality | Dateigröße | Artefakte |
|
||||
|---------|------------|-----------|
|
||||
| **100** | ≈2-3 MB | Kaum |
|
||||
| **85-90** | ≈200-400 KB | Minimal |
|
||||
| **50** | ≈100 KB | Sichtbar |
|
||||
|
||||
**Sweet Spot: 85-90**
|
||||
10x Kompression, für Menschen kaum unterscheidbar
|
||||
|
||||
<!--
|
||||
Quality 100 = Minimum Compression (nicht lossless!)
|
||||
Quality 85-90 = Standard für Web
|
||||
Quality 50 = Sichtbare Artefakte (Blocking, Ringing)
|
||||
Photoshop "Save for Web": Standard ist 60
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
GIF-Animation (z.B. Meme)
|
||||
256 Farben, aber Animationen möglich
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Die GIF-Geschichte
|
||||
|
||||
**GIF = Graphics Interchange Format (1987)**
|
||||
CompuServe (US-Online-Dienst)
|
||||
|
||||
**Features:**
|
||||
- 256 Farben max (8-bit Palette)
|
||||
- Lossless (für Palette)
|
||||
- Animationen!
|
||||
|
||||
**1994 Twist:** Unisys hält Patent auf LZW-Kompression
|
||||
→ Fordert Lizenzgebühren
|
||||
|
||||
→ **"Burn All GIFs!" Kampagne**
|
||||
|
||||
<!--
|
||||
CompuServe: Früher Online-Dienst (1969-2009)
|
||||
LZW = Lempel-Ziv-Welch Compression
|
||||
Unisys Patent-Trolling: Erst Jahre nach GIF-Einführung
|
||||
Community-Reaktion: Boykott, Suche nach Alternative
|
||||
Ergebnis: PNG wurde entwickelt (1996)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# PNG vs. GIF
|
||||
|
||||
**GIF:**
|
||||
✓ Animationen
|
||||
✓ Breite Unterstützung
|
||||
❌ Nur 256 Farben
|
||||
❌ Patent-Probleme (bis 2003)
|
||||
|
||||
**PNG:**
|
||||
✓ Millionen Farben
|
||||
✓ Alpha-Transparenz
|
||||
✓ Patent-frei
|
||||
❌ Keine Animationen (bis APNG, 2004)
|
||||
|
||||
**Ergebnis:** PNG für Grafiken, GIF für Memes!
|
||||
|
||||
<!--
|
||||
APNG = Animated PNG (Firefox, Safari support)
|
||||
WebP (Google, 2010): Animationen + bessere Kompression
|
||||
GIF überlebte kulturell (Meme-Format)
|
||||
"GIF" Aussprache: "Jif" vs. "Gif" – ewiger Streit
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# WebP & AVIF
|
||||
|
||||
**WebP (Google, 2010):**
|
||||
- Lossy UND Lossless
|
||||
- Animationen
|
||||
- 25-35% kleiner als JPEG
|
||||
|
||||
**AVIF (2019):**
|
||||
- Basiert auf AV1-Video-Codec
|
||||
- 50% kleiner als JPEG
|
||||
- HDR-Unterstützung
|
||||
- Patent-frei
|
||||
|
||||
**Problem:** Browser-Support dauert Jahre
|
||||
|
||||
<!--
|
||||
WebP: Von Google entwickelt, deshalb Skepsis
|
||||
AVIF: Alliance for Open Media (Google, Netflix, Amazon, Mozilla...)
|
||||
Browser-Support 2024: WebP fast überall, AVIF wachsend
|
||||
JPEG bleibt dominant (Kompatibilität!)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Vorher/Nachher: Hochauflösend vs. Instagram-Upload
|
||||
Sichtbare Qualitätsverluste
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Warum Instagram eure Fotos "ruiniert"
|
||||
|
||||
**Upload-Pipeline:**
|
||||
1. Dein Foto: 12 MP, 8 MB
|
||||
2. Instagram skaliert: max. 1080px
|
||||
3. Re-Kompression: JPEG Quality ~75
|
||||
4. Endgröße: 200-400 KB
|
||||
|
||||
**Warum?**
|
||||
- Speicherkosten (Milliarden Fotos!)
|
||||
- Ladezeiten (Mobile)
|
||||
- Bandbreite (günstiger)
|
||||
|
||||
<!--
|
||||
Instagram ist keine Kunstgalerie
|
||||
Optimiert für Geschwindigkeit, nicht Qualität
|
||||
Facebook macht dasselbe
|
||||
Lösung: Portfolio-Websites (eigene Kontrolle)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hands-On: Kompression vergleichen
|
||||
|
||||
**Aufgabe (40 Min):**
|
||||
|
||||
1. Hochauflösendes Foto (eigenes oder CC)
|
||||
2. Exportiere:
|
||||
- PNG
|
||||
- JPEG Q100, Q85, Q50
|
||||
- WebP (optional)
|
||||
3. Tool: **Squoosh.app** (Google-Tool)
|
||||
4. Vergleiche: Dateigrößen, sichtbare Unterschiede
|
||||
5. Wo werden Artefakte sichtbar?
|
||||
|
||||
<!--
|
||||
Squoosh.app: Browser-basiert, keine Installation
|
||||
Side-by-Side-Vergleich mit Zoom
|
||||
Verschiedene Codecs testen
|
||||
Studis sollen selbst "Sweet Spot" finden
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Nimm ein Foto (eigenes oder CC)**
|
||||
|
||||
1. Exportiere: PNG, JPEG Q90, JPEG Q50
|
||||
2. Vergleiche Größen & Qualität
|
||||
3. Welche Quality ist für dich "akzeptabel"?
|
||||
4. Wo siehst du zuerst Artefakte?
|
||||
|
||||
**Bonus:** Teste WebP oder AVIF
|
||||
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Subjektive Wahrnehmung (jeder anders)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Video
|
||||
## Kompression & Codecs
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Netflix 4K-Streaming
|
||||
Unmöglich ohne moderne Codecs
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Problem: Video ist RIESIG
|
||||
|
||||
**1 Minute 4K-Video (3840×2160):**
|
||||
|
||||
- 30 fps (Bilder/Sekunde)
|
||||
- Jedes Bild: 24,8 MB (unkomprimiert)
|
||||
|
||||
**Rechnung:**
|
||||
30 × 24,8 MB = **744 MB/Sekunde**
|
||||
× 60 Sekunden = **44,6 GB/Minute**
|
||||
|
||||
**2-Stunden-Film: 5,3 TB!**
|
||||
|
||||
<!--
|
||||
4K = 3840×2160 Pixel = 8,3 Megapixel pro Frame
|
||||
30 fps = Standard, Kino = 24 fps, Gaming = 60+ fps
|
||||
Ohne Kompression: Unmöglich zu streamen oder speichern
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Container vs. Codec
|
||||
|
||||
**Container = Die Box**
|
||||
Verpackt Video, Audio, Untertitel, Metadaten
|
||||
|
||||
**Beispiele:** MP4, MKV, AVI, MOV
|
||||
|
||||
**Codec = Kompressionsalgorithmus**
|
||||
Entscheidet, WIE Daten komprimiert werden
|
||||
|
||||
**Video-Codecs:** H.264, H.265, VP9, AV1
|
||||
**Audio-Codecs:** AAC, MP3, Opus
|
||||
|
||||
<!--
|
||||
Container ≠ Codec (häufiges Missverständnis!)
|
||||
MP4 ist KEIN Codec, sondern Container
|
||||
Schachtel-Analogie: Container = Karton, Codec = Inhalt
|
||||
Ein MP4 kann H.264, H.265 oder AV1 enthalten
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Diagramm: Container mit verschiedenen Streams
|
||||
Video-Track (H.264)
|
||||
Audio-Track (AAC)
|
||||
Untertitel-Track (SRT)
|
||||
Metadaten (Titel, Künstler, etc.)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Video-Kompression: Drei Prinzipien
|
||||
|
||||
**1. Spatial Compression (Intra-Frame)**
|
||||
Jedes Bild einzeln (wie JPEG)
|
||||
→ I-Frames
|
||||
|
||||
**2. Temporal Compression (Inter-Frame)**
|
||||
Nur Änderungen zwischen Bildern
|
||||
→ P-Frames, B-Frames
|
||||
|
||||
**3. Motion Compensation**
|
||||
"Ball bewegt sich von A nach B"
|
||||
|
||||
<!--
|
||||
Spatial: Innerhalb eines Bildes (JPEG-ähnlich)
|
||||
Temporal: Zwischen Bildern (zeitliche Redundanz)
|
||||
Motion Compensation: Intelligente Vorhersage
|
||||
→ 90%+ Effizienz durch temporale Kompression
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# I-Frames, P-Frames, B-Frames
|
||||
|
||||
**I-Frame (Intra):**
|
||||
Vollständiges Bild (wie JPEG)
|
||||
Groß, aber unabhängig
|
||||
|
||||
**P-Frame (Predicted):**
|
||||
Referenziert vorherige Frames
|
||||
Viel kleiner
|
||||
|
||||
**B-Frame (Bi-directional):**
|
||||
Referenziert vorherige UND zukünftige Frames
|
||||
Am effizientesten
|
||||
|
||||
**GOP:** I - B - B - P - B - B - P - B - B - I
|
||||
|
||||
<!--
|
||||
GOP = Group of Pictures (typisch 12-15 Frames)
|
||||
I-Frame: Alle 1-2 Sekunden nötig (für Seeking)
|
||||
P-Frame: "Pixel X bewegt sich 5px rechts"
|
||||
B-Frame: Komplex, aber beste Kompression
|
||||
Wenn du vorspulst: Sucht nach nächstem I-Frame
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Visualisierung: I/P/B-Frame-Abhängigkeiten
|
||||
Pfeile zeigen Referenzen
|
||||
I-Frame = Anker, P/B-Frames hängen dran
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# H.264: Der König
|
||||
|
||||
**H.264 / AVC (2003)**
|
||||
|
||||
**Warum dominant?**
|
||||
✓ Exzellente Kompression (100:1 möglich)
|
||||
✓ Hardware-Support (jedes Gerät seit ~2010)
|
||||
✓ YouTube, Netflix, Blu-ray – alles H.264
|
||||
|
||||
**Features:**
|
||||
- Variable Block-Größen (16×16 bis 4×4)
|
||||
- Deblocking-Filter
|
||||
- CABAC-Coding
|
||||
|
||||
<!--
|
||||
AVC = Advanced Video Coding
|
||||
MPEG-4 Part 10 = H.264 (gleicher Standard)
|
||||
Revolutionierte Video-Streaming
|
||||
Hardware-Decoder in CPUs/GPUs → Batterie-schonend
|
||||
CABAC = Context-Adaptive Binary Arithmetic Coding
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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/Einheit
|
||||
- Content-Distribution: Kostenlos für "Internet Broadcast"
|
||||
|
||||
**Problem:** Open-Source-Projekte in Grauzone
|
||||
|
||||
<!--
|
||||
MPEG-LA = Licensing Authority
|
||||
Firefox weigerte sich lange, H.264 zu supporten (Patent-Gründe)
|
||||
Chromium musste extern linken
|
||||
Patent-Pool: Firmen teilen Patente, gemeinsame Lizenzierung
|
||||
"Free to View" Klausel: YouTube etc. kostenlos
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# H.265 / HEVC
|
||||
|
||||
**H.265 (2013):**
|
||||
50% bessere Kompression als H.264
|
||||
|
||||
**ABER:** Patent-Desaster
|
||||
|
||||
**Drei (!) konkurrierende Patent-Pools:**
|
||||
- MPEG-LA
|
||||
- HEVC Advance
|
||||
- Velos Media
|
||||
|
||||
→ Viele bleiben bei H.264 oder suchen Alternativen
|
||||
|
||||
<!--
|
||||
HEVC = High Efficiency Video Coding
|
||||
Technisch überlegen, aber juristisch Albtraum
|
||||
Apple nutzt HEVC (iPhone-Videos)
|
||||
Netflix zögert wegen Lizenzkosten
|
||||
Fragmentierung verzögert Adoption
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
YouTube VP9-Logo
|
||||
Google's Patent-freie Alternative
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# VP9: Googles Antwort
|
||||
|
||||
**VP9 (2013):**
|
||||
Entwickelt von Google (On2-Akquisition)
|
||||
|
||||
**Eigenschaften:**
|
||||
✓ Ähnlich H.265-Kompression
|
||||
✓ KOSTENLOS, patent-frei (laut Google)
|
||||
✓ YouTube nutzt VP9 für 4K
|
||||
|
||||
**Nachteile:**
|
||||
❌ Hardware-Support langsam
|
||||
❌ Höherer CPU-Aufwand
|
||||
❌ Nicht universell wie H.264
|
||||
|
||||
<!--
|
||||
On2 Technologies: Gekauft 2010 für $133M
|
||||
VP8 → VP9 → AV1 (Evolution)
|
||||
YouTube forciert VP9: 4K-Videos nur VP9/AV1
|
||||
Hardware-Decoder erst ab ~2016 (langsame Adoption)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
AV1-Logo
|
||||
Alliance for Open Media
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# AV1: Die Open-Source-Revolution
|
||||
|
||||
**AV1 (2018):**
|
||||
Alliance for Open Media: Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
|
||||
|
||||
**Ziel:** Patent-freier, moderner Codec
|
||||
|
||||
**Features:**
|
||||
✓ 30% besser als H.265
|
||||
✓ Royalty-free, Open Source
|
||||
✓ 8K, HDR, hohe Frame-Rates
|
||||
|
||||
**Stand 2025:**
|
||||
YouTube, Netflix nutzen AV1 für 4K/8K
|
||||
|
||||
<!--
|
||||
AOM = Alliance for Open Media (2015 gegründet)
|
||||
Alle Big-Tech-Player vereint (historisch!)
|
||||
"Fuck you" an Patent-Mafia
|
||||
Problem: Encoding SEHR langsam (10-100x vs. H.264)
|
||||
Hardware-Encoder kommen (ab 2020er-GPUs)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Adaptive Bitrate Streaming
|
||||
|
||||
**Problem:** Internet-Geschwindigkeit variiert
|
||||
|
||||
**Lösung:** Mehrere Qualitäten parallel
|
||||
|
||||
**MPEG-DASH / HLS:**
|
||||
- 4K (20 Mbps)
|
||||
- 1080p (5 Mbps)
|
||||
- 720p (2,5 Mbps)
|
||||
- 480p (1 Mbps)
|
||||
- 240p (0,5 Mbps)
|
||||
|
||||
Segmente: 2-10 Sekunden
|
||||
Player wählt dynamisch
|
||||
|
||||
<!--
|
||||
DASH = Dynamic Adaptive Streaming over HTTP
|
||||
HLS = HTTP Live Streaming (Apple)
|
||||
Beide ähnlich, aber inkompatibel
|
||||
Manifest-Datei: Liste aller Qualitäten
|
||||
Player misst Bandbreite, wechselt live
|
||||
→ Warum Netflix plötzlich pixelig wird
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Visualisierung: Qualitätswechsel während Playback
|
||||
Bandbreite schwankt → Player reagiert
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Container im Detail
|
||||
|
||||
**MP4:**
|
||||
- Standard für Web, Mobile
|
||||
- H.264, H.265, AV1
|
||||
- DRM-fähig
|
||||
|
||||
**MKV (Matroska):**
|
||||
- Open Source, extrem flexibel
|
||||
- Beliebig viele Audio-/Untertitel-Spuren
|
||||
- Fast jeden Codec
|
||||
|
||||
**WebM:**
|
||||
- Google, Web-optimiert
|
||||
- Nur VP9/AV1 + Opus/Vorbis
|
||||
|
||||
<!--
|
||||
MP4 = MPEG-4 Part 14 (ISO-Standard)
|
||||
Matroska = Russisch: Matrjoschka (Puppen ineinander)
|
||||
WebM = Subset von Matroska (HTML5-Video)
|
||||
MKV vs. MP4: Offenheit vs. Kompatibilität
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hands-On: Video analysieren
|
||||
|
||||
**Aufgabe (40 Min):**
|
||||
|
||||
**Tool:** FFmpeg (CLI) oder HandBrake (GUI)
|
||||
|
||||
1. Download: CC-Video (Big Buck Bunny, ~1 Min)
|
||||
2. Analysiere: `ffmpeg -i video.mp4` oder MediaInfo
|
||||
3. Notiere: Container, Codec, Bitrate, Auflösung
|
||||
4. Konvertiere:
|
||||
- H.264, 1080p, 5 Mbps
|
||||
- H.265, 1080p, 2,5 Mbps
|
||||
5. Vergleiche: Größen, Encoding-Zeit, Qualität
|
||||
|
||||
<!--
|
||||
Big Buck Bunny: Open-Source-Film (Blender Foundation)
|
||||
FFmpeg: Swiss Army Knife für Video
|
||||
HandBrake: GUI für FFmpeg (einfacher)
|
||||
MediaInfo: Detaillierte Datei-Analyse
|
||||
Encoding-Zeit: H.265 deutlich langsamer als H.264
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Nimm kurzes Video (eigenes oder CC, max. 1 Min)**
|
||||
|
||||
1. Analysiere: Container, Codecs, Bitrate
|
||||
2. Konvertiere: H.264 + H.265 (gleiche Qualität)
|
||||
3. Vergleiche: Dateigrößen, Encoding-Zeiten, visueller Unterschied?
|
||||
|
||||
**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
|
||||
|
||||
<!--
|
||||
MediaInfo oder ffprobe für Analyse
|
||||
HandBrake für Konvertierung
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://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: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
|
||||
Reference in New Issue
Block a user