---
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);
}
section.klausur {
  background: #e3f2fd !important;
}
section.klausur footer {
  display: none;
}
</style>

<!-- _class: invert -->
<!-- _header: '' -->
<!-- _footer: '' -->
<!-- _backgroundColor: #000 -->

![bg fit opacity:0.4](./assets/digital-landscape.png)

# Dateiformate, Schnittstellen, Speichermedien & Distributionswege

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

**Wintersemester 2025/26**

[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/qr/slides-223015b.png)

---

<!-- _class: lead -->

# Termin 2 – 09.01.2026
## Bild-, Audio- & Videoformate

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg](./assets/photo-comparison.png)

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

---

<!-- _class: klausur -->
<!-- _footer: '' -->

# Rastergrafiken (Bitmaps)

**Aufbau:** 2D-Array von Pixeln mit Farbwerten

**Speicherbedarf (unkomprimiert):**
Breite × Höhe × Farbtiefe (in Bytes)
→ 1920×1080 × 3 Byte (RGB) = **6,2 MB**

**Farbtiefe:**
- 1 Bit = 2 Farben (S/W)
- 8 Bit = 256 Farben (Graustufen/Palette)
- 24 Bit = 16,7 Mio. Farben (True Color)
- 32 Bit = True Color + Alpha (Transparenz)

**Skalierung:** Interpolation (Nearest Neighbor, Bilinear, Bicubic)

<!--
DEFINITION: Bitmap = Bit-mapped graphics, 2D-Matrix aus Pixeln
BERECHNUNG SPEICHERBEDARF: Breite × Höhe × (Farbtiefe / 8)
BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
FARBTIEFE erklärt:
- 1 Bit: 2^1 = 2 Farben (Schwarz/Weiß, Fax)
- 8 Bit: 2^8 = 256 Farben (GIF, Graustufen)
- 24 Bit: 2^24 = 16.777.216 Farben (True Color, RGB je 8 Bit)
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal (Transparenz)
INTERPOLATION bei Skalierung:
- Nearest Neighbor: Schnell, pixelig (Pixel-Art)
- Bilinear: Mittelwert aus 4 Nachbarn (Standard)
- Bicubic: 16 Nachbarn, glatter (Photoshop-Standard)
- Lanczos: Beste Qualität, rechenintensiv
PRÜFUNGSRELEVANT: Speicherberechnung, Farbtiefe-Tabelle, warum Vergrößern problematisch
-->

---

<!-- _class: klausur -->
<!-- _footer: '' -->

# 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"/>`
→ 3 Parameter statt 5.027 Pixel (r=40)

**Rendering-Pipeline:**
Vektordaten → Rasterisierung → Framebuffer → Display

**Auflösungsunabhängig:** Gleiche Datei für Icon (32px) und Plakat (3m)

<!--
PRIMITIVE: Grundbausteine der Vektorgrafik
- Pfade: Sequenz von Punkten, verbunden durch Linien/Kurven
- Bézierkurven: Quadratisch (3 Kontrollpunkte), Kubisch (4 Kontrollpunkte)
- Formen: Rechteck, Ellipse, Polygon (intern als Pfade)
SVG-SYNTAX Beispiele:
- <rect x="0" y="0" width="100" height="50"/>
- <circle cx="50" cy="50" r="25"/>
- <path d="M 0 0 L 100 100"/> (MoveTo, LineTo)
BERECHNUNG: Kreis mit r=40 → Fläche = π×40² ≈ 5.027 Pixel vs. 3 Parameter
RENDERING-PIPELINE: Vector → Tessellation → Rasterization → Framebuffer
FORMATE:
- SVG: XML-basiert, Web-Standard, editierbar
- PDF: Seiten-Beschreibungssprache, Vektoren + Raster gemischt
- AI/EPS: Adobe-proprietär, Druckvorstufe
PRÜFUNGSRELEVANT: Warum Vektoren skalierbar, SVG-Grundsyntax, Rendering-Pipeline
-->

