rebuild dev and build system with single marp server
- simplify development: single marp server on port 3000 instead of 3 processes - rename klausur to klausurfolien for better naming - update extract script to use 00-intro.md as template when no 01-*.md exists - update makefile and package.json for new workflow - add comprehensive AGENTS.md guidelines
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -1,563 +0,0 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
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 -->
|
||||
|
||||
|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Verlustfrei vs. Verlustbehaftet
|
||||
|
||||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||||
|---|---|---|
|
||||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
|
||||
| **Reduktion** | 30-50% | 80-99% |
|
||||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||||
|
||||
**Faustregel:**
|
||||
- Medien für Endnutzer → Lossy oft akzeptabel
|
||||
- Quellmaterial, Code, Archive → Lossless nötig
|
||||
|
||||
<!--
|
||||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||||
|
||||
KLAUSURRELEVANT:
|
||||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Dateneinheiten
|
||||
|
||||
| Einheit | Bytes | Potenz | Beispiel |
|
||||
|---------|------:|:------:|----------|
|
||||
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||||
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||||
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
|
||||
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
|
||||
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
|
||||
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
|
||||
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||||
|
||||
<!--
|
||||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||||
1 TB Festplatte = ~931 GiB nutzbar
|
||||
|
||||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Der digitale Wendepunkt
|
||||
|
||||
| Jahr | Analog | Digital | Digital-Anteil |
|
||||
|------|--------|---------|----------------|
|
||||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||||
| **2007** | 18 EB | 277 EB | **94%** |
|
||||
|
||||
**Perspektive:**
|
||||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||||
- 2025: ~181 Zettabyte jährlich produziert
|
||||
|
||||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||||
|
||||
<!--
|
||||
PRÜFUNGSRELEVANT:
|
||||
- Wendepunkt 2002
|
||||
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
|
||||
- Magnetband als Archivmedium
|
||||
|
||||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||||
|
||||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||||
|
||||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||||
|
||||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||||
|
||||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||||
|
||||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
|
||||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Analoge Medien
|
||||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||||
|
||||
- **Text**
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
- **Bild**
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
- **Audio:**
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
- **Video:**
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Medien
|
||||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||||
|
||||
- **Text**
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
- **Bild**
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
- **Audio**
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
- **Video**
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Speichermedien
|
||||
|
||||
- **Optische Speicher**
|
||||
- CD, DVD, Blu-ray
|
||||
- **Magnetische Speicher**
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
- **Flash-Speicher**
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
- **Cloud-Speicher**
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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 |
|
||||
|
||||
<!--
|
||||
BERECHNUNG: 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
|
||||
- 8 Bit: 2^8 = 256 Farben
|
||||
- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
|
||||
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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 nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
|
||||
|
||||
<!--
|
||||
Vektorgrafiken beschreiben WAS gezeichnet werden soll.
|
||||
Rastergrafiken beschreiben WIE jeder Pixel aussieht.
|
||||
|
||||
Rendering-Pipeline:
|
||||
Vektordaten → Rasterisierung → Framebuffer → Display
|
||||
|
||||
Beim Skalieren werden einfach die Koordinaten multipliziert.
|
||||
Keine Information geht verloren.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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 (aber Helligkeit behalten)
|
||||
- Glatte Flächen effizient speichern
|
||||
- Hohe Frequenzen (Details) verwerfen
|
||||
|
||||
<!--
|
||||
Das ist die visuelle Entsprechung zur Psychoakustik.
|
||||
|
||||
Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
|
||||
als für Farbe (Zapfen).
|
||||
|
||||
Hohe Frequenzen = schnelle Wechsel = feine Details
|
||||
Niedrige Frequenzen = langsame Wechsel = große Flächen
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
|
||||
|
||||
# JPEG: Schritt 1 – Farbraumkonversion
|
||||
|
||||
**RGB → Y'CbCr** (seltener Y'UV)
|
||||
|
||||
- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
|
||||
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
|
||||
- **Cr** = Rot-Grün-Anteil (Chrominanz)
|
||||
|
||||
**Warum diese Trennung?**
|
||||
Y (Helligkeit) behält volle Auflösung.
|
||||
Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
|
||||
|
||||
<!--
|
||||
YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
|
||||
Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
|
||||
|
||||
Die Umrechnung ist reversibel (mathematische Transformation).
|
||||
Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# JPEG: Schritt 6 – Huffman-Coding
|
||||
|
||||
**Verlustfreie Kompression der Restwerte**
|
||||
|
||||
**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
|
||||
Häufige Werte bekommen kurze Bit-Sequenzen.
|
||||
|
||||
| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
|
||||
|---------|------------|------|
|
||||
| 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 ist verlustfrei.
|
||||
Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
|
||||
Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Container und Codec
|
||||
|
||||
**Container = Das Dateiformat (Beispiel: MP4)**
|
||||
Die "Box", die verschiedene Streams zusammenpackt:
|
||||
- Video-Stream
|
||||
- Audio-Stream(s)
|
||||
- Untertitel
|
||||
- Metadaten
|
||||
|
||||
**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
|
||||
Entscheidet, WIE komprimiert wird.
|
||||
|
||||
|
||||
<!--
|
||||
Container ≠ Codec
|
||||
Das ist ein häufiges Missverständnis.
|
||||
|
||||
MP4 ist ein Container, nicht ein Codec.
|
||||
Ein MP4 kann H.264, H.265 oder AV1 enthalten.
|
||||
|
||||
Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
|
||||
Bei Bildern fallen Container und Codec oft zusammen.
|
||||
|
||||
Tools wie MediaInfo zeigen beide Informationen.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# H.264 / AVC
|
||||
|
||||
**Advanced Video Coding (2003)**
|
||||
|
||||
**Warum dominant?**
|
||||
- Exzellente Kompression (~100:1 möglich)
|
||||
- Hardware-Support 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 Block-Artefakte)
|
||||
|
||||
<!--
|
||||
H.264 revolutionierte Video-Streaming.
|
||||
Ohne H.264 kein Netflix, kein YouTube in HD.
|
||||
|
||||
Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
|
||||
Selbst billige 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 und Netflix nutzen AV1 für 4K/8K
|
||||
Hardware-Encoder in aktuellen GPUs
|
||||
|
||||
<!--
|
||||
AOM = Alliance for Open Media, gegründet 2015.
|
||||
Historisch: Konkurrierende Tech-Giganten vereint.
|
||||
|
||||
Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
|
||||
|
||||
Problem: Encoding ist sehr langsam (10-100× vs. H.264).
|
||||
Hardware-Encoder lösen das zunehmend.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
458
slides/223015b/klausurfolien.md
Normal file
458
slides/223015b/klausurfolien.md
Normal file
@@ -0,0 +1,458 @@
|
||||
---
|
||||
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 -->
|
||||
|
||||
|
||||
|
||||
# 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: "" -->
|
||||
|
||||
|
||||
|
||||
|
||||
# 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
|
||||
-->
|
||||
Reference in New Issue
Block a user