lecture-01 #1
@@ -0,0 +1,373 @@
|
||||
# Marp/Marpit Complete Reference
|
||||
|
||||
## Overview
|
||||
|
||||
**Marp** = Markdown Presentation Ecosystem
|
||||
**Marpit** = The core framework ("skinny framework for creating slide deck from Markdown")
|
||||
|
||||
Built-in themes: `default`, `gaia`, `uncover`
|
||||
|
||||
---
|
||||
|
||||
## Slide Structure
|
||||
|
||||
### Slide Separation
|
||||
Slides are separated by horizontal rulers:
|
||||
```markdown
|
||||
---
|
||||
```
|
||||
Alternatives: `___`, `***`, `- - -`
|
||||
|
||||
**Important**: May need empty line before `---` per CommonMark spec.
|
||||
|
||||
### Basic Document Structure
|
||||
```markdown
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
---
|
||||
|
||||
# First Slide
|
||||
|
||||
Content here
|
||||
|
||||
---
|
||||
|
||||
# Second Slide
|
||||
|
||||
More content
|
||||
|
||||
<!-- Speaker notes go here -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Directives
|
||||
|
||||
### Syntax Options
|
||||
|
||||
**HTML Comments:**
|
||||
```markdown
|
||||
<!-- theme: default -->
|
||||
<!-- paginate: true -->
|
||||
```
|
||||
|
||||
**Front-matter (YAML):**
|
||||
```markdown
|
||||
---
|
||||
theme: default
|
||||
paginate: true
|
||||
---
|
||||
```
|
||||
|
||||
### Directive Scopes
|
||||
|
||||
| Scope | Applies to | Syntax |
|
||||
|-------|-----------|--------|
|
||||
| Global | Entire deck | Normal directive |
|
||||
| Local | Current + following slides | Normal directive mid-document |
|
||||
| Spot | Single slide only | Underscore prefix: `_directive` |
|
||||
|
||||
### Global Directives
|
||||
- `theme` — Slide deck theme
|
||||
- `style` — Custom CSS
|
||||
- `lang` — Language attribute (accessibility)
|
||||
- `headingDivider` — Auto-split at heading levels (1-6)
|
||||
|
||||
### Local Directives
|
||||
- `paginate` — Page numbers (true/false/hold/skip)
|
||||
- `header` — Persistent header text
|
||||
- `footer` — Persistent footer text
|
||||
- `class` — CSS class for slide
|
||||
- `backgroundColor` — Slide background color
|
||||
- `backgroundImage` — Background image URL
|
||||
- `backgroundPosition` — CSS background-position
|
||||
- `backgroundRepeat` — CSS background-repeat
|
||||
- `backgroundSize` — CSS background-size
|
||||
- `color` — Text color
|
||||
|
||||
### Spot Directive Example
|
||||
```markdown
|
||||
<!-- _backgroundColor: aqua -->
|
||||
<!-- _class: lead -->
|
||||
```
|
||||
Only affects current slide.
|
||||
|
||||
### Pagination Values
|
||||
- `true` — Show and increment
|
||||
- `false` — Hide but increment
|
||||
- `hold` — Show without incrementing
|
||||
- `skip` — Hide without incrementing
|
||||
|
||||
### Heading Divider
|
||||
```markdown
|
||||
---
|
||||
headingDivider: 2
|
||||
---
|
||||
|
||||
# Section 1
|
||||
Content
|
||||
|
||||
## Slide 1.1 <!-- auto slide break -->
|
||||
Content
|
||||
|
||||
## Slide 1.2 <!-- auto slide break -->
|
||||
Content
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Image Syntax
|
||||
|
||||
### Basic Resizing
|
||||
```markdown
|
||||
 <!-- width 200px -->
|
||||
 <!-- height 300px -->
|
||||
 <!-- both -->
|
||||
```
|
||||
|
||||
Units: px, em, cm, pt, etc. (no viewport units vw/vh)
|
||||
|
||||
### Image Filters
|
||||
```markdown
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
Combine multiple:
|
||||
```markdown
|
||||
|
||||
```
|
||||
|
||||
### Background Images
|
||||
```markdown
|
||||
 <!-- full background -->
|
||||
 <!-- contain/fit -->
|
||||
 <!-- cover (default) -->
|
||||
 <!-- original size -->
|
||||
 <!-- scale percentage -->
|
||||
```
|
||||
|
||||
### Split Backgrounds
|
||||
```markdown
|
||||
 <!-- left half -->
|
||||
 <!-- right half -->
|
||||
 <!-- custom split -->