---

<!-- _class: klausur -->
<!-- _footer: '' -->

# Raster vs. Vektor: Entscheidungskriterien

| Kriterium | Raster | Vektor |
|---|---|---|
| **Speicherung** | Pixelmatrix | Geometrie + Attribute |
| **Skalierung** | Qualitätsverlust | Verlustfrei |
| **Komplexität** | O(Breite × Höhe) | O(Anzahl Objekte) |
| **Bearbeitung** | Pixelbasiert | Objektbasiert |

**Wann Raster?** Fotos, Texturen, komplexe Farbverläufe
**Wann Vektor?** Logos, Icons, Typografie, technische Zeichnungen

**Konvertierung:**
- Raster → Vektor: Tracing (verlustbehaftet, approximiert)
- Vektor → Raster: Rasterisierung (exakt, aber auflösungsgebunden)

<!--
KOMPLEXITÄT erklärt:
- Raster O(w×h): Speicher wächst mit Pixelanzahl
- Vektor O(n): Speicher wächst mit Objektanzahl
BEISPIEL: Foto einer Wiese
- Raster: 1920×1080 = 2 Mio. Pixel, komprimiert ~500 KB
- Vektor: Jeder Grashalm ein Pfad → Millionen Objekte, unkomprimierbar
KONVERTIERUNG:
- Raster→Vektor (Tracing): Kantenerkennung, verlustbehaftet
  - Tools: Potrace (Open Source), Adobe Live Trace, Inkscape
  - Funktioniert gut: Logos, Zeichnungen, Text
  - Funktioniert schlecht: Fotos, Farbverläufe
- Vektor→Raster (Rasterisierung): Exakt, aber Auflösung fixiert
  - Jeder Bildschirm macht das (GPU)
  - Export: "Auflösung" wählen = Ziel-Pixelgröße
ENTSCHEIDUNGSBAUM:
- Foto/Screenshot? → Raster
- Logo/Icon/Diagramm? → Vektor
- Druckvorlage? → Vektor (Auflösungsunabhängig)
- Web-Animation? → SVG (Vektor) oder Video (Raster)
PRÜFUNGSRELEVANT: Wann welches Format, Konvertierungsrichtungen und deren Eigenschaften
-->

---

# 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: '' -->

![bg](./assets/jpeg-artifacts.png)

<!--
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: '' -->

![bg](./assets/gif-animation.png)

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

<!-- 
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: '' -->

![bg](./assets/instagram-quality-loss.png)

<!--
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: '' -->

![bg](./assets/netflix-4k.png)

<!-- 
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: '' -->

![bg](./assets/container-codec-diagram.png)

<!-- 
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: '' -->

![bg](./assets/iframe-pframe-diagram.png)

<!-- 
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: '' -->

![bg](./assets/youtube-vp9.png)

<!-- 
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: '' -->

![bg](./assets/av1-logo.png)

<!-- 
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: '' -->

![bg](./assets/streaming-quality-switch.png)

<!-- 
Visualisierung: Qualitätswechsel während Playback
Bandbreite schwankt → Player reagiert
-->

---

# Container im Detail

**MP4:** Standard für Web/Mobile, DRM-fähig (H.264, H.265, AV1)

**MKV:** Open Source, beliebig viele Spuren (fast jeder 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):**

**Tools:**
- Desktop: FFmpeg, HandBrake, [MediaInfo](https://mediaarea.net/MediaInfoOnline)
- Browser: [Squoosh.app](https://squoosh.app) (Bilder), [MediaInfo Online](https://mediaarea.net/MediaInfoOnline)
- iOS/Android: MediaInfo App, VLC

1. Download: CC-Video (Big Buck Bunny, ~1 Min)
2. Analysiere: Container, Codec, Bitrate, Auflösung
3. Konvertiere: H.264 vs. H.265 (gleiche Qualität)
4. Vergleiche: Größen, Encoding-Zeit

<!-- 
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/