---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
title: 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: #1a1a2e;
  color: #5fb3e4;
  padding: 0.15em 0.4em;
  border-radius: 4px;
}
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;
}
</style>

<!--
  ╔═══════════════════════════════════════════════════════════════════╗
  ║  AUTO-GENERATED FILE - DO NOT EDIT MANUALLY                       ║
  ║                                                                   ║
  ║  This file is generated by: make klausur                          ║
  ║  Source: scripts/extract-klausur.sh                               ║
  ║                                                                   ║
  ║  To update, edit the source slides and re-run make klausur        ║
  ╚═══════════════════════════════════════════════════════════════════╝
-->

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

![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)

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


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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Vektorgrafiken

**Speicherung als geometrische Primitive:**
- Pfade (Bézierkurven mit Kontrollpunkten)
- Grundformen (Rechteck, Ellipse, Polygon)
- Text (Glyphen als Outlines)

**SVG-Beispiel:**
```xml
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
```

<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# 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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


![bg right:20%](./assets/Barn-yuv.png)

# 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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# 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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# 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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# 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

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


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Wann HDD, wann SSD?

| Anwendung | Empfehlung |
|-----------|------------|
| Betriebssystem | SSD (NVMe) |
| Anwendungen, Spiele | SSD |
| Video-Editing (Projekte) | SSD |
| Foto-Archiv | HDD oder SSD |
| Backup | HDD |
| NAS / Server | HDD (oder Mix) |
| Cold Storage | HDD oder Band |

<!--
Die Faustregel:
- Oft genutzt, schnell gebraucht → SSD
- Selten genutzt, viel Kapazität → HDD

Viele setzen auf beides:
Kleine SSD für System + große HDD für Archiv.
-->


---

<!-- _header: "" -->
<!-- _footer: "" -->


# Die 3-2-1-Regel

**3** Kopien eurer Daten
(Original + 2 Backups)

**2** verschiedene Medientypen
(z.B. SSD + HDD, oder lokal + Cloud)

**1** Kopie an anderem Ort
(Offsite: Cloud, anderes Gebäude)

<!--
Herkunft: Peter Krogh, "The DAM Book" (2005)

Warum 3 Kopien?
- Original kann kaputt gehen
- Backup 1 auch
- Backup 2 = Sicherheitspuffer

Warum 2 Medientypen?
- Gleiche Medien haben gleiche Schwachstellen
- Batch-Fehler bei HDDs derselben Charge

Warum 1 Offsite?
- Brand/Wasserschaden zerstört alles vor Ort
- Ransomware verschlüsselt angeschlossene Laufwerke
-->