|
||||
|
||||
```
|
||||
|
||||
### Multiple Backgrounds
|
||||
```markdown
|
||||
|
||||
|
||||
|
||||
```
|
||||
Arranges horizontally by default.
|
||||
|
||||
```markdown
|
||||
|
||||
|
||||
```
|
||||
Arranges vertically.
|
||||
|
||||
---
|
||||
|
||||
## Fragmented Lists (Animations)
|
||||
|
||||
### Bullet Lists — Use `*`
|
||||
```markdown
|
||||
* First item <!-- reveals first -->
|
||||
* Second item <!-- reveals second -->
|
||||
* Third item <!-- reveals third -->
|
||||
```
|
||||
|
||||
Regular `-` or `+` bullets don't animate.
|
||||
|
||||
### Ordered Lists — Use `)`
|
||||
```markdown
|
||||
1) First item
|
||||
2) Second item
|
||||
3) Third item
|
||||
```
|
||||
|
||||
Regular `.` numbered lists don't animate.
|
||||
|
||||
### Output
|
||||
```html
|
||||
<li data-marpit-fragment="1">First</li>
|
||||
<li data-marpit-fragment="2">Second</li>
|
||||
```
|
||||
|
||||
**Note**: Actual animation depends on presentation viewer.
|
||||
|
||||
---
|
||||
|
||||
## Theme CSS
|
||||
|
||||
### Required Metadata
|
||||
```css
|
||||
/* @theme my-theme */
|
||||
```
|
||||
|
||||
### Core Selectors
|
||||
```css
|
||||
/* Slide container */
|
||||
section {
|
||||
width: 1280px;
|
||||
height: 720px;
|
||||
font-size: 32px;
|
||||
}
|
||||
|
||||
/* Higher specificity alternative */
|
||||
:root {
|
||||
--color-primary: #3498db;
|
||||
}
|
||||
|
||||
/* Pagination */
|
||||
section::after {
|
||||
content: attr(data-marpit-pagination) ' / ' attr(data-marpit-pagination-total);
|
||||
}
|
||||
```
|
||||
|
||||
### Scoped Styles
|
||||
```markdown
|
||||
<style scoped>
|
||||
/* Only this slide */
|
||||
h1 { color: red; }
|
||||
</style>
|
||||
```
|
||||
|
||||
### Global Inline Styles
|
||||
```markdown
|
||||
<style>
|
||||
/* All slides */
|
||||
section { background: #f0f0f0; }
|
||||
</style>
|
||||
```
|
||||
|
||||
### Theme Inheritance
|
||||
```css
|
||||
/* @theme derived-theme */
|
||||
@import 'default';
|
||||
/* or */
|
||||
@import-theme 'default';
|
||||
```
|
||||
|
||||
### Units
|
||||
- `rem` scales relative to slide `<section>` (isolated from HTML root)
|
||||
- Slide dimensions require absolute units (px, cm, in, mm)
|
||||
|
||||
---
|
||||
|
||||
## Marp CLI
|
||||
|
||||
### Installation
|
||||
```bash
|
||||
npm install -g @marp-team/marp-cli
|
||||
# or
|
||||
brew install marp-cli
|
||||
```
|
||||
|
||||
### Basic Conversion
|
||||
```bash
|
||||
marp slide.md # → HTML
|
||||
marp --pdf slide.md # → PDF
|
||||
marp --pptx slide.md # → PowerPoint
|
||||
marp --images png slide.md # → PNG images
|
||||
```
|
||||
|
||||
### Development Server
|
||||
```bash
|
||||
marp --server ./slides/
|
||||
PORT=1312 marp --server ./
|
||||
```
|
||||
|
||||
Query formats: `http://localhost:8080/deck.md?pdf`
|
||||
|
||||
### Watch Mode
|
||||
```bash
|
||||
marp --watch slide.md
|
||||
```
|
||||
|
||||
### Key Options
|
||||
```bash
|
||||
-o, --output <file> # Output path
|
||||
-w, --watch # Watch for changes
|
||||
-s, --server # HTTP server mode
|
||||
-p, --preview # Open preview window
|
||||
--pdf # PDF output
|
||||
--pptx # PowerPoint output
|
||||
--images [png|jpeg] # Image output
|
||||
--image-scale <n> # Resolution (e.g., 2 for 2x)
|
||||
--allow-local-files # Enable local file access (security risk)
|
||||
--pdf-notes # Include speaker notes in PDF
|
||||
--browser <name> # chrome, edge, firefox
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Title Slide
|
||||
```markdown
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Presentation Title
|
||||
|
||||
**Author Name**
|
||||
Date
|
||||
```
|
||||
|
||||
### Two-Column Layout (via background)
|
||||
```markdown
|
||||
|
||||
|
||||
# Right Content
|
||||
|
||||
Text appears on right side
|
||||
```
|
||||
|
||||
### Speaker Notes
|
||||
```markdown
|
||||
# Slide Title
|
||||
|
||||
Content
|
||||
|
||||
<!--
|
||||
These are speaker notes.
|
||||
Not visible in slides.
|
||||
Visible in presenter mode.
|
||||
-->
|
||||
```
|
||||
|
||||
### Custom Class
|
||||
```markdown
|
||||
<!-- _class: centered dark -->
|
||||
|
||||
# Centered Dark Slide
|
||||
```
|
||||
|
||||
Then in CSS/theme:
|
||||
```css
|
||||
section.centered { text-align: center; }
|
||||
section.dark { background: #222; color: #fff; }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Project Conventions (This Project)
|
||||
|
||||
- Theme: `gaia`
|
||||
- Assets: `./assets/filename.png`
|
||||
- Build output: `build/`
|
||||
- Dev server: `make dev` (port 1312)
|
||||
- Never end with `---` (creates empty slide)
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
name: marp
|
||||
description: Marp/Marpit documentation and slide creation guide. Use this skill when working with Marp presentations, slide syntax, themes, directives, or troubleshooting Marp-related issues.
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Glob
|
||||
- Grep
|
||||
- WebFetch
|
||||
---
|
||||
|
||||
# Marp/Marpit Skill
|
||||
|
||||
## Purpose
|
||||
|
||||
This skill provides comprehensive knowledge about Marp (Markdown Presentation Ecosystem) and its core engine Marpit. Use this when creating, editing, or troubleshooting Markdown-based slide presentations.
|
||||
|
||||
## Documentation Sources
|
||||
|
||||
When you need Marp information, fetch from these official sources:
|
||||
|
||||
### Marpit Framework (Core Engine)
|
||||
- **Main docs**: https://marpit.marp.app/
|
||||
- **Markdown syntax**: https://marpit.marp.app/markdown
|
||||
- **Directives**: https://marpit.marp.app/directives
|
||||
- **Theme CSS**: https://marpit.marp.app/theme-css
|
||||
- **Fragmented list**: https://marpit.marp.app/fragmented-list
|
||||
- **Image syntax**: https://marpit.marp.app/image-syntax
|
||||
|
||||
### Marp CLI
|
||||
- **Usage guide**: https://github.com/marp-team/marp-cli
|
||||
|
||||
## Key Concepts to Learn
|
||||
|
||||
### 1. Slide Separation
|
||||
Slides are separated by `---` (horizontal rule). The first `---` after frontmatter starts the first slide.
|
||||
|
||||
### 2. Directives
|
||||
- **Global directives**: Apply to all slides (in frontmatter)
|
||||
- **Local directives**: Apply to current slide only (`<!-- _directive: value -->`)
|
||||
- **Spot directives**: Underscore prefix for local scope
|
||||
|
||||
### 3. Image Syntax
|
||||
Marp extends standard Markdown image syntax:
|
||||
- `` - background image
|
||||
- `` - fit to slide
|
||||
- `` - split background
|
||||
- `` - width filter
|
||||
- `` - height filter
|
||||
|
||||
### 4. Theme CSS
|
||||
- Themes use CSS with special Marpit selectors
|
||||
- `section` = slide container
|
||||
- `section::after` = pagination
|
||||
- CSS variables for theming
|
||||
|
||||
### 5. Scoped Styles
|
||||
```html
|
||||
<style scoped>
|
||||
/* Only applies to this slide */
|
||||
</style>
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
When asked about Marp:
|
||||
|
||||
1. **Read REFERENCE.md first** - Contains comprehensive syntax documentation
|
||||
2. **Check local files** - Read existing slides and themes in the project
|
||||
3. **Fetch official docs if needed** - Use WebFetch for edge cases
|
||||
4. **Provide concrete examples** - Show actual Marp syntax
|
||||
5. **Reference project conventions** - Follow CLAUDE.md guidelines
|
||||
|
||||
## Project-Specific Notes
|
||||
|
||||
This project uses:
|
||||
- Theme: `gaia`
|
||||
- Assets path: `./assets/`
|
||||
- Build output: `build/`
|
||||
- Dev server: `make dev` (port 1312)
|
||||
@@ -61,3 +61,5 @@ Desktop.ini
|
||||
*.html
|
||||
!build/*.html
|
||||
*.pdf
|
||||
index.md.bak
|
||||
hdm-lehrauftrag-uebersicht.md
|
||||
|
||||
@@ -6,6 +6,13 @@ This project builds a presentation deck for Marp based on Markdown files.
|
||||
- Agent NEVER runs commands on its own except changing files INSIDE THIS FOLDER, never any other then this
|
||||
- Agent NEVER runs build commands or any automated processes without explicit user request, as the user is working in dev mode
|
||||
|
||||
## Critical File Protection: index.md
|
||||
- `index.md` is the MAIN CONTENT FILE for the entire lecture series - treat with extreme care
|
||||
- ALLOWED: Adding new slides, adjusting existing content, fixing typos, enhancing sections
|
||||
- FORBIDDEN (without explicit permission): Deleting slides, removing sections, bulk replacements that remove content
|
||||
- Before ANY deletion in index.md: ALWAYS ask user for confirmation and warn about what will be removed
|
||||
- When in doubt, ADD rather than REPLACE - let the user decide what to remove
|
||||
|
||||
## Build Commands
|
||||
- `npm run build` - Build slides from Markdown using Marp
|
||||
- `npm run dev` - Start development server at http://localhost:8080
|
||||
|
||||
+319
@@ -0,0 +1,319 @@
|
||||
# Image List for HdM Dateiformate Slides
|
||||
|
||||
This document lists all images needed for the lecture slides. Each image includes:
|
||||
- **Filename**: Target filename in `./assets/`
|
||||
- **Context**: Where/why it's used in the slides
|
||||
- **AI Prompt**: Suggested prompt for image generation (Gemini, DALL-E, Midjourney, etc.)
|
||||
|
||||
**Recommended settings:**
|
||||
- Aspect ratio: 16:9 (1920x1080 or similar)
|
||||
- Style: Clean, professional, educational
|
||||
- For logos: Consider downloading official versions from the web instead of generating
|
||||
|
||||
**Legend:**
|
||||
- ✅ = Already generated and in assets/
|
||||
- ⬚ = Not yet generated
|
||||
|
||||
---
|
||||
|
||||
## Intro
|
||||
|
||||
### ✅ digital-landscape.png
|
||||
- **Context**: Opening slide background, sets futuristic tech mood
|
||||
- **AI Prompt**: Futuristic digital landscape with glowing blue and purple data streams, abstract network connections, binary patterns flowing through a neon-lit cyber environment, wide cinematic shot, no text
|
||||
|
||||
---
|
||||
|
||||
## Termin 1: Grundlagen, Text & Audio
|
||||
|
||||
### ✅ matrix-code.png
|
||||
- **Context**: Opening visual for "WTF!?" hex dump slide
|
||||
- **AI Prompt**: Matrix-style green digital rain code falling on black background, glowing green characters, cyberpunk hacker aesthetic, mysterious data visualization
|
||||
|
||||
### ✅ lightbulb-onoff.png
|
||||
- **Context**: Explaining the bit concept (0 or 1, on or off)
|
||||
- **AI Prompt**: Simple lightbulb comparison: one lit bright yellow, one dark/off, side by side, clean minimal style, binary concept visualization, white background
|
||||
|
||||
### ✅ grayscale-gradient.png ⚠️ NEEDS REGENERATION
|
||||
- **Context**: Explaining 256 grayscale values (0=black to 255=white)
|
||||
- **AI Prompt**: Horizontal grayscale gradient bar on a neutral gray background (#808080), gradient goes from pure black (left) to pure white (right), add visible value labels "0" on left and "255" on right, ensure edges are clearly visible against background, clean educational diagram style, 16:9 aspect ratio
|
||||
- **Issue**: Current image has barely visible edges on left (black) and right (white) sides
|
||||
|
||||
### ✅ rgb-color-model.png
|
||||
- **Context**: Explaining RGB color model (3 bytes per pixel)
|
||||
- **AI Prompt**: RGB color model visualization showing three overlapping circles (red, green, blue) creating cyan, magenta, yellow, and white in overlaps, clean educational diagram style
|
||||
|
||||
### ✅ ascii-table.png
|
||||
- **Context**: Showing ASCII character encoding (7-bit, 128 characters total)
|
||||
- **AI Prompt**: Clean ASCII table showing printable characters 32-126 with their decimal and hex values, vintage computer terminal aesthetic, green on black or clean white background, educational reference chart. Note: ASCII is 7-bit encoding with 128 total characters (0-127), not 256. First 32 (0-31) are control characters, 127 is DEL.
|
||||
|
||||
### ✅ hex-binary-table.png
|
||||
- **Context**: Hex to binary conversion reference
|
||||
- **AI Prompt**: Clean conversion table showing hexadecimal digits 0-F with their 4-bit binary equivalents, educational reference style, programmer cheat sheet aesthetic
|
||||
|
||||
### ✅ hexeditor-screenshot.png
|
||||
- **Context**: Showing what a hex editor looks like
|
||||
- **AI Prompt**: Screenshot of hex editor software showing file bytes in hexadecimal with ASCII representation on the right side, typical hex editor layout, technical software interface
|
||||
|
||||
### ✅ cassette-ipod.png
|
||||
- **Context**: Audio format evolution intro
|
||||
- **AI Prompt**: Vintage audio cassette tape next to modern iPod or MP3 player, technology evolution comparison, nostalgic meets modern, clean product photography style
|
||||
|
||||
### ✅ compression-types.png
|
||||
- **Context**: Lossless vs lossy compression comparison
|
||||
- **AI Prompt**: Split diagram comparing lossless (ZIP icon, identical files) vs lossy (JPEG/MP3 icon, smaller but different), educational infographic style, clear visual distinction
|
||||
|
||||
### ✅ karlheinz-brandenburg.jpg
|
||||
- **Context**: MP3 inventor portrait/reference (Fraunhofer IIS)
|
||||
- **AI Prompt**: Professional portrait style of a German scientist/engineer in academic setting, Fraunhofer institute aesthetic, 1990s technology pioneer look (or use real photo)
|
||||
|
||||
### ✅ suzanne-vega.jpg
|
||||
- **Context**: "Tom's Diner" - the song used to test MP3 compression
|
||||
- **AI Prompt**: Female singer-songwriter aesthetic, acoustic guitar, 1980s folk music style, intimate cafe performance setting (or use real photo)
|
||||
|
||||
### ✅ audio-spectrogram.png
|
||||
- **Context**: Visualizing audio frequencies and MP3 compression effects
|
||||
- **AI Prompt**: Colorful audio spectrogram visualization showing frequency spectrum over time, rainbow gradient from low (red) to high (blue) frequencies, scientific audio analysis display
|
||||
|
||||
### ✅ napster-interface.png
|
||||
- **Context**: MP3 piracy era / file sharing history (1999-2001)
|
||||
- **AI Prompt**: Late 1990s peer-to-peer file sharing interface aesthetic, Windows 98/2000 style dialog boxes, music file listings, nostalgic internet era, retro software UI
|
||||
|
||||
---
|
||||
|
||||
## Termin 2: Bild, Audio, Video
|
||||
|
||||
### ✅ photo-comparison.png
|
||||
- **Context**: Demonstrating compression quality loss
|
||||
- **AI Prompt**: Side-by-side comparison of same landscape photo: left side crystal clear high resolution, right side heavily compressed with visible JPEG artifacts, blocky pixels and color banding, split down the middle, educational comparison style
|
||||
|
||||
### ✅ jpeg-artifacts.png
|
||||
- **Context**: Close-up example of JPEG compression artifacts
|
||||
- **AI Prompt**: Close-up macro shot of heavily compressed JPEG image showing visible compression artifacts, blocky 8x8 pixel blocks, mosquito noise around edges, color banding in gradients, technical demonstration image
|
||||
|
||||
### ✅ gif-animation.png
|
||||
- **Context**: Explaining GIF format limitations
|
||||
- **AI Prompt**: Classic internet aesthetic image with limited color palette (256 colors), dithering patterns visible, retro web 1.0 style, simple animation frames concept, nostalgic internet culture
|
||||
|
||||
### ✅ instagram-quality-loss.png
|
||||
- **Context**: Real-world example of social media compression
|
||||
- **AI Prompt**: Split image comparison: left side showing original crisp smartphone photo, right side showing same image after social media upload with visible quality degradation, compression artifacts, softer details, educational before/after style
|
||||
|
||||
### ✅ netflix-4k.png
|
||||
- **Context**: Modern streaming technology introduction
|
||||
- **AI Prompt**: Modern living room with large OLED TV displaying streaming interface, 4K UHD quality visible, cozy home theater setup, ambient lighting, contemporary interior design, cinematic wide shot
|
||||
|
||||
### ✅ container-codec-diagram.png
|
||||
- **Context**: Explaining video container vs codec concept
|
||||
- **AI Prompt**: Clean technical diagram showing video container structure as a box containing separate colored tracks: video stream (blue), audio stream (green), subtitle stream (yellow), metadata (gray), arrows showing data flow, minimal infographic style, white background
|
||||
|
||||
### ✅ iframe-pframe-diagram.png
|
||||
- **Context**: Video compression frame types explanation
|
||||
- **AI Prompt**: Technical diagram showing video compression frame sequence: large I-frame (keyframe) in blue, smaller P-frames (predicted) in green, tiny B-frames (bidirectional) in orange, arrows showing dependencies between frames, timeline visualization, clean educational style
|
||||
|
||||
### ✅ youtube-vp9.png
|
||||
- **Context**: VP9 codec discussion
|
||||
- **AI Prompt**: YouTube video player interface with VP9 codec indicator, stats for nerds overlay showing codec information, modern streaming technology aesthetic, screen capture style
|
||||
|
||||
### ✅ av1-logo.png
|
||||
- **Context**: AV1 codec introduction
|
||||
- **AI Prompt**: AV1 video codec logo visualization, Alliance for Open Media branding, clean modern tech logo style, blue and white color scheme, professional technology branding
|
||||
|
||||
### ✅ streaming-quality-switch.png
|
||||
- **Context**: Adaptive bitrate streaming explanation
|
||||
- **AI Prompt**: Visualization of adaptive bitrate streaming: video player with quality indicator showing switch from 480p to 720p to 1080p, buffer loading bar, bandwidth graph in corner, technical streaming diagram style
|
||||
|
||||
---
|
||||
|
||||
## Termin 3: Speichermedien & Schnittstellen
|
||||
|
||||
### ⬚ hdd-ssd-comparison.png
|
||||
- **Context**: Storage technology comparison
|
||||
- **AI Prompt**: Side-by-side comparison: opened hard disk drive showing silver platters and read/write head on left, modern NVMe SSD circuit board with flash chips on right, technical product photography, white background, educational comparison
|
||||
|
||||
### ⬚ directory-tree.png
|
||||
- **Context**: File system structure explanation
|
||||
- **AI Prompt**: File system directory tree visualization, hierarchical folder structure with branching paths, root folder at top expanding into subdirectories, clean diagram style with folder icons, blue and gray color scheme, technical illustration
|
||||
|
||||
### ⬚ backup-disaster.png
|
||||
- **Context**: Importance of backups - cautionary tale
|
||||
- **AI Prompt**: Dramatic scene of broken hard drive with visible damage, smoke rising, concerned person in background looking at computer screen showing error message, data loss disaster concept, moody lighting, cautionary illustration style
|
||||
|
||||
### ⬚ bit-rot.png
|
||||
- **Context**: Data degradation over time
|
||||
- **AI Prompt**: Abstract visualization of digital decay: image gradually corrupting from left to right, pixels breaking apart, glitch effects spreading, data entropy concept, corrupted file aesthetic, technical art style
|
||||
|
||||
### ⬚ lto-tape.png
|
||||
- **Context**: Professional archival storage
|
||||
- **AI Prompt**: LTO tape cartridge in professional data center setting, tape drive unit visible, blue and black enterprise storage equipment, clean technical product shot, professional backup infrastructure
|
||||
|
||||
### ⬚ m-disc.png
|
||||
- **Context**: Long-term optical storage
|
||||
- **AI Prompt**: M-DISC optical disc showing distinctive gold/bronze reflective surface, archival grade media, jewel case partially visible, product photography style, emphasis on durability and longevity
|
||||
|
||||
### ⬚ dna-helix.png
|
||||
- **Context**: Future storage technology
|
||||
- **AI Prompt**: DNA double helix structure with binary code (0s and 1s) integrated into the strand pattern, futuristic data storage concept, blue bioluminescent glow, science fiction meets biology, clean dark background
|
||||
|
||||
### ⬚ cable-mess.png
|
||||
- **Context**: Cable/connector chaos problem
|
||||
- **AI Prompt**: Chaotic tangle of various cables: USB-A, USB-C, HDMI, DisplayPort, Lightning, micro-USB, all intertwined in frustrating mess, cable drawer chaos, relatable tech problem, overhead shot
|
||||
|
||||
### ⬚ pc-back-1990s.png
|
||||
- **Context**: Legacy port evolution
|
||||
- **AI Prompt**: Back panel of vintage 1990s beige desktop PC showing rainbow of legacy ports: blue VGA, green/purple PS/2, gray serial DB9, pink parallel DB25, game port, nostalgic retro computing, authentic vintage tech
|
||||
|
||||
### ⬚ usb-c-cables.png
|
||||
- **Context**: USB-C confusion (same connector, different specs)
|
||||
- **AI Prompt**: Five identical-looking USB-C cables laid out in a row, all appearing the same but with subtle question marks or spec labels (USB 2.0, 3.0, 3.1, Thunderbolt, charging only), consumer confusion concept, clean product shot
|
||||
|
||||
### ⬚ thunderbolt-logo.png
|
||||
- **Context**: Thunderbolt interface explanation
|
||||
- **AI Prompt**: Thunderbolt technology logo, stylized lightning bolt symbol, Intel branding aesthetic, clean modern tech logo on dark background, high-speed connection concept
|
||||
|
||||
### ⬚ hdmi-cable.png
|
||||
- **Context**: HDMI interface explanation
|
||||
- **AI Prompt**: HDMI cable with gold-plated connector in sharp focus, premium build quality visible, professional AV equipment aesthetic, product photography on neutral background
|
||||
|
||||
### ⬚ displayport-cable.png
|
||||
- **Context**: DisplayPort interface explanation
|
||||
- **AI Prompt**: DisplayPort cable and connector close-up, distinctive asymmetrical shape visible, professional display connection, technical product photography, clean background
|
||||
|
||||
### ⬚ hdcp-warning.png
|
||||
- **Context**: DRM/content protection issues
|
||||
- **AI Prompt**: TV or monitor screen displaying HDCP error message dialog box, "Content Protection Error" or "HDCP not supported" warning, frustrated user experience, screen capture style, consumer electronics problem
|
||||
|
||||
### ⬚ ethernet-cable.png
|
||||
- **Context**: Network connectivity
|
||||
- **AI Prompt**: Blue Ethernet cable with clear RJ45 connector showing gold pins, Cat6 or Cat7 network cable, technical product shot, networking infrastructure aesthetic
|
||||
|
||||
### ⬚ vintage-ports.png
|
||||
- **Context**: Legacy connector nostalgia/history
|
||||
- **AI Prompt**: Collection of vintage computer ports and connectors: VGA blue, PS/2 keyboard and mouse, serial DB9, parallel DB25, arranged like museum display, retro computing history, nostalgic tech photography
|
||||
|
||||
---
|
||||
|
||||
## Termin 4: Distribution, APIs, Zukunft
|
||||
|
||||
### ⬚ sneakernet-truck.png
|
||||
- **Context**: Physical data transport concept ("Never underestimate bandwidth of a truck full of tapes")
|
||||
- **AI Prompt**: Semi truck loaded with pallets of hard drives and storage media, highway background, humorous take on data transfer, "sneakernet" concept visualization, photorealistic style
|
||||
|
||||
### ⬚ aws-snowmobile.png
|
||||
- **Context**: AWS Snowmobile - extreme data transfer
|
||||
- **AI Prompt**: Large shipping container truck (semi-trailer) with data center branding, AWS style, massive scale data transfer concept, industrial tech photography
|
||||
|
||||
### ⬚ cd-dvd-bluray.png
|
||||
- **Context**: Physical media distribution history
|
||||
- **AI Prompt**: Three optical discs arranged showing evolution: CD, DVD, Blu-ray, each with distinctive colors/labels, product photography, media format comparison
|
||||
|
||||
### ⬚ server-overload.png
|
||||
- **Context**: "Hug of Death" / traffic spike problems
|
||||
- **AI Prompt**: Server rack with red warning lights flashing, smoke or heat waves rising, overwhelmed system visualization, too many connection requests flooding in as visual arrows, data center stress, dramatic lighting
|
||||
|
||||
### ⬚ cdn-map.png
|
||||
- **Context**: Content Delivery Network explanation
|
||||
- **AI Prompt**: World map with glowing nodes representing CDN edge locations, connection lines between points of presence, global content delivery network visualization, dark background with bright cyan/green nodes, tech infographic style
|
||||
|
||||
### ⬚ netflix-openconnect.png
|
||||
- **Context**: Netflix CDN case study
|
||||
- **AI Prompt**: Netflix Open Connect server appliance in ISP data center rack, red Netflix branding visible, professional server hardware, content delivery infrastructure, enterprise equipment photography
|
||||
|
||||
### ⬚ p2p-network.png
|
||||
- **Context**: Peer-to-peer architecture explanation
|
||||
- **AI Prompt**: Peer-to-peer network diagram showing decentralized mesh of connected computer nodes, no central server, all nodes equal, bidirectional arrows between peers, clean technical diagram style, blue network aesthetic
|
||||
|
||||
### ⬚ bittorrent-swarm.png
|
||||
- **Context**: BitTorrent technology explanation
|
||||
- **AI Prompt**: BitTorrent swarm visualization showing multiple peers exchanging colored file chunks/pieces, some peers have complete file (seeders), others downloading (leechers), piece availability concept, technical diagram style
|
||||
|
||||
### ⬚ pirate-bay-logo.png
|
||||
- **Context**: BitTorrent history/controversy discussion
|
||||
- **AI Prompt**: Pirate ship silhouette in vintage woodcut style, cassette tape as sail, controversial but historically significant internet culture reference, monochrome illustration style
|
||||
|
||||
### ⬚ ipfs-logo.png
|
||||
- **Context**: Decentralized storage future
|
||||
- **AI Prompt**: IPFS (InterPlanetary File System) logo concept, interconnected nodes forming globe shape, decentralized web aesthetic, teal/cyan color scheme, modern tech branding
|
||||
|
||||
### ⬚ streaming-hls.png
|
||||
- **Context**: HLS/DASH streaming protocols
|
||||
- **AI Prompt**: Streaming pipeline diagram: video encoder box connecting to CDN cloud connecting to multiple player devices, HLS/DASH segment chunks visualized as small boxes along the path, technical flowchart style
|
||||
|
||||
### ⬚ api-diagram.png
|
||||
- **Context**: API concept introduction
|
||||
- **AI Prompt**: Clean API diagram showing multiple application icons connected by arrows through central API gateway, request/response flow visualization, software integration concept, modern flat design infographic
|
||||
|
||||
### ⬚ http-request-response.png
|
||||
- **Context**: HTTP basics
|
||||
- **AI Prompt**: HTTP request/response cycle diagram: client computer on left, server on right, arrows showing GET request going right, response with data coming back left, status codes visible, clean technical illustration
|
||||
|
||||
### ⬚ rest-api.png
|
||||
- **Context**: REST architecture explanation
|
||||
- **AI Prompt**: REST API structure diagram showing resource URLs (/users, /posts, /comments) with HTTP methods (GET, POST, PUT, DELETE) color-coded, CRUD operations mapped, clean API documentation style
|
||||
|
||||
### ⬚ graphql-logo.png
|
||||
- **Context**: GraphQL introduction
|
||||
- **AI Prompt**: GraphQL logo, distinctive pink/magenta hexagonal shape, query language for APIs branding, modern tech aesthetic, clean vector style on dark background
|
||||
|
||||
### ⬚ websocket-diagram.png
|
||||
- **Context**: Real-time communication
|
||||
- **AI Prompt**: WebSocket vs HTTP comparison diagram: HTTP showing multiple request-response pairs, WebSocket showing single persistent bidirectional connection, real-time communication concept, technical comparison illustration
|
||||
|
||||
### ⬚ grpc-logo.png
|
||||
- **Context**: gRPC introduction
|
||||
- **AI Prompt**: gRPC logo, Google's RPC framework branding, blue and white color scheme, protocol buffers concept, modern microservices aesthetic, clean tech logo
|
||||
|
||||
### ⬚ exif-gps.png
|
||||
- **Context**: Metadata privacy concerns
|
||||
- **AI Prompt**: Smartphone photo with semi-transparent overlay showing EXIF metadata: GPS coordinates on map, camera model, date/time, exposure settings, privacy concern visualization, metadata exposure concept
|
||||
|
||||
### ⬚ mcafee-exif-fail.png
|
||||
- **Context**: Real-world EXIF privacy incident
|
||||
- **AI Prompt**: News headline style image about location data leak, map with pin showing exposed location, journalist camera icon, privacy fail case study concept, documentary style illustration
|
||||
|
||||
### ⬚ id3-tag-editor.png
|
||||
- **Context**: Audio metadata explanation
|
||||
- **AI Prompt**: Screenshot-style image of ID3 tag editor software interface showing MP3 metadata fields: title, artist, album, year, genre, track number, album art placeholder, music file management aesthetic
|
||||
|
||||
### ⬚ musicbrainz-logo.png
|
||||
- **Context**: Music metadata database
|
||||
- **AI Prompt**: MusicBrainz logo concept, music database branding, orange/yellow color scheme, open source music metadata project aesthetic
|
||||
|
||||
### ⬚ pdf-metadata-leak.png
|
||||
- **Context**: Document metadata privacy
|
||||
- **AI Prompt**: PDF document properties dialog showing hidden metadata: author name, creation date, software used, revision history, privacy concern visualization, document forensics concept
|
||||
|
||||
### ⬚ futuristic-datacenter.png
|
||||
- **Context**: Future of data storage intro
|
||||
- **AI Prompt**: Futuristic data center with glowing blue server racks, holographic displays, advanced cooling systems, sci-fi technology aesthetic, next-generation computing infrastructure
|
||||
|
||||
### ⬚ jpeg-xl-logo.png
|
||||
- **Context**: Next-gen image formats
|
||||
- **AI Prompt**: JPEG XL logo concept, modern image format branding, evolution of JPEG, clean tech logo style, future of image compression
|
||||
|
||||
### ⬚ dna-storage-concept.png
|
||||
- **Context**: DNA data storage future
|
||||
- **AI Prompt**: DNA strand with digital data visualization, binary code transforming into genetic sequence, futuristic biotechnology concept, scientific illustration style, data storage evolution
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
| Lecture | Total | ✅ Done | ⬚ Todo |
|
||||
|---------|-------|--------|--------|
|
||||
| Intro | 1 | 1 | 0 |
|
||||
| Termin 1 (Grundlagen/Text/Audio) | 13 | 13 | 0 |
|
||||
| Termin 2 (Bild/Audio/Video) | 10 | 10 | 0 |
|
||||
| Termin 3 (Speichermedien) | 16 | 0 | 16 |
|
||||
| Termin 4 (Distribution/APIs) | 25 | 0 | 25 |
|
||||
| **Total** | **65** | **24** | **41** |
|
||||
|
||||
**Note:** grayscale-gradient.png is marked ⚠️ NEEDS REGENERATION due to visibility issues at edges.
|
||||
|
||||
## Generation Tips
|
||||
|
||||
1. **Diagrams**: Use "clean infographic style", "technical illustration", "minimal diagram" in prompts
|
||||
2. **Photos**: Use "product photography", "professional shot", "realistic" for hardware images
|
||||
3. **Concepts**: Use "visualization", "abstract representation" for abstract ideas
|
||||
4. **Logos**: Consider downloading official logos instead of generating (better accuracy)
|
||||
5. **Consistency**: Add "educational style", "professional presentation" to maintain visual coherence
|
||||
@@ -1,48 +1,92 @@
|
||||
# Makefile for Marp Slides Project
|
||||
|
||||
.PHONY: help build dev watch pdf html clean install deploy
|
||||
.PHONY: help build dev watch pdf html clean install deploy assemble
|
||||
|
||||
# Slide components
|
||||
SLIDES_DIR = slides
|
||||
BUILD_DIR = build
|
||||
HEADER = $(SLIDES_DIR)/_frontmatter.md
|
||||
INTRO = $(SLIDES_DIR)/_intro.md
|
||||
OUTRO = $(SLIDES_DIR)/_outro.md
|
||||
|
||||
# Termin files (date-topic naming convention)
|
||||
TERMIN_1 = 2025-12-19-termin-1-grundlagen-text-audio
|
||||
TERMIN_2 = 2026-01-09-termin-2-bild-audio-video
|
||||
TERMIN_3 = 2026-01-23-termin-3-speichermedien-schnittstellen
|
||||
TERMIN_4 = 2026-01-30-termin-4-distribution-apis-zukunft
|
||||
TERMIN_5 = 2026-xx-xx-termin-5-vertiefung-offene-fragen
|
||||
TERMINS = $(TERMIN_1) $(TERMIN_2) $(TERMIN_3) $(TERMIN_4) $(TERMIN_5)
|
||||
|
||||
# Default target
|
||||
help:
|
||||
@echo "Available commands:"
|
||||
@echo " make build - Build slides from Markdown"
|
||||
@echo " make dev - Start development server with live reload"
|
||||
@echo " make watch - Watch for changes and rebuild automatically"
|
||||
@echo " make pdf - Export slides to PDF format"
|
||||
@echo " make html - Export slides to HTML format"
|
||||
@echo " make clean - Remove generated files"
|
||||
@echo " make install - Install dependencies"
|
||||
@echo " make deploy - Deploy slides to server"
|
||||
@echo ""
|
||||
@echo " Development:"
|
||||
@echo " make dev - Start dev server (browse all files at localhost:1312)"
|
||||
@echo ""
|
||||
@echo " Build:"
|
||||
@echo " make build - Build all slides (HTML + PDF)"
|
||||
@echo " make pdf - Export all slides to PDF"
|
||||
@echo " make html - Export all slides to HTML"
|
||||
@echo ""
|
||||
@echo " Other:"
|
||||
@echo " make assemble - Assemble all termin files in build/"
|
||||
@echo " make clean - Remove generated files"
|
||||
@echo " make install - Install dependencies"
|
||||
@echo " make deploy - Deploy slides to server"
|
||||
|
||||
# Build slides
|
||||
build:
|
||||
@echo "Building slides..."
|
||||
npm run build
|
||||
# Ensure build directory exists
|
||||
$(BUILD_DIR)/.exists:
|
||||
@mkdir -p $(BUILD_DIR)
|
||||
@touch $@
|
||||
|
||||
# Start development server
|
||||
# Assemble all termin files
|
||||
assemble: $(BUILD_DIR)/.exists
|
||||
@echo "Assembling slides..."
|
||||
@for f in $(TERMINS); do \
|
||||
echo " $$f.md"; \
|
||||
cat $(HEADER) $(INTRO) $(SLIDES_DIR)/$$f.md $(OUTRO) > $(BUILD_DIR)/$$f.md; \
|
||||
done
|
||||
@echo " all.md"
|
||||
@cat $(HEADER) $(INTRO) $(foreach t,$(TERMINS),$(SLIDES_DIR)/$(t).md) $(OUTRO) > $(BUILD_DIR)/all.md
|
||||
@cp -r $(SLIDES_DIR)/assets $(BUILD_DIR)/ 2>/dev/null || true
|
||||
|
||||
# Development server - serves slides/ directly with HMR
|
||||
dev:
|
||||
@echo "Starting development server..."
|
||||
npm run dev
|
||||
@echo "Starting dev server with HMR..."
|
||||
@echo "Open: http://localhost:1312"
|
||||
PORT=1312 npx @marp-team/marp-cli --server $(SLIDES_DIR)/
|
||||
|
||||
# Watch for changes
|
||||
watch:
|
||||
@echo "Watching for changes..."
|
||||
npm run watch
|
||||
watch: assemble
|
||||
npx @marp-team/marp-cli --watch $(BUILD_DIR)/all.md
|
||||
|
||||
# Export to PDF
|
||||
pdf:
|
||||
# Build all slides (HTML + PDF)
|
||||
build: assemble
|
||||
@echo "Building all slides..."
|
||||
@for f in $(TERMINS); do \
|
||||
echo "Building $$f..."; \
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/$$f.md -o $(BUILD_DIR)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/$$f.md --pdf --allow-local-files -o $(BUILD_DIR)/$$f.pdf; \
|
||||
done
|
||||
@echo "Building all.md..."
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/all.md -o $(BUILD_DIR)/all.html
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/all.md --pdf --allow-local-files -o $(BUILD_DIR)/all.pdf
|
||||
|
||||
# Export to PDF (all slides combined)
|
||||
pdf: assemble
|
||||
@echo "Exporting to PDF..."
|
||||
npm run export:pdf -- --allow-local-files
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/all.md --pdf --allow-local-files -o $(BUILD_DIR)/all.pdf
|
||||
|
||||
# Export to HTML
|
||||
html:
|
||||
# Export to HTML (all slides combined)
|
||||
html: assemble
|
||||
@echo "Exporting to HTML..."
|
||||
npm run export:html
|
||||
npx @marp-team/marp-cli $(BUILD_DIR)/all.md -o $(BUILD_DIR)/all.html
|
||||
|
||||
# Clean generated files
|
||||
clean:
|
||||
@echo "Cleaning generated files..."
|
||||
rm -rf dist/ build/ *.pdf *.html
|
||||
rm -rf $(BUILD_DIR)/ *.pdf *.html
|
||||
|
||||
# Install dependencies
|
||||
install:
|
||||
@@ -52,5 +96,5 @@ install:
|
||||
# Deploy slides
|
||||
deploy: build
|
||||
@echo "Deploying slides..."
|
||||
scp build/index.html tengo@tuttle.uberspace.de:/home/tengo/html/malta/
|
||||
scp -r build/assets/ tengo@tuttle.uberspace.de:/home/tengo/html/malta/
|
||||
scp $(BUILD_DIR)/all.html tengo@tuttle.uberspace.de:/home/tengo/html/malta/index.html
|
||||
scp -r $(BUILD_DIR)/assets/ tengo@tuttle.uberspace.de:/home/tengo/html/malta/
|
||||
|
||||
@@ -1,6 +1,44 @@
|
||||
# HdM - Dateiformate, Speichermedien und Schnittstellen
|
||||
# 223015b – Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
## Creating Slides
|
||||
**Modul "Technik 1"** · 1. Semester · Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart · Wintersemester 2025/26
|
||||
|
||||
**Repository:** [git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
|
||||
|
||||
---
|
||||
|
||||
## Über dieses Modul
|
||||
|
||||
> *Internettechnologien 1 – "Technische Grundlagen von IT-Projekten"*
|
||||
|
||||
Die Digitalisierung verändert die Prozesse und Tätigkeiten in allen Branchen. Sie hat neue Geschäftsmodelle ermöglicht und auch unseren Alltag stark verändert. Kaum ein Projekt in der Medienwelt kommt ohne digitale Technik aus – als Produkt, Kollaborationsplattform oder Marketing- und Verkaufsplattform.
|
||||
|
||||
**Ziel:** Technische Grundlagen verstehen, um mit Entwicklungsteams, Kunden und Projektpartnern auf Augenhöhe zusammenarbeiten zu können.
|
||||
|
||||
### Termine
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 19.12.2025 | Grundlagen, Text & Audio |
|
||||
| 2 | 09.01.2026 | Bild- & Videoformate |
|
||||
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
|
||||
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
|
||||
| 5 | TBA | Vertiefung & offene Fragen |
|
||||
|
||||
### Kompetenzen
|
||||
|
||||
In dieser Veranstaltung erwerben Sie folgende Kompetenzen:
|
||||
- Technische Konzepte des Internets verstehen (Netzwerke, Protokolle, Client/Server)
|
||||
- Dateiformate analysieren und verstehen
|
||||
- Grundlagen von Kompression (Audio, Bild, Video)
|
||||
- Speichermedien und Schnittstellen kennen
|
||||
- APIs und Distributionswege verstehen
|
||||
|
||||
**Dozent:** Michael Czechowski · michael.czechowski@lehre.dhbw-stuttgart.de
|
||||
|
||||
---
|
||||
|
||||
## Slides erstellen
|
||||
|
||||
### Basic Slide Structure
|
||||
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
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>
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h2 {
|
||||
color: var(--color-dimmed);
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _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://git.librete.ch/hdm/223015b](https://git.librete.ch/hdm/223015b)
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Internettechnologien 1
|
||||
## "Technische Grundlagen von IT-Projekten"
|
||||
|
||||
---
|
||||
|
||||
# Über mich
|
||||
|
||||
**Michael Czechowski**
|
||||
|
||||
- Softwareentwickler & IT-Berater
|
||||
- Schwerpunkte: Cloud, AI, Web-Technologien, Systemarchitektur, Open Source
|
||||
- Hintergrund: Philosophie & Informatik
|
||||
- Kontakt: mail@librete.ch
|
||||
|
||||
<!--
|
||||
Kurze Vorstellung
|
||||
Praxisbezug betonen
|
||||
Fragen jederzeit willkommen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Kurze Umfrage
|
||||
|
||||
**Bitte Hand heben:**
|
||||
|
||||
1. Wer hat schon mal ein Video komprimiert/konvertiert?
|
||||
2. Wer hat schon mal eine Datei mit einem Hex-Editor geöffnet?
|
||||
3. Wer weiß, was der Unterschied zwischen JPEG und PNG ist?
|
||||
4. Wer hat schon mal mit APIs gearbeitet?
|
||||
5. Wer weiß, was UTF-8 bedeutet?
|
||||
6. **Wer hat schon mal HTML oder CSS gemacht?** (Hex-Farben wie `#FF0000`?)
|
||||
|
||||
<!--
|
||||
Niveau der Gruppe einschätzen
|
||||
Keine falschen Antworten
|
||||
Zeigt, wo wir starten
|
||||
HTML/CSS-Frage: Viele kennen Hex-Codes aus Webdesign
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Warum dieses Modul?
|
||||
|
||||
Die Digitalisierung verändert die Prozesse und Tätigkeiten in allen Branchen. Sie hat neue Geschäftsmodelle ermöglicht und auch unseren Alltag stark verändert.
|
||||
|
||||
Kaum ein Projekt in der Medienwelt kommt ohne digitale Technik aus:
|
||||
- Als **Produkt** (z.B. Verkauf einer Webseite)
|
||||
- Als **Kollaborationsplattform**
|
||||
- Als **Marketing- und Verkaufsplattform**
|
||||
|
||||
<!--
|
||||
Aus dem Modulhandbuch "Internettechnologien 1"
|
||||
Digitalisierung betrifft alle Branchen
|
||||
Technik ist nicht optional, sondern zentral
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Ziel
|
||||
|
||||
**Technische Grundlagen verstehen**, um mit Entwicklungsteams, Kunden und Projektpartnern **auf Augenhöhe** zusammenarbeiten zu können.
|
||||
|
||||
Grundkenntnisse der Internettechnologien und der Prozesse der Software-Entwicklung sind **unabdingbar**, um ein gemeinsames Verständnis von Projektanforderungen und dem Projektvorgehen zu erreichen.
|
||||
|
||||
<!--
|
||||
Nicht: Ihr sollt Programmierer werden
|
||||
Sondern: Ihr sollt mitreden können
|
||||
"Auf Augenhöhe" = verstehen, was Entwickler:innen meinen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Was ihr lernt
|
||||
|
||||
**In dieser Veranstaltung erwerbt ihr folgende Kompetenzen:**
|
||||
|
||||
- Technische Konzepte des Internets verstehen (Netzwerke, Protokolle, Client/Server)
|
||||
- Dateiformate analysieren und verstehen
|
||||
- Grundlagen von Kompression (Audio, Bild, Video)
|
||||
- Speichermedien und Schnittstellen kennen
|
||||
- APIs und Distributionswege verstehen
|
||||
|
||||
<!--
|
||||
Fokus auf Verständnis, nicht auf Programmierung
|
||||
Hands-On jede Woche: Selbst ausprobieren
|
||||
Ziel: Einblick in die Denkweise von Software-Entwicklern
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Kursübersicht
|
||||
|
||||
**5 Termine:**
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 19.12.2025 | Bits, Bytes, Zeichenkodierung & Audio |
|
||||
| 2 | 09.01.2026 | Bild- & Video-Kompression |
|
||||
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
|
||||
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
|
||||
| 5 | TBA | Vertiefung & offene Fragen |
|
||||
|
||||
**Format:** Theorie + Hands-On (30-40 Min pro Termin)
|
||||
|
||||
<!--
|
||||
Nicht nur theoretische Inhalte
|
||||
Praktische Übungen jede Woche
|
||||
Medienwissenschaftler:innen, nicht Informatiker:innen
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,844 @@
|
||||
---
|
||||
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>
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h2 {
|
||||
color: var(--color-dimmed);
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015c** · 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 1 – 19.12.2025
|
||||
## Grundlagen, Text & Audio
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# WTF!?
|
||||
|
||||
```
|
||||
89 50 4E 47 0D 0A 1A 0A
|
||||
00 00 00 0D 49 48 44 52
|
||||
00 00 01 90 00 00 01 2C
|
||||
```
|
||||
|
||||
**Was ist das?**
|
||||
|
||||
<!--
|
||||
Hex-Dump ohne Erklärung auf Bildschirm werfen
|
||||
Fragen in den Raum: "Was seht ihr?"
|
||||
"Ist das Text? Ein Bild? Code?"
|
||||
Überleitung: "Alles digital ist nur Zahlen. Heute lernen wir, sie zu lesen."
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Bit = Binary Digit
|
||||
Demonstration: Glühbirne AN/AUS = 1 Bit
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Bit
|
||||
|
||||
**Kleinste Informationseinheit**
|
||||
|
||||
- **0 oder 1**
|
||||
- AN oder AUS
|
||||
- Strom fließt oder nicht
|
||||
|
||||
<!--
|
||||
BIT = Binary Digit (Binärziffer) – 1948 von Claude Shannon geprägt
|
||||
Shannon war Mathematiker bei Bell Labs – begründete die Informationstheorie
|
||||
Warum binär? Elektronische Schaltungen haben nur 2 Zustände: Strom/kein Strom
|
||||
Das ist physikalisch am stabilsten (weniger Fehler als 3 oder 10 Zustände)
|
||||
Alles Digitale basiert auf dieser simplen Idee: AN oder AUS
|
||||
Transistoren in modernen CPUs: Milliarden davon, schalten Milliarden Mal pro Sekunde
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Byte
|
||||
|
||||
**8 Bits = 1 Byte**
|
||||
|
||||
```
|
||||
0 1 0 0 1 1 0 1
|
||||
```
|
||||
|
||||
**Wie viele Kombinationen?**
|
||||
2⁸ = **256 Möglichkeiten** (0-255)
|
||||
|
||||
<!--
|
||||
BYTE = Wortspiel aus "Bit" + "Bite" (Bissen) – ein "Bissen" Information
|
||||
Warum genau 8 Bits?
|
||||
- 1964: IBM System/360 setzte diesen Standard (vorher: 6-Bit, 7-Bit Systeme)
|
||||
- ASCII (1963) brauchte 7 Bit für 128 Zeichen
|
||||
- 8 Bit = praktisch für Hardware (Zweierpotenz: 2³ = 8)
|
||||
- 8 Bit = 2 Hexadezimalziffern (elegante Darstellung)
|
||||
Eselsbrücke: 1 Byte = 1 Buchstabe (in ASCII/UTF-8 für einfache Zeichen)
|
||||
Rechnung: 2×2×2×2×2×2×2×2 = 256 mögliche Kombinationen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
256 Graustufen: 0 = Schwarz, 255 = Weiß
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Was kann man mit 256 Zuständen machen?
|
||||
|
||||
- **256 Zeichen** (Buchstaben, Zahlen, Symbole)
|
||||
- **256 Graustufen** (0 = Schwarz, 255 = Weiß)
|
||||
- **256 Lautstärkestufen**
|
||||
- **Zahlen 0-255** (oder -128 bis +127)
|
||||
|
||||
<!--
|
||||
256 = die "magische Zahl" bei 8 Bit
|
||||
Alltagsbeispiele:
|
||||
- Lautstärkeregler (0 = stumm, 255 = max)
|
||||
- Helligkeitswerte in Bildern (0 = schwarz, 255 = weiß)
|
||||
- Alter in Jahren (0-255 reicht für Menschen locker)
|
||||
- Zeichen (ASCII erweitert: 256 Buchstaben/Symbole)
|
||||
Für Farbbilder: 3 Bytes pro Pixel (R, G, B)
|
||||
Jeder Kanal 0-255 → 256³ = 16.777.216 Farben ("True Color")
|
||||
Das menschliche Auge kann etwa 10 Millionen Farben unterscheiden
|
||||
→ 24 Bit reicht für fotorealistische Bilder
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
RGB = Additive Farbmischung (Bildschirme)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Farben: RGB-Modell
|
||||
|
||||
**1 Pixel = 3 Bytes**
|
||||
|
||||
- **Rot:** 0-255
|
||||
- **Grün:** 0-255
|
||||
- **Blau:** 0-255
|
||||
|
||||
**Beispiele:**
|
||||
`FF 00 00` = Rot | `00 FF 00` = Grün
|
||||
`00 00 00` = Schwarz | `FF FF FF` = Weiß
|
||||
|
||||
<!--
|
||||
CMYK = Subtraktive Farbmischung (Druck)
|
||||
Hex-Notation: FF = 255 in Dezimal
|
||||
CSS-Farben nutzen Hex: #FF0000 = Rot
|
||||
Wer HTML/CSS gemacht hat, kennt das schon!
|
||||
background-color: #FF0000; = Rot
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Problem: Sprachen
|
||||
|
||||
**Die Welt hat mehr als 256 Zeichen!**
|
||||
|
||||
- Englisches Alphabet: 52 (A-Z, a-z)
|
||||
- + Ziffern: 10 (0-9)
|
||||
- + Sonderzeichen: ~30
|
||||
|
||||
**≈ 90 Zeichen → passt in 1 Byte**
|
||||
|
||||
**Aber:** ä, ö, ü, ß, é, à, ç, α, β, 中, 日, 😀
|
||||
|
||||
→ **1 Byte reicht nicht!**
|
||||
|
||||
<!--
|
||||
Problem der Zeichenkodierung
|
||||
ASCII (1963): 7 Bit = 128 Zeichen (nur Englisch)
|
||||
ISO-8859-1 (Latin-1): 8 Bit = 256 Zeichen (Westeuropa)
|
||||
Chaos: Verschiedene Standards für verschiedene Sprachen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
ASCII-Tabelle (1963)
|
||||
7 Bit = 128 Zeichen
|
||||
Erste 32: Steuerzeichen (nicht druckbar)
|
||||
Zeichen 32-126: Druckbar (Buchstaben, Ziffern, Satzzeichen)
|
||||
Keine Umlaute, kein ñ, kein é
|
||||
"American Standard" → Rest der Welt ausgeschlossen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Unicode: Ein Standard für alle
|
||||
|
||||
**Unicode (1991):**
|
||||
Jedes Schriftsystem der Welt
|
||||
|
||||
**>150.000 Zeichen:**
|
||||
- Latein, Kyrillisch, Arabisch, Chinesisch, Japanisch...
|
||||
- Mathematische Symbole, Emoji, historische Schriften
|
||||
|
||||
**UTF-8:** Variable Länge (1-4 Bytes pro Zeichen)
|
||||
|
||||
<!--
|
||||
Unicode Consortium: Non-Profit seit 1991
|
||||
Aktuell: Unicode 16.0 (2024)
|
||||
UTF-8 = Unicode Transformation Format, 8-bit
|
||||
ASCII-kompatibel: "A" = 1 Byte (rückwärtskompatibel)
|
||||
Umlaute: "ä" = 2 Bytes, Chinesisch: 3 Bytes, Emoji: 4 Bytes
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Beispiel: Bytes zählen
|
||||
|
||||
**Text:** `"Why the heck braucht 💩 4 Bytes?!"`
|
||||
|
||||
```
|
||||
W h y → je 1 Byte (4 Bytes)
|
||||
t h e → je 1 Byte (4 Bytes)
|
||||
h e c k → je 1 Byte (4 Bytes)
|
||||
→ 1 Byte (Leerzeichen)
|
||||
b r a u c h t → je 1 Byte (7 Bytes)
|
||||
→ 1 Byte
|
||||
💩 → 4 Bytes! (0xF0 9F 92 A9)
|
||||
→ 1 Byte
|
||||
4 B y t e s ? ! → je 1 Byte (9 Bytes)
|
||||
```
|
||||
|
||||
**Gesamt: 37 Bytes**
|
||||
|
||||
<!--
|
||||
Buchstaben = 1 Byte (ASCII/UTF-8-kompatibel)
|
||||
Emoji = 4 Bytes (Unicode-Bereich U+1F4A9)
|
||||
Haufen-Emoji: "Pile of Poo" (offizieller Name!)
|
||||
UTF-8-Kodierung: Variable Länge spart Speicher bei ASCII
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Hex-Binär-Umrechnungstabelle
|
||||
Jede Hex-Ziffer = 4 Bits
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hexadezimal: Lesbarkeit
|
||||
|
||||
**Binär ist unleserlich:**
|
||||
`01001101 01010000 00110011`
|
||||
|
||||
**Hexadezimal (Base 16):**
|
||||
`4D 50 33` (= "MP3" in ASCII)
|
||||
|
||||
**Jede Hex-Ziffer = 4 Bits (ein "Nibble")**
|
||||
0-9, A-F (10=A, 11=B, ..., 15=F)
|
||||
|
||||
<!--
|
||||
Warum Hexadezimal statt Dezimal?
|
||||
- Binär ist zu lang: 01001101 (8 Zeichen für 1 Byte)
|
||||
- Dezimal passt nicht: 77 (unregelmäßig, manchmal 2, manchmal 3 Ziffern)
|
||||
- Hex ist perfekt: 4D (immer 2 Ziffern pro Byte)
|
||||
|
||||
Trick: 4 Bits = 1 Hex-Ziffer (weil 2⁴ = 16)
|
||||
0000 = 0, 0001 = 1, ..., 1001 = 9, 1010 = A, 1011 = B, ..., 1111 = F
|
||||
|
||||
"Nibble" = 4 Bits = halbes Byte (Wortspiel: nibble = knabbern, byte = beißen)
|
||||
|
||||
Umrechnung üben:
|
||||
- 0x4D = 4×16 + 13 = 64 + 13 = 77 (Dezimal) = Buchstabe "M" in ASCII
|
||||
- 0xFF = 15×16 + 15 = 255 (Maximum für 1 Byte)
|
||||
|
||||
Hex-Editor = Standard-Tool für Dateianalyse und Reverse Engineering
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Magic Numbers
|
||||
|
||||
**Dateityp-Identifikation durch erste Bytes**
|
||||
|
||||
| Format | Magic Number (Hex) | ASCII |
|
||||
|--------|-------------------|-------|
|
||||
| PNG | `89 50 4E 47 0D 0A 1A 0A` | `.PNG` |
|
||||
| JPEG | `FF D8 FF` | `ÿØÿ` |
|
||||
| PDF | `25 50 44 46` | `%PDF` |
|
||||
| ZIP/DOCX/ODT | `50 4B 03 04` | `PK` |
|
||||
|
||||
**Achtung:** TXT, HTML, CSS haben **keine** Magic Number!
|
||||
|
||||
<!--
|
||||
Magic Number = Signatur/Fingerabdruck am Dateianfang
|
||||
Wozu? Betriebssystem erkennt Dateityp unabhängig von Dateiendung
|
||||
|
||||
Geschichte: "PK" bei ZIP = Phil Katz (Erfinder von PKZip, 1989)
|
||||
Fun Fact: DOCX, XLSX, PPTX, ODT = alles ZIP-Archive mit XML-Inhalt!
|
||||
→ Einfach .zip anhängen und entpacken!
|
||||
|
||||
Dateien OHNE Magic Number: TXT, HTML, CSS, JSON, XML
|
||||
→ Diese sind reiner Text, kein binäres Format
|
||||
→ Werden anhand Inhalt/Endung erkannt
|
||||
|
||||
Sicherheits-Aspekt:
|
||||
virus.exe → bild.jpg umbenennen täuscht nur Menschen
|
||||
Windows vertraut der Endung, aber Tools wie "file" (Linux) lesen Magic Number
|
||||
→ Nie Dateien von Fremden öffnen, nur weil sie harmlos aussehen!
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Hex-Editor-Screenshot mit PNG-Datei
|
||||
Erste Bytes: 89 50 4E 47 = PNG-Signatur
|
||||
IHDR = Image Header (Breite, Höhe, Farbtiefe)
|
||||
Zeigen, wie man Magic Number liest
|
||||
Tool: HxD (Windows), Hex Fiend (Mac), xxd (Linux)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hands-On: WTF Files
|
||||
|
||||
**Aufgabe (30 Min):**
|
||||
|
||||
1. Drei Dateien ohne Extension: `wtf1`, `wtf2`, `wtf3`
|
||||
→ Download: `materials/` Ordner
|
||||
2. Öffne im Hex-Editor
|
||||
3. Lies erste 16 Bytes
|
||||
4. Identifiziere Format (Magic Number)
|
||||
5. Benenne um und öffne
|
||||
|
||||
**Tools:** hexed.it (online), HxD, Hex Fiend, Bless
|
||||
|
||||
<!--
|
||||
Praktische Phase: Studierende arbeiten selbst
|
||||
Dateien im materials/ Ordner:
|
||||
- wtf1: Plaintext (keine Magic Number)
|
||||
- wtf2: PNG (89 50 4E 47)
|
||||
- wtf3: JPEG (FF D8 FF)
|
||||
Gruppenarbeit: 3-4 Personen
|
||||
Ziel: Hex-Dump lesen lernen, Dateiformate verstehen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Finde eine Datei auf deinem Computer**
|
||||
|
||||
1. Öffne im Hex-Editor
|
||||
2. Schau dir die ersten 16 Bytes an
|
||||
3. Identifiziere die Magic Number (falls vorhanden)
|
||||
4. Nächste Woche: Kurze Diskussion
|
||||
|
||||
**Bonus:** Finde Datei ohne Magic Number
|
||||
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Nächste Woche kurz besprechen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Die MP3-Revolution
|
||||
## Psychoakustik & Audio-Kompression
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Kassette neben iPod
|
||||
Visueller Kontrast: Analog vs. Digital
|
||||
1980er vs. 2000er
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Das Problem (1990)
|
||||
|
||||
**1 Minute CD-Audio:**
|
||||
|
||||
- Sample Rate: 44.100 Hz
|
||||
- Bit Depth: 16 Bit
|
||||
- Stereo: 2 Kanäle
|
||||
|
||||
**Rechnung:**
|
||||
44.100 × 16 × 2 = 1.411.200 Bits/Sekunde
|
||||
≈ **10,6 MB/Minute**
|
||||
≈ **635 MB für 60-Min-Album**
|
||||
|
||||
**1990:** Festplatten hatten 100-500 MB!
|
||||
|
||||
<!--
|
||||
CD-Qualität = Standard seit 1982
|
||||
Ein Album = ganze Festplatte
|
||||
Download bei 56k-Modem = Tage!
|
||||
Streaming? Unmöglich.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Lossless vs. Lossy Kompression
|
||||
Visualisierung der beiden Philosophien
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Zwei Philosophien
|
||||
|
||||
**Lossless (Verlustfrei):**
|
||||
- Original exakt wiederherstellbar
|
||||
- ZIP, PNG, FLAC
|
||||
- 30-50% Ersparnis
|
||||
|
||||
**Lossy (Verlustbehaftet):**
|
||||
- Daten irreversibel verändert
|
||||
- JPEG, MP3, H.264
|
||||
- 90%+ Ersparnis
|
||||
|
||||
<!--
|
||||
Lossless: Findet Muster, beschreibt effizienter
|
||||
Lossy: Wirft "Unwichtiges" weg (Psychoakustik/Psychovisuell)
|
||||
Trade-off: Größe vs. Qualität
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Lossless: Run-Length Encoding
|
||||
## Lauflängenkodierung
|
||||
|
||||
**Original:**
|
||||
```
|
||||
AAAAABBBCCCCCCCC
|
||||
```
|
||||
|
||||
**Komprimiert:**
|
||||
```
|
||||
5A 3B 8C
|
||||
```
|
||||
|
||||
**Ersparnis:** 16 → 6 Zeichen (62% Reduktion)
|
||||
|
||||
<!--
|
||||
RLE = Run-Length Encoding = Lauflängenkodierung
|
||||
Simplest Compression Algorithm
|
||||
Gut für repetitive Daten (Fax, simple Grafiken)
|
||||
Schlecht für chaotische Daten (Fotos, Audio)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Lossy: Der Trick
|
||||
|
||||
**Kernidee:** Wirf weg, was der Mensch eh nicht wahrnimmt
|
||||
|
||||
**JPEG:** Schwächen des Auges
|
||||
- Helligkeit besser als Farbe wahrgenommen
|
||||
- Große Flächen besser als feine Details
|
||||
|
||||
**MP3:** Schwächen des Ohrs
|
||||
- Mittlere Frequenzen besser als hohe/tiefe
|
||||
- Laute Töne "maskieren" leise Töne
|
||||
|
||||
→ **Psychoakustik / Psychovisuell**
|
||||
|
||||
<!--
|
||||
Auditory Masking: Lauter 1000 Hz-Ton → leise 950 Hz unhörbar
|
||||
Visuelle Masking: Starker Kontrast überstrahlt Details
|
||||
Kompression = Modell der menschlichen Wahrnehmung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Karlheinz Brandenburg
|
||||
|
||||
**"Vater der MP3"**
|
||||
|
||||
- Diplom-Ingenieur, Universität Erlangen-Nürnberg
|
||||
- Fraunhofer IIS (Institut für Integrierte Schaltungen)
|
||||
- Forschung ab 1982, Patent 1988
|
||||
- Hörte "Tom's Diner" über 10.000 Mal
|
||||
|
||||
<!--
|
||||
Fraunhofer IIS Erlangen
|
||||
Forschung dauerte über 10 Jahre
|
||||
Perfektionist: Jeder Hörtest musste bestehen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Die Geburt der MP3
|
||||
|
||||
**1982:** Universität Erlangen-Nürnberg
|
||||
Karlheinz Brandenburg, Diplom-Ingenieur
|
||||
|
||||
**1987:** Fraunhofer IIS entwickelt MPEG-1 Audio Layer III
|
||||
|
||||
**1988:** Patentanmeldung
|
||||
|
||||
**1992:** Erste Software-Implementierung
|
||||
|
||||
**1995:** .mp3 Dateiendung offiziell
|
||||
|
||||
<!--
|
||||
MPEG = Moving Picture Experts Group
|
||||
Layer III = Dritte Verfeinerungsstufe
|
||||
Forschung dauerte 10 Jahre
|
||||
Patent lief 2017 aus
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Suzanne Vega
|
||||
|
||||
**"Tom's Diner" (1987)**
|
||||
|
||||
- A cappella (keine Instrumente)
|
||||
- Klare, hohe Frequenzen
|
||||
- Perfekter Stresstest für Kompression
|
||||
- Der erste Song, der als MP3 kodiert wurde
|
||||
|
||||
<!--
|
||||
Suzanne Vega – "Tom's Diner" (1987)
|
||||
A cappella = einfacher zu analysieren (nur Stimme)
|
||||
Hohe Frequenzen = Herausforderung für Kompression
|
||||
Brandenburg hörte den Song über 10.000 Mal
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# "Tom's Diner"
|
||||
|
||||
**Warum dieser Song?**
|
||||
|
||||
- A cappella (keine Instrumente)
|
||||
- Suzanne Vegas Stimme ist "schwierig"
|
||||
- Klare, hohe Frequenzen → Stresstest
|
||||
|
||||
*"If I could code Suzanne Vega's voice well, I could code anything."*
|
||||
— Karlheinz Brandenburg
|
||||
|
||||
<!--
|
||||
Brandenburg hörte Song 10.000+ Mal
|
||||
A cappella = einfacher zu analysieren (nur Stimme)
|
||||
Hohe Frequenzen = Herausforderung für Kompression
|
||||
Perfektionismus: Jeder Hörtest musste bestehen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Wie funktioniert MP3?
|
||||
|
||||
**1. Frequenz-Analyse (FFT)**
|
||||
Audio → Frequenzspektrum
|
||||
|
||||
**2. Psychoakustisches Modell**
|
||||
Welche Töne hört Mensch nicht?
|
||||
|
||||
**3. Quantisierung**
|
||||
Unwichtige Frequenzen reduzieren
|
||||
|
||||
**4. Huffman-Coding**
|
||||
Lossless-Kompression der Restdaten
|
||||
|
||||
<!--
|
||||
MP3-Kompression in 4 Schritten (vereinfacht):
|
||||
|
||||
1. FFT (Fast Fourier Transform)
|
||||
- Wandelt Schallwellen in Frequenzen um
|
||||
- Wie ein Prisma Licht in Farben zerlegt
|
||||
|
||||
2. Psychoakustisches Modell
|
||||
- Fragt: "Was kann ein Mensch NICHT hören?"
|
||||
- Maskierungseffekte: Lauter Ton verdeckt leisen daneben
|
||||
- Hohe/tiefe Frequenzen werden schlechter wahrgenommen
|
||||
|
||||
3. Quantisierung (hier passiert der Datenverlust!)
|
||||
- Unwichtige Frequenzen werden "grob" gespeichert
|
||||
- Wichtige Frequenzen bleiben genau
|
||||
- Wie JPEG: Details entfernen, wo es nicht auffällt
|
||||
|
||||
4. Huffman-Coding (verlustfrei)
|
||||
- Häufige Muster = kurze Codes
|
||||
- Seltene Muster = lange Codes
|
||||
- Finaler Effizienz-Boost
|
||||
|
||||
MP3 ist KEIN einfaches "Kleiner machen"
|
||||
→ Es simuliert, wie dein Gehirn Musik verarbeitet!
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Bitrate: Der Qualitäts-Knopf
|
||||
|
||||
| Bitrate | Qualität | Kompression |
|
||||
|---------|----------|-------------|
|
||||
| **128 kbps** | Hörbar schlechter | ~11x |
|
||||
| **192 kbps** | Akzeptabel | ~7x |
|
||||
| **256 kbps** | Gut | ~5,5x |
|
||||
| **320 kbps** | "CD-Qualität" | ~4,4x |
|
||||
|
||||
**Original CD:** 1.411 kbps (unkomprimiert)
|
||||
|
||||
<!--
|
||||
kbps = Kilobit pro Sekunde
|
||||
128 kbps = Standard in 2000ern (Napster-Ära)
|
||||
320 kbps = Maximum für MP3
|
||||
Höhere Bitrate = mehr Daten = bessere Qualität
|
||||
Aber: Diminishing Returns ab 256 kbps
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
Spektrogramm-Vergleich
|
||||
Original vs. 320 kbps vs. 128 kbps
|
||||
Hohe Frequenzen verschwinden bei niedriger Bitrate
|
||||
Visuell: Dunkle Bereiche = fehlende Frequenzen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Der Patentkrieg
|
||||
|
||||
**1990er:** Fraunhofer + Thomson halten MP3-Patente
|
||||
|
||||
**Lizenzgebühren:**
|
||||
- $0,75 pro Decoder
|
||||
- $2,50 pro Encoder
|
||||
|
||||
**Problem:** Napster (1999) → unkontrollierte Verbreitung
|
||||
|
||||
**2017:** Patente laufen aus → MP3 ist frei
|
||||
|
||||
<!--
|
||||
Fraunhofer verklagte Winamp, andere Tools
|
||||
Millionen nutzten unlizenzierte Software
|
||||
Das Pferd war aus dem Stall
|
||||
2017: Fraunhofer selbst erklärte MP3 für "veraltet" (AAC besser)
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Napster (1999)
|
||||
|
||||
**P2P-Filesharing für MP3s**
|
||||
|
||||
- Shawn Fanning, 19 Jahre alt
|
||||
- 80 Millionen User in 2 Jahren
|
||||
- Musikindustrie verklagt (2001)
|
||||
- Pandora's Box: Nicht mehr aufzuhalten
|
||||
|
||||
<!--
|
||||
P2P = Peer-to-Peer
|
||||
Shawn Fanning gründete Napster als Student
|
||||
RIAA verklagte Napster, Schließung 2001
|
||||
Aber: LimeWire, Kazaa, BitTorrent folgten
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Napster & Musikindustrie
|
||||
|
||||
**1999:** Napster startet
|
||||
**2001:** 80 Millionen User
|
||||
|
||||
**Musikindustrie:**
|
||||
- CDs kosten $15-20
|
||||
- MP3s gratis (illegal, aber egal)
|
||||
- Einzelne Songs statt Alben
|
||||
|
||||
**2001:** Napster verklagt, geschlossen
|
||||
|
||||
**Aber:** Pandora's Box offen
|
||||
→ LimeWire, Kazaa, BitTorrent, später Spotify
|
||||
|
||||
<!--
|
||||
RIAA (Recording Industry Association of America) verklagte Napster
|
||||
Urteil: Napster muss schließen (2001)
|
||||
Aber: Technologie nicht mehr aufzuhalten
|
||||
iPod (2001): "1.000 songs in your pocket"
|
||||
iTunes Store (2003): Legale Alternative
|
||||
Spotify (2008): Streaming-Ära beginnt
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Kulturelle Revolution
|
||||
|
||||
**MP3 veränderte:**
|
||||
|
||||
✓ Musik wurde portabel (Walkman → iPod)
|
||||
✓ Alben wurden irrelevant (Playlists)
|
||||
✓ Musikkonsum explodierte (kostenlos/billig)
|
||||
✓ Künstler verloren Kontrolle
|
||||
|
||||
**Aber auch:**
|
||||
❌ Künstler verdienen weniger pro Stream
|
||||
❌ Audio-Qualität sank (Loudness War)
|
||||
❌ Physische Medien starben
|
||||
|
||||
<!--
|
||||
Walkman (1979): Kassetten
|
||||
Discman (1984): CDs
|
||||
iPod (2001): MP3s
|
||||
Spotify (2008): Streaming
|
||||
Künstler-Einkommen: Album-Verkauf → Streaming-Pennies
|
||||
Loudness War: Alles wird lauter gemastert (Dynamik verloren)
|
||||
Vinyl-Revival: 2020er Gegenbewegung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Hands-On: MP3 sezieren
|
||||
|
||||
**Aufgabe (30 Min):**
|
||||
|
||||
1. Lade Lied runter (eigenes oder CC)
|
||||
2. Konvertiere in verschiedene Bitraten:
|
||||
- 320 kbps, 128 kbps, 64 kbps
|
||||
3. Tool: **Audacity** (kostenlos)
|
||||
4. Höre Unterschiede (Kopfhörer!)
|
||||
5. Vergleiche Dateigrößen
|
||||
|
||||
**Spektrogramm:** Track-Menü → Spektrogramm
|
||||
|
||||
<!--
|
||||
Audacity: FOSS Audio-Editor (audacityteam.org)
|
||||
Export: Datei → Exportieren → MP3 → Bitrate wählen
|
||||
Spektrogramm-Ansicht: Track-Name klicken → "Spektrogramm"
|
||||
Hohe Frequenzen (oben im Bild) verschwinden bei niedriger Bitrate
|
||||
Alternative: Spek (spek.cc) – reiner Spektrogramm-Viewer
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Fleißaufgabe bis nächste Woche
|
||||
|
||||
**Nimm ein Lied (eigenes oder CC)**
|
||||
|
||||
1. Exportiere: WAV, MP3 320 kbps, MP3 128 kbps
|
||||
2. Höre die Unterschiede (Kopfhörer!)
|
||||
3. Vergleiche die Dateigrößen
|
||||
|
||||
**Bonus:** Niedrigste Bitrate finden, bei der du keinen Unterschied hörst
|
||||
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Keine Abgabe, nur zum Ausprobieren
|
||||
Goldenes Ohr: Manche hören Unterschied, manche nicht
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** mail@librete.ch
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
# 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/
|
||||
|
||||
@@ -0,0 +1,771 @@
|
||||
---
|
||||
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>
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h2 {
|
||||
color: var(--color-dimmed);
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||
|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015c** · 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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. Poste im Forum: Screenshot + Reflexion
|
||||
|
||||
**Fragen:**
|
||||
- Welche Quality ist für dich "akzeptabel"?
|
||||
- Wo siehst du zuerst Artefakte?
|
||||
|
||||
**Bonus:** Teste WebP oder AVIF
|
||||
|
||||
<!--
|
||||
Selbstständiges Experimentieren
|
||||
Subjektive Wahrnehmung (jeder anders)
|
||||
Forum: Austausch über Ergebnisse
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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. Poste im Forum:
|
||||
- Dateigrößen
|
||||
- Encoding-Zeiten
|
||||
- Visueller Unterschied?
|
||||
|
||||
**Bonus:** AV1-Encoding (Warnung: SEHR langsam!)
|
||||
|
||||
<!--
|
||||
MediaInfo oder ffprobe für Analyse
|
||||
HandBrake für Konvertierung (einfacher als CLI)
|
||||
Encoding-Zeit: H.265 ~5x langsamer, AV1 ~50x langsamer
|
||||
Qualität: Bei gleicher Bitrate H.265 > H.264
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
# 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/
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,67 @@
|
||||
---
|
||||
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>
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h2 {
|
||||
color: var(--color-dimmed);
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 5 – TBA
|
||||
## Vertiefung & Offene Fragen
|
||||
|
||||
---
|
||||
|
||||
# Ersatztermin
|
||||
|
||||
**Dieser Termin wird noch bekannt gegeben.**
|
||||
|
||||
Mögliche Inhalte:
|
||||
- Vertiefung von Themen nach Wunsch
|
||||
- Praxisübungen & Hands-On
|
||||
- Offene Fragen & Diskussion
|
||||
- Prüfungsvorbereitung
|
||||
|
||||
<!--
|
||||
Flexibler Termin für Nachholbedarf
|
||||
Themen nach Interesse der Studierenden
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Fragen & Diskussion
|
||||
|
||||
**Kontakt:** czechowski@hdm-stuttgart.de
|
||||
**Folien:** Online verfügbar unter https://hdm.librete.ch
|
||||
|
||||
---
|
||||
|
||||
# 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/
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.6 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.7 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.7 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 197 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.0 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 308 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.5 MiB |
@@ -0,0 +1 @@
|
||||
Dies ist eine einfache Textdatei. Keine Magic Number hier! Plaintext hat keinen Standard-Header.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 197 KiB |
Reference in New Issue
Block a user