824 lines
16 KiB
Markdown
824 lines
16 KiB
Markdown
---
|
||
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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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
|
||
-->
|
||
|
||
---
|
||
|
||
<!-- _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/
|
||
|