### Teilaufgabe 1: Recherchiere gruendlich, welche ANWENDUNGEN und BENUTZER-WERKZEUGE ein Desktop-Betriebssystem mindestens braucht, damit ein normaler Mensch es taeglich benutzen kann, ohne auf Windows zurueckzuwechseln. Orientiere dich an Windows 11 und an typischen Linux-Desktops (GNOME/KDE): Was ist standardmaessig dabei? Erstelle eine PRIORISIERTE Liste in drei Stufen: (1) unverzichtbar, ohne das ist das System unbenutzbar, (2) wichtig, fehlt schnell auf, (3) Kuer. Nenne zu jedem Punkt kurz, WOZU man es braucht und WIE AUFWENDIG die Umsetzung ungefaehr ist (klein/mittel/gross). Beruecksichtige ausdruecklich: Bildschirmausschnitt aufnehmen (Snipping Tool), Bildbetrachter, Medienwiedergabe (Video und Audio), Dateimanager, Texteditor, Terminal, Taschenrechner, Archiv-Werkzeug (zip), Drucken, PDF-Anzeige, Zwischenablage mit Verlauf, Bildschirmtastatur, Barrierefreiheit. Antworte auf Deutsch, kompakt, ohne Werbefloskeln.
# Minimaler Anwendungs-Satz für einen alltagstauglichen Desktop

Referenz: Windows 11 („Inbox Apps", 24H2 liefert ~36 vorinstallierte Apps), GNOME Core Apps und KDE Gear. Aufwandsschätzung bezieht sich auf **Eigenentwicklung** eines brauchbaren (nicht perfekten) Werkzeugs; „klein" ≈ Tage, „mittel" ≈ Wochen, „groß" ≈ Monate.

---

## Vorbemerkung: Plattform-Dienste, ohne die keine App funktioniert

Diese sind keine „Anwendungen", aber jede Liste unten hängt daran. Wer sie überspringt, baut Insellösungen:

| Dienst | Wozu | Aufwand |
|---|---|---|
| MIME-/Standard-App-Registry | „Öffnen mit", Doppelklick öffnet das Richtige | mittel |
| Datei-Dialoge (Öffnen/Speichern) systemweit einheitlich | jede App braucht sie | mittel |
| Zwischenablage-Server (Text, Bild, Dateien) | App-übergreifendes Copy/Paste | mittel |
| Drag & Drop zwischen Apps | Dateien in Mail/Editor ziehen | mittel |
| Benachrichtigungen | Downloads, Fehler, Termine | klein |
| Audio-Routing (PipeWire-Äquivalent) + Lautstärke-/Geräte-Umschaltung | Mehrere Apps gleichzeitig, Kopfhörer einstecken | groß |
| Portals/Sandbox-Zugriff (Screenshot, Datei, Kamera) | Sicherheitsmodell moderner Desktops | mittel |

---

## Stufe 1 — Unverzichtbar (ohne das ist das System unbenutzbar)

| # | Werkzeug | Wozu | Aufwand |
|---|---|---|---|
| 1 | **Dateimanager** (Explorer / Nautilus / Dolphin) | Navigieren, Kopieren, Umbenennen, Löschen, Papierkorb, USB-Sticks einbinden, Suche. Das zentrale Werkzeug. Muss: Zwischenablage, Drag&Drop, Kontextmenü, Miniaturansichten | **groß** |
| 2 | **Webbrowser** | De facto die wichtigste Anwendung überhaupt: Mail, Banking, Video, Office, Behördenkram. Ohne funktionierenden Browser wechselt der Nutzer sofort zurück. Realistisch nur durch Portierung von Chromium/Firefox lösbar, keine Eigenentwicklung | **groß** (Portierung: mittel–groß) |
| 3 | **Terminal + Shell** | Administration, Fehlersuche, Installation. Für dich als Entwickler auch das Bootstrapping-Werkzeug. Muss: UTF-8, Farben, Scrollback, Copy/Paste, Größenänderung | **mittel** |
| 4 | **Texteditor** (Notepad / gedit / Kate) | Konfigurationsdateien, Notizen, schnelle Bearbeitung. Muss: Öffnen/Speichern, Suchen/Ersetzen, Undo, Zeichenkodierung | **klein–mittel** |
| 5 | **Einstellungen / Systemsteuerung** | WLAN, Anzeige/Auflösung, Ton, Tastaturlayout, Zeitzone, Benutzer, Energie. Ohne WLAN-Dialog ist ein Laptop tot | **groß** |
| 6 | **Anwendungsstarter + Fensterverwaltung + Taskleiste** | App finden, starten, wechseln, minimieren, Alt+Tab, Uhr, Statussymbole (Akku, WLAN, Lautstärke) | **groß** |
| 7 | **Bildbetrachter** | JPG/PNG/WebP/HEIF anzeigen, zoomen, drehen, vor/zurück blättern. Ohne das kann man Fotos nicht ansehen — sofortiger Frustpunkt | **klein** |
| 8 | **Archiv-Werkzeug (ZIP)** | Praktisch jeder Download ist ein ZIP. Muss: entpacken **und** packen, ZIP zwingend, tar.gz/7z stark empfohlen, passwortgeschützte ZIPs | **klein–mittel** |
| 9 | **PDF-Anzeige** | Rechnungen, Verträge, Handbücher, Behördenformulare. Muss: Blättern, Zoom, Textsuche, Drucken, Text kopieren. Bibliothek (PDFium/MuPDF) verwenden, nicht selbst schreiben | **mittel** |
| 10 | **Zwischenablage (Basis)** | Text/Bild/Datei zwischen Apps. Siehe Plattform-Dienste — ohne funktionierendes Strg+C/V ist das System unbenutzbar | **mittel** |
| 11 | **Softwareinstallation / Paketverwaltung mit Oberfläche** | Neue Programme installieren und aktualisieren. Ohne das ist das System eingefroren | **mittel–groß** |
| 12 | **Netzwerk-/WLAN-Verwaltung mit Oberfläche** | Netz auswählen, Passwort eingeben, VPN. Technisch Teil von Einstellungen, aber eigener kritischer Pfad | **mittel** |

---

## Stufe 2 — Wichtig (fehlt innerhalb der ersten Tage schmerzhaft auf)

| # | Werkzeug | Wozu | Aufwand |
|---|---|---|---|
| 13 | **Bildschirmausschnitt aufnehmen** (Snipping Tool / Spectacle / GNOME Screenshot) | Ausschnitt, Fenster, ganzer Bildschirm, Verzögerung; direkt in Zwischenablage **und** als Datei; leichte Markierung (Pfeil, Kasten, Verpixeln). Windows-Nutzer erwarten Win+Shift+S. Sehr hoher gefühlter Wert bei kleinem Aufwand | **klein–mittel** |
| 14 | **Medienwiedergabe Video** (MPV/VLC-Klasse) | MP4/MKV/WebM, H.264/HEVC/AV1, Untertitel, Hardware-Dekodierung. Eigenentwicklung sinnlos — libmpv/ffmpeg einbetten | **mittel** (mit ffmpeg), sonst groß |
| 15 | **Medienwiedergabe Audio** | MP3/FLAC/AAC/Opus, Wiedergabeliste, Lautstärke, Mediensteuerungstasten. Kann derselbe Player sein | **klein–mittel** |
| 16 | **Drucken** (Drucksystem + Dialog) | Druckerkennung (IPP Everywhere/AirPrint macht das heute treiberlos), Druckdialog mit Seitenauswahl/Kopien/Duplex, Warteschlange, **PDF-Export als virtueller Drucker**. Realistisch: CUPS übernehmen statt neu bauen | **groß** (mit CUPS: mittel) |
| 17 | **Taschenrechner** | Grundrechnen, Prozent, Wissenschaftsmodus, Einheiten-/Währungsumrechnung. Klassisches „ist doch selbstverständlich" | **klein** |
| 18 | **Zwischenablage-Verlauf** | Mehrere Kopien behalten, Verlauf per Tastenkürzel (Win+V), Anheften, Bilder, Verlauf löschen. Hoher Alltagsnutzen | **klein–mittel** |
| 19 | **Systemmonitor / Task-Manager** | Hängende App abschießen, CPU/RAM/Datenträger sehen. Erste Anlaufstelle bei Problemen | **klein–mittel** |
| 20 | **Barrierefreiheit — Basis** | Systemweite Schriftvergrößerung/Skalierung, Bildschirmlupe, hoher Kontrast, Mausklick-Verzögerung/Einrastfunktion, Tastaturnavigation überall. Nicht nachrüstbar — muss im Toolkit von Anfang an drin sein | **mittel** (früh) / **groß** (nachträglich) |
| 21 | **Bildschirmtastatur** | Touchscreen/2-in-1-Geräte, Notfall bei defekter Tastatur, Barrierefreiheit. Muss: Layoutwechsel, Umschalt/Strg, automatisches Einblenden bei Texteingabe auf Touch | **mittel** |
| 22 | **Datenträger-/Laufwerksverwaltung + automatisches Einbinden** | USB-Stick, SD-Karte, externe Platte; Formatieren, sicheres Auswerfen | **mittel** |
| 23 | **Suche über Dateien und Apps** | „Wo ist das Dokument von letzter Woche?" — Indexer + Suchfeld im Starter | **mittel–groß** |
| 24 | **Mail-Client** (oder klar gesetzt: Webmail) | Wenn kein Client da ist, muss der Browser es sicher können. Sonst harter Blocker | **groß** (Client) / **klein** (Webmail-Entscheidung) |
| 25 | **Archivierung/Sicherung** | Datensicherung vor dem ersten Datenverlust. Ohne das verliert man Nutzer dauerhaft | **mittel** |
| 26 | **Schriftarten + Emoji + internationale Tastaturlayouts** | Umlaute, €, Sonderzeichen, Emoji. Klingt trivial, ist ein häufiger Abbruchgrund | **klein–mittel** |

---

## Stufe 3 — Kür (macht den Unterschied zwischen „geht" und „gern benutzt")

| # | Werkzeug | Wozu | Aufwand |
|---|---|---|---|
| 27 | **Bildbearbeitung leicht** (Zuschneiden, Drehen, Größe, Helligkeit) | Foto vor dem Versenden anpassen. Oft im Bildbetrachter integriert | klein |
| 28 | **Bildschirmaufnahme (Video) + Webcam-App** | Anleitungen, Videokonferenz-Test | mittel |
| 29 | **Kalender + Kontakte + Aufgaben** | Termine, Erinnerungen; Wert steigt stark mit Synchronisierung (CalDAV) | mittel–groß |
| 30 | **Uhr/Wecker/Timer/Stoppuhr** | Kleinkram mit hoher Nutzungshäufigkeit | klein |
| 31 | **Zeichentool / Notizen mit Stift** | Skizzen, Tablet-Nutzung | mittel |
| 32 | **Office-Paket** (Text, Tabelle, Präsentation) | Eigenentwicklung ausgeschlossen — LibreOffice portieren oder Web-Office setzen | groß (Portierung) |
| 33 | **Passwort-Speicher / Schlüsselbund** | WLAN- und Web-Passwörter sicher ablegen; Browser braucht das ohnehin | mittel |
| 34 | **Scannen** | Dokumente digitalisieren (Simple Scan / Windows Scan) | mittel |
| 35 | **Bildschirmreader (Sprachausgabe)** | Vollständige Barrierefreiheit (Orca-Äquivalent + AT-SPI-artige Schnittstelle + Sprachsynthese). Sehr aufwendig, aber ohne Alternative für blinde Nutzer | groß |
| 36 | **Diktat/Spracheingabe, Übersetzung, Wetter, Karten, Nachrichten-Widgets** | Komfort, Windows liefert vieles davon mit | mittel je Stück |
| 37 | **Virtualisierung / Kompatibilitätsschicht für Windows-Programme** | Der ehrliche Notausgang: das eine Spezialprogramm, das es nur für Windows gibt. Verhindert Rückwechsel wirksamer als jede eigene App | groß |
| 38 | **Spiele/Zeitvertreib (Solitär o. ä.)** | Windows hat es, wirkt als Signal von „fertigem" System | klein |

---

## Umsetzungsreihenfolge (empfohlen)

1. **Fundament zuerst:** Fensterverwaltung, Taskleiste/Starter, Zwischenablage, MIME-Registry, Datei-Dialoge, Audio. Alles andere hängt daran.
2. **Der große Hebel:** Browser portieren. Er ersetzt allein Mail, Office, Karten, Medien, Nachrichten — und halbiert damit Stufe 2 und 3.
3. **Die billigen Siege:** Bildbetrachter, Taschenrechner, Screenshot, ZIP, Zwischenablage-Verlauf. Zusammen wenige Wochen, aber sie prägen den Eindruck „vollständiges System" am stärksten.
4. **Nicht selbst bauen:** PDF-Rendering, Video-/Audio-Dekodierung, Drucken, Schriftrendering. Existierende Bibliotheken (PDFium/MuPDF, ffmpeg/libmpv, CUPS, HarfBuzz/FreeType) einbinden — Eigenentwicklung kostet hier Jahre ohne Gewinn.
5. **Barrierefreiheit früh verankern:** Skalierung, Fokus-/Tastaturnavigation und eine Zugänglichkeits-Schnittstelle müssen im Toolkit-Design stecken. Nachträglich ist es ein Vielfaches an Aufwand.

**Häufigste Abbruchgründe in der Praxis** (in dieser Reihenfolge): WLAN geht nicht → Drucker geht nicht → Browser rendert Banking-Seite falsch → Audio/Bluetooth-Kopfhörer funktionieren nicht → ein bestimmtes Windows-Programm fehlt. Diese fünf Punkte entscheiden mehr über den Rückwechsel als jedes fehlende Zubehörprogramm.

**Sources:**
- [Microsoft: Windows 11 24H2 installs 36 inbox apps](https://www.windowslatest.com/2025/07/16/microsoft-windows-11-24h2-installs-36-inbox-apps-now-fully-up-to-date/)
- [Reimagining the apps included with Windows 11 – Windows Insider Blog](https://blogs.windows.com/windows-insider/2022/05/10/reimagining-the-apps-included-with-windows-11/)
- [Inbox Microsoft Store apps update in Windows media – Windows IT Pro Blog](https://techcommunity.microsoft.com/blog/windows-itpro-blog/inbox-microsoft-store-apps-update-in-windows-media/4433131)
- [GNOME Core Applications – Wikipedia](https://en.wikipedia.org/wiki/GNOME_Core_Applications)
- [Apps for GNOME](https://apps.gnome.org/)
- [Ubuntu Wiki: DefaultApps](https://wiki.ubuntu.com/DefaultApps)
- [A Complete Guide to Kubuntu Default Apps and Their Purposes](https://www.ubuntubuzz.com/2023/01/a-complete-guide-to-kubuntu-default-apps-and-their-purposes.html)
- [Dolphin (file manager) – Wikipedia](https://en.wikipedia.org/wiki/Dolphin_(file_manager))
- [Accessibility stack – Ubuntu Desktop documentation](https://documentation.ubuntu.com/desktop/en/latest/explanation/accessibility-stack/)
- [Orca – A free and open source screen reader](https://orca.gnome.org/)

---

### Teilaufgabe 2: Recherchiere technisch praezise, was fuer VIDEO- UND AUDIO-WIEDERGABE in einem selbstgebauten Betriebssystem noetig ist, das heute NUR einen linearen Rahmenpuffer (Framebuffer) hat, KEINE GPU-Treiber, KEINE Soundtreiber und KEINE fremden Bibliotheken einbinden will (alles selbst geschrieben in einer eigenen Sprache). Beantworte konkret: (a) Welcher Container und welcher Codec ist mit vertretbarem Aufwand selbst dekodierbar? Vergleiche dabei ausdruecklich: unkomprimiertes WAV, MP3, Vorbis, Opus, FLAC fuer Audio; MJPEG, VP8/VP9, AV1, H.264 fuer Video. Nenne jeweils die ungefaehre Groessenordnung an Code und die Rechenlast fuer Software-Dekodierung bei 720p30. (b) Warum ist H.264 rechtlich und technisch heikel? (c) Welcher Audio-Chip ist auf echter PC-Hardware am realistischsten selbst anzusteuern - Intel HD Audio (HDA) oder AC97 - und wie aufwendig ist ein minimaler Wiedergabe-Treiber? (d) Was braucht es fuer Zeitsteuerung und Lippensynchronitaet zwischen Bild und Ton? Antworte auf Deutsch, mit Zahlen wo moeglich, und sag ehrlich, was unrealistisch ist.
# Video- & Audiowiedergabe auf einem selbstgebauten OS (nur Framebuffer, alles selbst geschrieben)

Kurzfassung vorab: **Machbar ist ein eigener Container + PCM/WAV (später FLAC oder MP3) + MJPEG.** Alles darüber (VP9, AV1, H.264) ist für ein Ein-Personen-Projekt in eigener Sprache realistisch nicht abschließbar. Der eigentliche Engpass ist am Ende oft nicht der Codec, sondern die **Framebuffer-Schreibbandbreite** und die **Zeitbasis**.

---

## (a) Container & Codec: was ist selbst dekodierbar?

### Container

| Container | Parser-Aufwand | Bewertung |
|---|---|---|
| **Eigenes Format** | 150–300 LOC | **Empfehlung.** Header (fps, Samplerate, Kanäle) + Paketstrom mit 64-bit-PTS in µs. Löst Interleaving und Sync in einem Tag. |
| WAV (RIFF) | 200–400 LOC | Trivial, nur Audio. |
| Ogg | 600–1000 LOC | Page-Header, CRC32, Granule-Position, Segment-Tabelle, Packet-Continuation. Machbar. |
| Matroska/WebM (EBML) | 1500–3000 LOC | Variable-Length-IDs/-Größen, Cluster/SimpleBlock, Lacing, Seek-Head. Nervig, aber lesbar. |
| MP4/ISOBMFF | 2000–4000 LOC | Box-Baum, `stbl` mit stts/stsc/stsz/stco/ctts. Der Sample-Table-Kram ist fummelig; Fragmented MP4 ist nochmal ein zweites Format. |
| MPEG-TS | 1000–2000 LOC | 188-Byte-Pakete, PAT/PMT, PES, 33-bit-PCR/PTS mit Wraparound. Nur sinnvoll bei Streaming. |

**Fazit Container:** Für ein Eigen-OS ist ein Fremdcontainer reine Selbstbestrafung. Ein eigenes Format kostet 200 Zeilen und liefert dir exakt die Timestamps, die du für Lippensync brauchst. Ein kleines Konvertierungsskript auf dem Host-PC (ffmpeg) erzeugt dir die Dateien.

### Audio-Codecs

Referenz-Datenrate: 48 kHz, Stereo, 16 bit = **1,536 Mbit/s = 192 KB/s = 691 MB/h**.

| Codec | Decoder-Code (LOC, eigene Sprache, ohne Fremdlib) | CPU-Last (1 Kern, 3 GHz, unoptimiert skalar) | Kernprobleme |
|---|---|---|---|
| **WAV/PCM** | **200–400** | **< 0,1 %** | Nur Endianness + Kanal-Interleaving. Kein Risiko. |
| **FLAC** | **1500–3000** | **~0,5–2 %** | Rice/Golomb-Decoder, LPC-Prädiktion (bis Ordnung 32, Integer-Arithmetik, exakt), Fixed-Prädiktoren, Subframe-Typen, Blockgrößen, CRC. Bit-exakt, verlustfrei → **Bugs fallen sofort auf**. Kompression ~50–60 %. Sehr gutes Preis-Leistungs-Verhältnis. |
| **MP3** | 3500–6000 | ~1–3 % | Huffman-Tabellen (~30 statische Tabellen, ~10–15 KB Daten), Bit-Reservoir (Frames referenzieren Bytes vorheriger Frames – der klassische Stolperstein), Requantisierung mit x^(4/3), Stereo-Modi (MS/Intensity), Alias-Reduktion, 18-Punkt-IMDCT, 32-Band-Polyphase-Synthese (512-Tap-Fenster). Referenz: `minimp3` ≈ 2500 Zeilen C. Machbar in 2–4 Wochen. |
| **Vorbis** | 6000–10000 | ~2–5 % | Setup-Header ist ein Monster: Codebooks mit Huffman + VQ-Lookup (Typ 1/2), Floor 0 (LSP) und Floor 1 (Line-Segment), Residue 0/1/2 mit Partitionierung und Klassifikation, Mapping/Coupling, zwei Blockgrößen mit Fensterüberlappung. `stb_vorbis` ≈ 5500 Zeilen. **Deutlich schwerer als MP3**, kein Vorteil außer Lizenzfreiheit – die MP3 seit 2017 auch hat. |
| **Opus** | 12000–25000 | ~3–8 % | **Zwei komplette Codecs in einem**: SILK (LP-basiert, ≤ 8 kHz Kern, LTP, NLSF-Quantisierung, Stereo-Prädiktion) + CELT (MDCT, PVQ-Codierung, Band-Energie mit Coarse/Fine/Allocation-Trim, Anti-Collapse) + Hybrid-Modus + Range-Decoder + Resampler + PLC. Bit-exakter Konformitätstest zwingend. **Für ein Solo-Projekt unrealistisch.** |

**Empfehlung Audio:** WAV → FLAC → (optional) MP3. Vorbis und Opus überspringen.

### Video-Codecs

Referenz: 1280×720, 30 fps, YUV 4:2:0 = **1,38 MB pro Frame roh**, RGBA-Ausgabe 3,69 MB pro Frame.

| Codec | Decoder-Code (LOC) | CPU-Last 720p30 | Datenrate | Urteil |
|---|---|---|---|---|
| **MJPEG (Baseline JPEG)** | **1500–3000** | **30–90 % eines 3-GHz-Kerns** | 6–15 Mbit/s (0,75–1,9 MB/s), ~3–7 GB/h | **Der klare Sieger.** Nur Intra, kein Referenz-Management, kein Loop-Filter, kein Bitfehler-Fortpflanzungsproblem – ein kaputter Frame ist ein kaputter Frame, nicht ein kaputtes GOP. Bausteine: Huffman-Decoder, Dequantisierung, 8×8-IDCT (Loeffler/AAN, 11 Mult + 29 Add pro 1-D-Durchlauf), Chroma-Upsampling, YCbCr→RGB. Restart-Marker (DRI) ermöglichen triviale Parallelisierung über Kerne. |
| **VP8** | 10000–15000 | ~150–350 % eines Kerns (unoptimiert) | 1,5–3 Mbit/s | Boolean(Range)-Decoder, 4×4/16×16-Intra-Modi, Motion Compensation mit 6-Tap-Subpel-Filter (der Hotspot), Loop-Filter (normal + simple), DCT + Walsh-Hadamard, Probability-Updates. **Grenzwertig**: 3–6 Monate Arbeit, und ohne SIMD wird 720p30 knapp. Realistisch nur bis 480p. |
| **VP9** | 30000–50000 | > 400 % | 0,8–1,5 Mbit/s | Superblöcke bis 64×64 mit rekursiver Partitionierung, 4 Transformationstypen (DCT/ADST-Kombis) in 4 Größen, Compound Prediction, adaptive Wahrscheinlichkeiten mit Backward-Update, Tiles, Segmentation. **Unrealistisch.** |
| **AV1** | 80000–150000 | > 800 %, ohne SIMD nicht echtzeitfähig | 0,5–1 Mbit/s | Zusätzlich CDEF, Loop Restoration (Wiener + Self-Guided), Film Grain Synthesis, Superres, Warped Motion, OBMC, 60+ Intra-Modi. `dav1d` sind ~50k Zeilen C **plus** ~100k Zeilen handgeschriebener Assembler – und die Assembler-Teile sind nicht Luxus, sondern Voraussetzung für Echtzeit. **Absolut unrealistisch.** |
| **H.264 Baseline** | 15000–25000 | ~200–400 % | 2–4 Mbit/s | Siehe (b). |

**Der versteckte Kostenpunkt – Framebuffer-Bandbreite:**
720p30 in RGBA = 1280 × 720 × 4 × 30 = **110 MB/s** reines Schreiben in VRAM. Entscheidend: Wie ist die Framebuffer-Region gemappt?

- **UC (uncached)** – der Default nach UEFI-GOP/VBE, wenn du nichts tust: ~30–100 MB/s. **Damit erreichst du 720p30 niemals.**
- **WC (write-combining)** via MTRR (`IA32_MTRR_PHYSBASE/MASK`, Typ 0x01) oder PAT: 1–4 GB/s. **Pflicht.**
- Zusätzlich: linear vorwärts schreiben, keine Reads aus VRAM, mit 32-Byte-Blöcken oder `movnti`/`movntdq`.

Dazu kommt die YUV→RGB-Konvertierung: 921 600 Pixel × ~8–12 Ops = ~10 MOps/Frame = **300 MOps/s**. Das ist derselbe Größenordnungsbereich wie die IDCT.

**Realistische Startkonfiguration:** 854×480 @ 24 fps MJPEG + 44,1/48 kHz PCM. Das ist mit ~35 % eines Kerns machbar und funktioniert am ersten Tag. 720p30 danach als Optimierungsziel.

---

## (b) Warum H.264 rechtlich und technisch heikel ist

**Rechtlich:**
- H.264/AVC wird über den Patentpool von **Via LA** (früher MPEG LA) lizenziert. **Das letzte US-Patent des Pools (US 7,826,532) läuft erst am 29. November 2027 aus.** Bis dahin ist ein verteilter Software-Decoder formal ein lizenzpflichtiges "AVC Product".
- Es gab historisch eine Freigrenze (erste 100 000 Einheiten/Jahr royalty-frei), und die "Internet Broadcast AVC Video"-Freistellung deckt nur *kostenloses Streaming an Endnutzer* ab – **nicht die Verteilung von Decoder-Software**.
- Via LA hat die Streaming-Gebühren 2026 massiv angehoben (Deckel von 100 000 $ auf gestaffelt bis 4,5 Mio. $/Jahr). Das zeigt: Der Pool ist aktiv und aggressiv, nicht schlafend.
- Praktisch: Ein Hobby-OS ohne Umsatz wird nicht verklagt. Aber sobald das Projekt öffentlich Verbreitung findet, hast du ein formales Problem, das dir jeder Firmen-Justiziar um die Ohren haut. **Bis Ende 2027 gibt es keinen sauberen Weg.** Ab 2028 ist die Patentlage weitgehend entschärft – die technische Lage nicht.

**Technisch:**
- **Bit-Exaktheit ist zwingend.** Anders als bei MJPEG (jedes Bild unabhängig) propagiert bei H.264 jeder einzelne Fehler über das gesamte GOP – bis zum nächsten IDR-Frame. Ein Off-by-one im Deblocking-Filter erzeugt Artefakte, die sich über 250 Frames aufschaukeln. Debuggen ohne Referenz-Decoder ist die Hölle.
- **CABAC** (ab Main Profile): kontextadaptive binäre Arithmetikkodierung mit ~460 Kontextmodellen, inhärent seriell, in optimierten Decodern 30–50 % der Gesamtzeit. Baseline nutzt nur CAVLC – aber Baseline-Streams gibt es in freier Wildbahn kaum.
- **Deblocking-Filter**: der berüchtigtste Teil der Spec. Randstärke-Berechnung (bS 0–4) abhängig von Intra/Inter, Motion-Vektor-Differenzen, Referenzindizes, Koeffizientenpräsenz – dutzende Sonderfälle.
- **Referenzbildverwaltung**: Reference Picture Lists mit Reordering-Kommandos, MMCO (Memory Management Control Operations), Sliding Window, Long-Term-References, POC-Berechnung in drei verschiedenen Typen. Ein Formalismus für sich.
- **Interlacing (PAFF/MBAFF)**: verdoppelt effektiv die Komplexität. Kann man weglassen, dann scheitert man an jedem TV-Stream.
- **Profile/Levels**: High Profile bringt 8×8-Transform, Scaling-Matrizen, Monochrom/4:2:2/4:4:4, 10 bit. Reale Dateien nutzen High Profile.

**Fazit:** H.264 kostet 6–18 Monate Vollzeit für eine korrekte Implementierung und bringt dir gegenüber MJPEG nur Datenrate – die auf lokalem Storage egal ist.

---

## (c) Audio-Chip: HDA oder AC97?

### AC97 (1997, ICH0–ICH7)
- **Deutlich einfacher.** PCI-Gerät, zwei I/O-BARs: NAM (Mixer, BAR0) und NABM (Bus-Master, BAR1). Alles über `in`/`out` auf Ports.
- Minimaler Wiedergabepfad: Mixer aufwecken (Reset Reg 0x00, Master Volume 0x02, PCM Out Volume 0x18), **Buffer Descriptor List** mit bis zu 32 Einträgen (je Adresse + Sample-Anzahl + IOC/BUP-Flags) anlegen, `PO_BDBAR` setzen, `PO_LVI` (Last Valid Index) setzen, Control-Register `PO_CR` Bit 0 (Run) setzen. Fertig.
- **~300–600 LOC.** Ein Wochenende.
- Fallstrick: Der DMA stoppt, sobald der Lesezeiger den LVI erreicht – du musst LVI ständig nachziehen, sonst Underrun.
- **Aber: AC97 ist auf realer Hardware seit ca. 2006–2008 praktisch ausgestorben.** Existiert real nur noch in QEMU (`-device AC97`), VirtualBox und Bochs.

### Intel HD Audio (HDA, Spec 1.0a, 2004)
- **Auf realer PC-Hardware praktisch alternativlos**: quasi jedes x86-System von 2005 bis heute hat einen HDA-Controller (Intel PCH, AMD FCH, NVIDIA HDMI-Audio). Auch in QEMU (`-device intel-hda`/`ich9-intel-hda`) verfügbar → gleicher Code für Emulator und Blech.
- MMIO über BAR0. Ablauf eines Minimal-Treibers:
  1. Controller-Reset (`GCTL` Bit 0 auf 0, warten, auf 1, warten ≥ 521 µs).
  2. `STATESTS` lesen → welche Codec-Slots antworten.
  3. Codec-Kommunikation: entweder **CORB/RIRB**-Ringpuffer (DMA, korrekt) oder die **Immediate Command Register** `ICOI`/`ICII`/`ICIS` (viel einfacher, aber optional in der Spec – funktioniert auf Intel meist, auf manchen AMD-Chips nicht).
  4. Widget-Baum enumerieren: Root Node → Function Group (Audio) → Widgets (Audio Output, Mixer, Selector, Pin Complex). Pfad von einem *Audio Output Converter* zu einem *Pin Complex* mit Default-Device "Line Out"/"Speaker" und Jack-Präsenz suchen.
  5. Pin aktivieren (`SET_PIN_WIDGET_CONTROL`, Out-Enable + ggf. HP-Amp), Amp-Gains setzen (`SET_AMP_GAIN_MUTE`, Output+Input, links+rechts).
  6. Stream: BDL anlegen, `SDnBDPL/U`, `SDnCBL` (Cyclic Buffer Length), `SDnLVI`, `SDnFMT` (z. B. 0x0011 = 48 kHz/16 bit/stereo), Stream-Tag im Converter und im `SDnCTL` gleich setzen, Run-Bit.
- **~1000–2000 LOC** für eine feste Konfiguration 48 kHz / 16 bit / Stereo.
- **Der eigentliche Schmerz ist nicht der Controller, sondern die Codec-Topologie.** Realtek ALC-, Conexant-, IDT/Sigmatel-Codecs haben völlig unterschiedliche Widget-Bäume, Pin-Defaults und Amp-Anordnungen. Linux hat dafür tausende Zeilen Quirk-Tabellen. Eine generische Heuristik ("erster Pin-Complex mit Default-Device = Speaker oder Line-Out, Jack Detect positiv") funktioniert auf grob 70–85 % der Maschinen. Die restlichen 15–30 % bleiben stumm, und du wirst nie herausfinden warum, ohne `codec#0`-Dumps zu vergleichen.

### Empfehlung
**Beides – in dieser Reihenfolge:** AC97 zuerst als schneller Erfolg im Emulator (1 Wochenende, du hörst Ton und kannst deinen Mixer/Ringpuffer/Timing-Code testen), dann HDA für echte Hardware (2–4 Wochen). Der Abstraktionslayer darüber (Ringpuffer, Format, `samples_played()`) bleibt identisch.

**Nicht vergessen:** PC-Speaker über PIT-Kanal 2 + Port 0x61 ist 20 Zeilen und liefert Rechtecktöne – gut für Systemsounds, nutzlos für Musik.

**Alternative USB Audio Class:** herstellerunabhängig standardisiert (kein Quirk-Chaos!), aber erfordert einen kompletten xHCI-Stack (~5000–10000 LOC) inklusive isochroner Transfer-Ringe mit korrekter Frame-Planung. Nur interessant, wenn du USB ohnehin für Tastatur/Maus brauchst.

---

## (d) Zeitsteuerung und Lippensynchronität

### Toleranzen (ITU-R BT.1359-1)
- Wahrnehmungsschwelle: Audio **+45 ms vor** Bild bzw. **−125 ms hinter** Bild.
- Akzeptanzgrenze: **+90 ms / −185 ms**.
- Praktisches Ziel: **± 20 ms**, dann merkt niemand etwas. Ein Frame bei 30 fps = 33,3 ms.

### Grundregel: Audio ist der Master-Clock
Nicht der TSC, nicht der HPET – **die Anzahl der tatsächlich vom DMA abgespielten Samples**.

Grund: Der Audio-Quarz läuft nominell 48 000 Hz, real mit ±100 ppm Abweichung. Über eine Stunde sind das **360 ms Drift**. Wenn du Video an den CPU-Timer hängst und Audio an den Codec-Quarz, laufen beide garantiert auseinander. Wenn du Video an den Sample-Zähler hängst, ist Sync per Konstruktion exakt.

```
t_audio_us = samples_played * 1_000_000 / sample_rate
```

`samples_played` kommt aus:
- **HDA:** `SDnLPIB` (Link Position in Buffer) – auf manchen Controllern ungenau/verzögert. Besser: **DMA Position Buffer** (`DPLBASE`/`DPUBASE`, ein 8-Byte-Eintrag pro Stream, vom Controller per DMA aktualisiert). Auflösung: Byte-genau.
- **AC97:** `PO_CIV` (Current Index Value) + `PO_PICB` (Position In Current Buffer, in Samples) → Position = abgespielte Buffer × Buffergröße + (Buffergröße − PICB).
- Fallback: Interrupt-Zähler (IOC pro BDL-Eintrag) × Samples pro Eintrag. Grober (Auflösung = Buffergröße), aber ausreichend.

### Zeitbasis für alles andere
| Quelle | Auflösung | Bewertung |
|---|---|---|
| **TSC** | ~0,3 ns @ 3 GHz | Beste Wahl, **aber nur mit Invariant TSC** – prüfen: `CPUID.80000007H:EDX[8]`. Muss gegen HPET oder PIT kalibriert werden. |
| **HPET** | 10–100 ns (Periode im Capability-Register in Femtosekunden) | Sauber, monoton, 64 bit (oder 32 bit mit Wrap). Gute Kalibrierreferenz. |
| **PIT** | 838 ns (1 193 182 Hz) | Immer da, ideal zur TSC-Kalibrierung. |
| **Local APIC Timer** | – | Für periodische Interrupts; TSC-Deadline-Modus wenn verfügbar. |
| **RTC/CMOS** | 1 s | Nur für Wanduhrzeit, nutzlos für Sync. |

### Audio-Ringpuffer-Dimensionierung
- BDL mit z. B. **4 Einträgen à 4 ms** (48 kHz × 4 ms × 2 Kanäle × 2 Byte = 768 Byte) → 16 ms Gesamtlatenz, Interrupt alle 4 ms.
- Bei 4 ms Interrupt-Intervall darf dein Refill-Pfad nicht länger als ~2 ms brauchen. Größere Puffer (8–16 ms pro Eintrag, 32–64 ms gesamt) sind für ein Hobby-OS sicherer – Video-Latenz gleicht man durch Vorlauf beim Dekodieren aus.
- **Underrun = hörbarer Klick.** Video-Frame verpasst = niemand merkt's. Deshalb: **Audio-Refill hat immer Vorrang, Video wird nie blockierend gewartet.**

### Video-Präsentationsschleife
```
loop:
  now = t_audio_us()
  frame = peek_next_video_frame()
  if frame.pts_us > now + HALF_FRAME:   -> noch zu früh: schlafen/dekodieren
  if frame.pts_us < now - FRAME_US:     -> zu spät: Frame verwerfen (drop), nächsten holen
  else:                                 -> blitten
```
- **Drop-Strategie:** Nur Frames verwerfen, die nicht als Referenz dienen. Bei MJPEG ist jeder Frame unabhängig → beliebig droppbar. Das ist ein weiteres starkes Argument für MJPEG.
- **Vorlauf-Puffer:** 3–5 dekodierte Frames vorhalten (720p YUV420 = 1,38 MB × 5 = 7 MB RAM), damit ein einzelner langsamer Frame nicht sofort zu einem Aussetzer führt.

### Tearing / Vsync – die schlechte Nachricht
Ohne GPU-Treiber hast du **keinen Vblank-Interrupt**. Optionen:
1. **Tearing akzeptieren.** Bei 30 fps auf 60 Hz sichtbar, aber erträglich.
2. **VGA-Retrace pollen:** Port `0x3DA`, Bit 3 = Vertical Retrace. Funktioniert nur bei VGA-kompatiblen Modi – bei einem UEFI-GOP-Framebuffer typischerweise **nicht**.
3. **Statistisch schätzen:** Refresh-Periode aus EDID (via I²C/DDC am Grafikchip – eigener Aufwand) oder hart annehmen (16,67 ms), Blit-Zeitpunkt phasenverriegelt legen. Halbherzig, aber besser als nichts.
4. **Backbuffer im RAM** rendern und mit einem schnellen linearen WC-Blit rüberkopieren – reduziert die Tearing-Zeitfenster deutlich, weil der Blit nur ~1–3 ms statt der ganzen Dekodierzeit dauert.

### A/V-Offset-Kalibrierung
Deine Audio-Hardware hat eine feste Ausgabelatenz (Puffer + Codec-Pipeline, typisch 5–30 ms). Das ist ein **konstanter Offset**, kein Drift – einmalig messen und als Konstante von `t_audio` abziehen.

---

## Was unrealistisch ist – ehrlich

| Vorhaben | Urteil |
|---|---|
| **AV1-Decoder selbst schreiben** | Unrealistisch. 80k+ LOC, ohne SIMD nicht echtzeitfähig, mehrere Personenjahre. |
| **VP9-Decoder** | Unrealistisch. 30–50k LOC. |
| **H.264 High Profile** | Unrealistisch bis 2027 (Patente) und danach immer noch 6–18 Monate Vollzeit. |
| **Opus-Decoder** | Unrealistisch. Zwei Codecs in einem, bit-exakte Konformität nötig. |
| **HDA-Treiber, der auf *jeder* Maschine Ton macht** | Unrealistisch ohne Quirk-Datenbank. Rechne mit 70–85 % Trefferquote. |
| **Echtes Vsync ohne GPU-Treiber** | Nicht möglich. Tearing einplanen. |
| **1080p60 in Software mit selbstgeschriebenem Codec** | Unrealistisch: allein 500 MB/s Framebuffer-Bandbreite plus Dekodierung. |
| **VP8 in 720p30 ohne SIMD** | Grenzwertig bis unrealistisch. Bis 480p okay. |

**Was dagegen sicher funktioniert (Zeitrahmen für eine Person mit vorhandenem Kernel):**

| Meilenstein | Aufwand |
|---|---|
| Eigener Container + WAV-Playback über AC97 in QEMU | 1–2 Wochen |
| HDA-Treiber (feste 48/16/2, Ringpuffer, Position-Reporting) | 2–4 Wochen |
| Baseline-JPEG-Decoder + YUV→RGB + WC-Framebuffer | 2–4 Wochen |
| A/V-Sync-Layer (Audio-Master, Drop/Repeat, Vorlaufpuffer) | 1 Woche |
| **→ 854×480 @ 24 fps MJPEG + PCM, lippensynchron** | **~2–3 Monate gesamt** |
| FLAC-Decoder ergänzen | +1–2 Wochen |
| Optimierung auf 720p30 (Loeffler-IDCT, Multicore über Restart-Marker, SIMD) | +2–4 Wochen |
| MP3-Decoder ergänzen | +3–5 Wochen |

---

## Zusammenfassung

- **(a)** **Container: eigenes Format** (200 LOC). **Audio: WAV → FLAC (1500–3000 LOC, <2 % CPU) → optional MP3 (3500–6000 LOC).** Vorbis (6–10k LOC) bringt nichts, Opus (12–25k LOC) ist unrealistisch. **Video: MJPEG (1500–3000 LOC, 30–90 % eines 3-GHz-Kerns bei 720p30, 6–15 Mbit/s).** VP8 grenzwertig, VP9/AV1/H.264 raus. Versteckte Kosten: 110 MB/s Framebuffer-Schreiblast → **MTRR/PAT auf Write-Combining stellen ist Pflicht**, sonst scheitert alles.
- **(b)** H.264: Via-LA-Patentpool bis **29.11.2027** aktiv, Decoder-Distribution formal lizenzpflichtig, Gebühren 2026 stark erhöht. Technisch: CABAC, Deblocking-Filter, MMCO/Referenzlisten, Bit-Exaktheit mit GOP-weiter Fehlerfortpflanzung. 6–18 Monate Vollzeit.
- **(c)** **AC97 zum Lernen im Emulator (300–600 LOC, 1 Wochenende), HDA für echte Hardware (1000–2000 LOC, 2–4 Wochen).** AC97 existiert real seit ~2007 nicht mehr; HDA ist auf jedem x86-PC seit 2005. Hauptproblem bei HDA ist nicht der Controller, sondern die herstellerspezifische Codec-Widget-Topologie.
- **(d)** **Audio-Sample-Zähler als Master-Clock** (HDA DMA Position Buffer bzw. AC97 CIV+PICB), TSC/HPET nur als Hilfstimer. Ziel ±20 ms (Grenzen: Audio max. +45 ms vor / −125 ms hinter Bild). Video-Frames droppen/wiederholen, nie blockieren. Vsync ohne GPU-Treiber nicht verfügbar → Tearing einplanen, Backbuffer + schneller WC-Blit minimiert es.

**Sources:**
- [Fraunhofer IIS – mp3 Software, Patents and Licenses](https://www.audioblog.iis.fraunhofer.com/mp3-software-patents-licenses)
- [MacRumors – MP3 licensing program terminated as patents expire](https://www.macrumors.com/2017/05/15/mp3-format-terminated/)
- [Via Licensing Alliance – AVC/H.264 Programm](https://www.via-la.com/licensing-programs/avc-h-264/)
- [Tom's Hardware – H.264 streaming license fees jump to $4.5 million (2026)](https://www.tomshardware.com/service-providers/streaming/h264-streaming-license-fees-jump-from-100000-to-4-5-million)
- [OSnews – US Patent Expiration for MP3, MPEG-2, H.264](https://www.osnews.com/story/24954/us-patent-expiration-for-mp3-mpeg-2-h264/)
- [OSDev Wiki – Sound](https://wiki.osdev.org/Sound)
- [OSDev Wiki – AC97](https://wiki.osdev.org/AC97)
- [OSDev Forum – Configuring Intel HDA](https://forum.osdev.org/viewtopic.php?f=1&t=33741)
- [OSDev Forum – HD Audio to AC97](https://f.osdev.org/viewtopic.php?t=28314)

---

### Teilaufgabe 3: Recherchiere, welche SYSTEM-BAUSTEINE (nicht Anwendungen) einem selbstgebauten Betriebssystem typischerweise fehlen, wenn es bereits Folgendes hat: Kernel mit Speicherverwaltung, Prozesse, Scheduler, Syscalls, eigene Programmiersprache mit Selbst-Uebersetzung, VFS mit eigenem Dateisystem und FAT, NVMe- und virtio-Treiber, Netzwerk mit TCP/IP und TLS 1.3, eigener Fensterserver im Kernel mit Fensterverwaltung, Taskleiste, Themes, Tastatur- und Maustreiber, USB/xHCI, Paketformat mit Generationen. Was fehlt einem solchen System noch, um als vollwertiges Betriebssystem zu gelten? Denke an: Zwischenablage, Drag-and-Drop, Schriftverwaltung, Mehrsprachigkeit und Tastaturlayouts, Zeitzonen und Sommerzeit, Energieverwaltung und Standby, Bluetooth, WLAN, Drucker, Kamera, Audio, Wechseldatentraeger und Automount, Papierkorb, Dateisuche mit Index, Rechteverwaltung, Prozessverwaltung fuer den Nutzer, Absturzberichte, Protokollierung, Aktualisierungen, Sicherung, Barrierefreiheit, Bildschirmschoner und Sperrbildschirm, mehrere Monitore, Skalierung fuer hohe Aufloesungen. Priorisiere nach Nutzen fuer einen Alltagsnutzer und schaetze den Aufwand. Antworte auf Deutsch.
## Kurzfassung

Was du hast, ist ein **Kernel plus GUI-Prototyp**. Was fehlt, ist zu ~60 % gar nicht aus deiner Liste, sondern die **Sockelschicht darunter**: Ohne Systembus, Dienstverwaltung, Sitzung, Geräte-Hotplug, Ereignis-Multiplex und Zeitbasis lassen sich Zwischenablage, Automount, Standby, Papierkorb usw. nur als Einzelhacks bauen — und müssen später alle nochmal gebaut werden. Reihenfolge ist hier wichtiger als Umfang.

**Aufwandsskala** (ein erfahrener Entwickler bzw. eine Agenten-Runde, ohne Fremdcode, alles in Firn selbst):
S = 2–5 Tage · M = 1–3 Wochen · L = 1–3 Monate · XL = > 3 Monate

---

## A) Die blinden Flecken — nicht in deiner Liste, aber P0

Diese Punkte kommen in deiner Aufzählung nicht vor und sind trotzdem Voraussetzung für die halbe Liste.

| # | Baustein | Warum P0 | Aufwand |
|---|---|---|---|
| A1 | **Ereignis-Multiplex** (`poll`/`epoll`-Äquivalent) + **Threads pro Prozess** + Futex/Mutex | Ohne das kann kein Programm gleichzeitig auf Fenster-, Netz- und Datei-Ereignisse warten. Jede GUI-App braucht es. | M |
| A2 | **Init / Dienstverwaltung** (PID 1): Startreihenfolge, Abhängigkeiten, Neustart bei Absturz, Socket-Aktivierung, sauberes Herunterfahren | Ohne das gibt es keine „Dienste", also keinen Automount-Dienst, Netzdienst, Zeitdienst … | M |
| A3 | **Systembus / IPC mit Rechten** (D-Bus-Äquivalent): Namen, Methoden, Signale, Rechteprüfung | **Der wichtigste einzelne Posten.** Zwischenablage, Drag-and-Drop, Benachrichtigungen, Automount-Meldungen, Energieereignisse, Sperrbildschirm, Einstellungen — alle brauchen ihn. Baust du ihn nicht, baust du ihn siebenmal ad hoc. | M–L |
| A4 | **Sitzung + Anmeldung**: Login, Benutzerwechsel, Sitzungsobjekt, „wem gehört Tastatur/Bildschirm/Audio" (Seat) | Voraussetzung für Rechteverwaltung, Sperrbildschirm, Mehrbenutzer. | M |
| A5 | **Gerätemanager / Hotplug** (udev-Äquivalent): Gerätebaum, Anstecken/Abziehen als Ereignis, Treiberbindung, Firmware-Laden | Voraussetzung für Wechseldatenträger, Kamera, Drucker, Bluetooth, WLAN, Monitor-Anstecken. | M |
| A6 | **ACPI**: Tabellen (RSDP/FADT/MADT/MCFG), Herunterfahren (S5), Neustart, Einschalttaste, Akku, Deckel | Ohne ACPI kein echtes Ausschalten, kein Standby, keine Energieverwaltung, kein sauberes SMP. Voller AML-Interpreter = XL; **Abkürzung: nur Tabellen + S5 + Ereignisse** = M. | M (voll: XL) |
| A7 | **SMP / Mehrkern** + hochauflösende Zeitgeber (falls noch einkernig) | Auf echter Hardware sonst unbrauchbar langsam. | M–L |
| A8 | **Dateisystem-Robustheit**: Journal oder Copy-on-Write, `fsck`, definierte `fsync`-Semantik, Seiten-Cache mit Schreibrückstellung | Ein Dateisystem ohne Stromausfall-Sicherheit ist ein Datenverlust mit Zeitzünder. | L |
| A9 | **Dynamisches Linken / ABI-Vertrag** oder die bewusste Entscheidung „alles statisch" + Symbolversionen | Sonst zerbricht jedes Paket bei jedem Kernel-/Bibliotheks-Update. Betrifft direkt dein Generationen-Modell. | M |
| A10 | **Speicherdruck**: Auslagerung oder Komprimierung, OOM-Auswahl, Reservenpuffer | Ohne das friert das System bei voller RAM-Auslastung ein statt zu reagieren. | M |
| A11 | **Benachrichtigungen** (Systemdienst + Anzeige in der Leiste) | Fehlt in deiner Liste, wird aber von Update, Automount, Akku, Absturz gebraucht. | S–M |
| A12 | **Sicherheitsgrundlagen**: ASLR, W^X, Stack-Schutz, Syscall-Argumentprüfung, signierter Bootpfad | Du hast bereits signierte Quellen im PLAN — die Laufzeit hinkt hinterher. | M |
| A13 | **Grafik-Kompositor mit Vsync / virtio-gpu bzw. GPU-Beschleunigung** | Fensterserver ohne Vsync = sichtbares Reißen; ohne 2D-Beschleunigung ruckelt jede Skalierung. virtio-gpu 2D = M, echte GPU = XL. | M (echt: XL) |

---

## B) Deine Liste — nach Alltagsnutzen priorisiert

### P1 — spürbar bei jeder Sitzung, baubar in QEMU

| Baustein | Umfang / Fallstricke | Aufwand |
|---|---|---|
| **Zwischenablage** | Stufe 1: nur Text im Fensterserver = S. Richtig: Besitzermodell (Inhalt bleibt beim Quellprogramm), Typenliste, verzögerte Übergabe, große Daten über geteilten Speicher, Auswahl vs. Ablage. Braucht A3. | S → M |
| **Protokollierung** | Kernel-Ringpuffer, strukturierte Einträge (Zeit, Dienst, Stufe), Rotation, Abfragewerkzeug. Voraussetzung für jede Fehlersuche auf echter Hardware. **Sehr hoher Nutzen pro Aufwand.** | S–M |
| **Absturzberichte** | Speicherabbild bei Signal, Rückverfolgung mit Firn-Symbolen, Kernel-Panik-Bildschirm mit Stapel, Ablage + Anzeige. Firn-Compiler muss Debug-Symbole ausgeben. | M |
| **Prozessverwaltung für Nutzer** | Aufgabenliste, CPU/Speicher pro Prozess, „Beenden erzwingen". Braucht Zähler im Scheduler. | S |
| **Zeitzonen + Sommerzeit** | Intern konsequent UTC, tzdata-Format lesen (oder eigenes kompaktes Format erzeugen), lokale Formatierung, NTP-Client mit Sprungkorrektur. Dein `/etc/zeit.conf` hat bisher keinen echten Konsumenten. | M |
| **Tastaturlayouts + Mehrsprachigkeit** | Layouttabellen (de/en/…), AltGr, Tote Tasten, Compose, Umschalten in der Leiste; dazu Übersetzungskatalog + Locale (Datum, Zahlen, Sortierung). Ohne das ist Umlaut-Eingabe Glückssache. | M |
| **Schriftverwaltung** | Der unterschätzteste Posten. TrueType-Rasterung mit Hinting/Kantenglättung, Unterschneidung, Schriftfallback-Kette, Rasterspeicher, Unicode-Zeilenumbruch. Latein-only geht in M, sauber (Formung, Bidi, CJK) ist L–XL. | M → L |
| **Skalierung + mehrere Monitore** | EDID über GOP/DisplayPort lesen, Modus setzen, Skalierungsfaktor im Fensterserver, Cursor und Fensterplatzierung pro Monitor, Anstecken zur Laufzeit. Nachträglich einzubauen ist teuer — **jetzt im Fensterserver vorsehen.** | M–L |
| **Wechseldatenträger + Automount** | USB-Massenspeicher/UAS über dein xHCI, Erkennen, FAT einhängen, Anzeige in der Leiste, sicheres Auswerfen (Puffer leeren!). Braucht A5. | M |
| **Papierkorb** | Pro Datenträger `.Trash`, Metadaten (Originalpfad, Zeit), Wiederherstellen, Größenbegrenzung, Automatik. Klein, aber alltäglich. | S |
| **Sperrbildschirm + Bildschirmschoner** | Leerlaufzähler, eigener Prozess, exklusive Eingabe, sicherer Ausfallzustand („bleibt gesperrt, wenn ich abstürze"), Kennwortprüfung über Sitzung (A4). | S–M |
| **Sicherung + Wiederherstellung** | Du hast die Definition (PLAN + secrets + config + state, 1,23 %). Es fehlt: **Wiederherstellung auf leeres Blech**, Zeitpunkte/Historie, Prüfung der Sicherung, und die Trennung Passwörter/Konten laut deinem Sicherheitsgrundsatz. | M |
| **Aktualisierungen** | Generationen sind da — es fehlt: Aktualisieren im laufenden Betrieb, A/B-Umschaltung des Bootpfads, **automatisches Rückrollen bei Fehlstart** (Bootzähler/Watchdog), signierte Kanäle, Deltas. Ohne Rückrollen ist ein Update auf echter Hardware Russisch Roulette. | M–L |
| **Rechteverwaltung** | uid/gid im VFS durchsetzen, Zugriffsprüfung bei jedem Syscall, setuid/Rechteabgabe, Administratorabfrage in der GUI. Teilweise vorhanden (accounts im PLAN), Durchsetzung fehlt. | M |
| **Audio** | Intel HDA-Treiber (M–L) + Mischer/Server (Formatumwandlung, Lautstärke pro Programm, Gerätewechsel) + Latenzpuffer. In QEMU nur begrenzt realistisch testbar. | L |
| **Energieverwaltung (Basis)** | Leerlauf-Halt (HLT/C-States), Bildschirm dimmen und abschalten, Akku- und Netzteilanzeige, CPU-Frequenz. Ohne das: Notebook heiß, Akku 90 Minuten. | M |
| **Drag-and-Drop** | Protokoll im Fensterserver: Typenaushandlung, Aktion (kopieren/verschieben/verweisen), Ziel-Rückmeldung, Cursor-Zustand, Ziehen zwischen Programmen. Baut auf dem Typmodell der Zwischenablage auf — **beides zusammen entwerfen.** | M |
| **Dateisuche mit Index** | Die eigentliche Arbeit ist die **Änderungsbenachrichtigung im VFS** (inotify-Äquivalent), nicht der Index. Danach: Durchlauf, invertierter Index, Abfragesprache, Inhaltsauszug pro Dateityp. | M–L |

### P2 — wichtig, aber teuer oder hardwareabhängig

| Baustein | Bemerkung | Aufwand |
|---|---|---|
| **Standby (S3 / Suspend-to-RAM)** | Der berüchtigtste Posten überhaupt: **jeder** Treiber braucht Anhalten/Wiederaufnehmen, Zustandssicherung, Wiederherstellung der Gerätetabellen, Neuaufsetzen von xHCI/NVMe/Grafik. Praktisch nicht in QEMU zu Ende zu entwickeln. Vorschlag: S5 (Ausschalten) und Ruhezustand auf Platte (S4-artig, eigenes Abbild) sind billiger und liefern 80 % des Nutzens. | L–XL |
| **WLAN** | 802.11-Stapel + WPA2/WPA3-Supplicant + Firmware-Laden + Regulierungsdomäne + Treiber pro Chip (iwlwifi-Klasse ist ein eigenes Projekt). Laut deinem Plan ohnehin erst nach dem ersten echten Hardwarestart. **Größter Einzelposten der Liste.** | XL |
| **Bluetooth** | HCI-Transport (USB) + L2CAP + SDP + Paarung/Verschlüsselung + Profile (HID für Maus/Tastatur, A2DP für Kopfhörer, braucht SBC-Kodierer). Zwei bis drei Ebenen unter der Sichtbarkeit. | XL |
| **Drucker** | Billigster Weg: **IPP-Everywhere über Netz** (kein Treiber pro Modell, Raster/URF oder PDF senden) — L. Über USB + PCL/Postscript pro Modell: unbegrenzt. | L |
| **Kamera** | USB-Video (UVC) über dein xHCI, MJPEG/YUV, Format- und Bildratenaushandlung, Berechtigungsabfrage, Anzeige-Weiterleitung. | M–L |
| **Barrierefreiheit** | Zweistufig: Kontrastthemen, Schriftvergrößerung, Bildschirmlupe, Tastaturbedienung ohne Maus, Einrastfunktion = S–M. Echter Bildschirmleser (Bedienelementbaum aller Programme + Sprachausgabe) = XL und muss von Anfang an **im Fensterserver-Protokoll** vorgesehen sein — das ist die Entscheidung, die du jetzt triffst oder nie. | M / XL |
| **Programm-Sandbox + Berechtigungen** | Datei-/Netz-/Kamera-/Mikrofonzugriff pro Programm, Portale statt Vollzugriff. Passt gut zu deinem Paketformat. | L |
| **Datenträgerverschlüsselung + Schlüsselbund** | Passt zu deinem Grundsatz „Backup ohne Geheimnisse". | M–L |
| **Netzwerkfreigaben (SMB/NFS-Client)** | Alltag im Heimnetz, aber verzichtbar. | L |

---

## C) Empfohlene Reihenfolge (Abhängigkeiten, nicht Wunschliste)

1. **Sockel-Runde:** A1 (Ereignis-Multiplex + Threads) → A2 (Init) → A3 (Systembus) → A4 (Sitzung) → A5 (Hotplug). Das ist der Flaschenhals für 12 weitere Punkte.
2. **Betriebstauglichkeit:** Protokollierung → Absturzberichte → Prozessverwaltung → Update mit Rückrollen. Ohne diese vier ist die Fehlersuche auf echter Hardware blind — und laut deinem Plan ist genau das der nächste Schritt (JARVIS-Helper auf OrientOS).
3. **Hardware-Brücke:** ACPI-Tabellen + S5 + SMP + EDID/Modus + Wechseldatenträger. Das ist das Minimum, damit ein echtes Gerät bootet, ausschaltet und einen Stick lesen kann.
4. **GUI-Kernstück:** Typmodell für Zwischenablage **und** Drag-and-Drop zusammen entwerfen, dann Schrift, dann Skalierung/Mehrmonitor. Alle drei sind nachträglich teuer.
5. **Alltag:** Zeit/Zeitzonen, Tastaturlayouts, Papierkorb, Sperrbildschirm, Benachrichtigungen, Rechteverwaltung, Energie-Basis, Suche.
6. **Erst nach echter Hardware:** Audio, WLAN, Standby, Bluetooth, Kamera, Drucker.

---

## D) Zwei Entscheidungen, die du *jetzt* treffen musst

- **Barrierefreiheits-Baum im Fensterserver-Protokoll**: nachträglich nachrüsten heißt, jedes Programm nochmal anzufassen. Kosten jetzt: klein. Kosten später: alles.
- **Typ-/Datenmodell für Zwischenablage + DnD + geteilten Speicher**: dasselbe Argument. Ein einziges Modell, drei Nutzer (Zwischenablage, DnD, Fensterinhalte).

Ebenfalls jetzt zu klären: **statisch oder dynamisch gelinkt** — das bestimmt, ob dein Generationen-/Paketmodell Bibliotheks-Updates überhaupt sinnvoll ausdrücken kann.

---

## E) Grobe Gesamtschätzung

| Block | Aufwand |
|---|---|
| A) Sockel P0 (A1–A12, ACPI abgekürzt) | ~6–10 Monate |
| B) P1 aus deiner Liste | ~8–12 Monate |
| C) P2 ohne WLAN/Bluetooth/Bildschirmleser | ~6–9 Monate |
| WLAN + Bluetooth + Standby + echter Bildschirmleser | jeweils eigenes Teilprojekt, zusammen ~1,5–2 Jahre |

„Vollwertig für einen Alltagsnutzer" ist erreicht nach **A + B + Audio + Wechseldatenträger** — WLAN, Bluetooth und Drucker sind schmerzhaft, aber per Kabel/Netz umgehbar. Standby ist das einzige P2, dessen Fehlen ein Notebook wirklich disqualifiziert.

---

### Teilaufgabe 4: Recherchiere, wie ein SNIPPING-TOOL bzw. Bildschirmfoto-Werkzeug technisch aufgebaut ist und welche Faehigkeiten es im Betriebssystem voraussetzt. Beantworte konkret: (a) Welche Aufnahmearten erwartet man heute (ganzer Bildschirm, einzelnes Fenster, freier Ausschnitt, verzoegerte Aufnahme, Bildlauf-Aufnahme, Bildschirmvideo)? (b) Wie wird technisch der Bildschirminhalt abgegriffen, wenn der Fensterserver selbst zeichnet - und welche Rolle spielt eine Overlay-Ebene fuer die Auswahl des Ausschnitts? (c) Welche SICHERHEITSFRAGEN wirft das auf: Warum ist ein Syscall, mit dem jedes Programm den Bildschirm auslesen kann, ein Problem, und wie loesen Windows, macOS und Wayland das? (d) Was muss ein einfacher Bildbearbeiter danach koennen (zuschneiden, markieren, Pfeil, Text, verpixeln)? (e) Welche Bildformate zum Speichern, und wie aufwendig ist ein eigener PNG-Kodierer mit deflate im Vergleich zu PNG mit unkomprimierten Bloecken? Antworte auf Deutsch, technisch praezise.
# Snipping-Tool: technischer Aufbau, OS-Anforderungen, Sicherheitsmodell

## (a) Erwartete Aufnahmearten (Stand 2026, Marktstandard)

| Modus | Beschreibung | Technische Voraussetzung |
|---|---|---|
| **Vollbild** | ein Display, alle Displays kombiniert | Zugriff auf Framebuffer/Scanout pro Output; Umgang mit unterschiedlichen DPI-Skalierungen und HDR pro Monitor |
| **Einzelfenster** | Fenster inkl./exkl. Schatten & Titelleiste | Fensterliste + Fenster-Geometrie vom Fensterserver; ideal Composition-Tree-Zugriff, damit verdeckte Fenster trotzdem sauber kommen |
| **Rechteck-Auswahl** | Drag-Rechteck, Standardfall | Overlay-Ebene + Zeigerereignisse (s. b) |
| **Freiform / Lasso** | polygonaler oder Freihand-Pfad, Rest transparent/weiß | Pfad → Maske → Alpha-Kanal |
| **UI-Element / Auto-Snap** | Hover rastet auf Fenster, Toolbar, DOM-Element ein | Fensterrechtecke aus dem WM; für Feineinrastung Accessibility-/UI-Automation-Bäume |
| **Verzögerte Aufnahme** | 3/5/10 s Timer | nötig, um Menüs, Tooltips, Hover-Zustände zu erwischen (Popup schließt sonst beim Klick ins Overlay) |
| **Bildlauf-Aufnahme** | ganze Webseite/Chat-Verlauf | schwierigster Modus, s. unten |
| **Bildschirmvideo** | + optional Mikrofon, System-Audio, Kamera-PiP, Mausklick-Visualisierung | kontinuierlicher Stream statt Einzelbild, Hardware-Encoder |
| **Zusatz heute erwartet** | Sofort-Kopie in Zwischenablage, OCR/Texterkennung aus dem Bild, QR-Code-Lesen, „Bild als Datei ziehen", Cloud-/Share-Ziel, Verlauf der letzten N Aufnahmen | |

**Bildlauf-Aufnahme** hat drei mögliche Umsetzungen:
1. **Blind-Stitching** (universell, unzuverlässig): wiederholt aufnehmen → synthetisches Scroll-Event senden → warten → erneut aufnehmen → überlappende Bänder per Phasenkorrelation oder Template-Matching (normalisierte Kreuzkorrelation über einen Streifen) ausrichten und zusammensetzen. Probleme: sticky Header/Footer (müssen erkannt und dedupliziert werden), Lazy Loading, Parallax, Animationen, variable Scroll-Schrittweite, `overflow:hidden`-Container.
2. **Semantisch über Accessibility-API**: UI Automation `IScrollProvider` (Windows) bzw. AX-`kAXScrollAreaRole` (macOS) — man kennt die tatsächliche Scrollposition und kann exakt versetzen. Erfordert Barrierefreiheits-Berechtigung.
3. **App-spezifisch**: Browser über CDP `Page.captureScreenshot {captureBeyondViewport:true}`. Am saubersten, aber nur für Browser.

Merke: Scroll-Capture braucht **synthetische Eingaben** — das ist eine *zweite*, deutlich sensiblere Berechtigung als reines Lesen (Input Injection ≈ Fernsteuerung).

---

## (b) Wie der Bildschirminhalt technisch abgegriffen wird

### Grundsituation
Auf allen modernen Systemen zeichnet **nicht** die Anwendung in einen gemeinsamen Bildspeicher, sondern jede App rendert in ihren **eigenen Off-Screen-Puffer** (GPU-Textur / DMA-BUF / IOSurface / DXGI-Surface). Ein **Compositor** (DWM, WindowServer, Wayland-Compositor, KWin/Mutter) setzt diese Puffer zum finalen Bild zusammen und übergibt es dem Scanout der GPU. Der Compositor ist damit die *einzige* Instanz, die das Gesamtbild besitzt. Ein Screenshot-Tool muss ihn also entweder fragen oder den Scanout-Puffer abgreifen.

### Windows
- **GDI `BitBlt(GetDC(NULL), …)`** — legacy, langsam, liefert oft schwarze Frames bei Hardware-Overlay/DRM/Fullscreen-Exclusive.
- **DXGI Desktop Duplication (`IDXGIOutputDuplication`)** — der zusammengesetzte Desktop-Frame als D3D11-Textur, inkl. Dirty-Rects, Move-Rects und **separatem Mauszeiger** (Position + Shape, damit man den Cursor optional einblenden kann). Ganzer Bildschirm, keine Einzelfenster.
- **`Windows.Graphics.Capture` (WinRT)** — moderner Weg, kann **Display *oder* HWND** erfassen, liefert Frames über einen `Direct3D11CaptureFramePool`. Mit `GraphicsCapturePicker` und **gelbem Rahmen-Indikator** als Sichtbarkeitszeichen.
- Ausgabe ist immer eine GPU-Textur → für die Weiterverarbeitung `CopyResource` in eine **Staging-Textur** (`D3D11_USAGE_STAGING` + `CPU_ACCESS_READ`) und `Map()`. Der CPU-Readback über PCIe ist der Flaschenhals; für Video hält man die Frames auf der GPU und übergibt sie direkt dem Encoder.

### macOS
- **ScreenCaptureKit** (`SCStream`, `SCShareableContent`, `SCContentFilter`, `SCContentSharingPicker`) ist heute der einzige empfohlene Weg. Erlaubt Filter wie „nur diese App", „alles außer diesem Fenster". Frames kommen als `CMSampleBuffer` mit `IOSurface`-Backing.
- `CGWindowListCreateImage`, `CGDisplayCreateImage`, `CGDisplayStream`, `AVCaptureScreenInput` sind **seit macOS 15 deprecated** und lösen zusätzlich Warn-Dialoge aus.
- Referenzverhalten liefert das eingebaute `screencapture(1)` / Screenshot.app.

### Wayland
Es gibt bewusst **keinen Kernpfad**, über den ein Client fremde Pixel liest. Zwei Wege:
- **Portal (unprivilegiert, sandbox-tauglich)**: D-Bus-Interfaces `org.freedesktop.portal.Screenshot` (Einzelbild) und `org.freedesktop.portal.ScreenCast` (Stream). Der Compositor-Backend zeigt den Auswahldialog, die Pixel kommen als **PipeWire-Stream** über einen übergebenen Filedeskriptor — typischerweise als DMA-BUF, also ohne Kopie.
- **Privilegierte Protokolle**: `ext-image-capture-source-v1` + `ext-image-copy-capture-v1` (2024/25 in wayland-protocols gemerged, ersetzen das deprecated `wlr-screencopy-unstable-v1`). Der Compositor gibt diese nur an per Allowlist/`wl_security_context` autorisierte Clients frei.
- X11 (Legacy): `XGetImage` auf das Root-Window — genau das Modell, das Wayland abschaffen wollte.

### Rolle der Overlay-Ebene
Die Auswahl-UI ist ein **eigenes Vollbild-Fenster**, technisch charakterisiert durch:
- always-on-top, über allen Fenstern, ohne Dekoration, pro Monitor eines (oder ein Fenster über den vereinigten virtuellen Desktop);
- **transparent bzw. per-pixel-alpha** (Windows: `WS_EX_LAYERED|WS_EX_TOPMOST|WS_EX_TOOLWINDOW`, `UpdateLayeredWindow`/DirectComposition; macOS: `NSWindow` mit `.isOpaque=false`, `backgroundColor=.clear`, hoher `windowLevel`; Wayland: `wlr-layer-shell` Layer `overlay` mit `keyboard_interactivity` exklusiv);
- **Pointer-/Keyboard-Grab**, damit `Esc` immer ankommt und der Klick nicht an die App darunter geht;
- Cursor auf Fadenkreuz, Lupe mit Pixelraster und Farb-Pipette, Live-Anzeige der Auswahlmaße, snapping auf erkannte Fensterrechtecke, Nachjustieren über Anfasser.

**Zentraler Kniff — „Freeze Frame":** Man nimmt den Bildschirm **zuerst** auf und zeigt das Standbild formatfüllend im Overlay an; darauf zeichnet man die Abdunklung außerhalb der Auswahl. Vorteile: (1) das Overlay kann sich unmöglich selbst mitfotografieren (sonst Rekursion/Selbstverdunkelung), (2) Animationen und Videos unter dem Overlay „laufen nicht weg", (3) die eigentliche Aufnahme ist danach nur ein **Zuschnitt eines bereits vorhandenen Bildes** — kein zweiter Capture-Call, kein Timing-Problem. Beim Alternativverfahren (Overlay wirklich transparent, Aufnahme nach dem Loslassen) muss man das Overlay erst ausblenden, einen Compositor-Frame abwarten und dann erfassen — fehleranfällig und flackernd.

Nebeneffekt: HiDPI. Overlay-Koordinaten sind in **logischen Punkten**, der Framebuffer in **physischen Pixeln**. Die Auswahl muss mit dem Skalierungsfaktor des jeweiligen Monitors multipliziert und auf ganze Pixel gerundet werden, sonst gibt es unscharfe Ein-Pixel-Ränder — bei gemischten Skalierungen (100 % + 150 %) pro Monitor separat.

---

## (c) Sicherheitsfragen

### Warum ein „Screenshot-Syscall für jedermann" ein Problem ist
Der Bildschirminhalt ist die **Aggregation aller Vertraulichkeit im System**, unabhängig von Dateirechten: Passwortmanager im geöffneten Zustand, TOTP-Codes, Banking-TANs, Klartext von Ende-zu-Ende-verschlüsselten Messengern, Recovery-Seeds, medizinische Daten, Quellcode. Ein einziger Leseprimitiv umgeht damit die gesamte Datei- und Prozessisolation.

Verschärfend:
1. **Kontinuierlich statt einmalig** — 5 fps über Stunden ist faktisch eine Videoüberwachung des Nutzers; mit OCR wird daraus ein durchsuchbarer Textstrom, und Netzwerktraffic von wenigen kB/s reicht dafür aus.
2. **Kein Nutzerbezug** — der Nutzer merkt nichts. Es gibt keine sichtbare Aktion, wie sie z. B. beim Kameralicht existiert.
3. **Kopplung mit Input** — wer lesen *und* Eingaben injizieren kann, hat vollständige Fernsteuerung (klassischer X11-Fall: `XGetImage` + `XTEST` + `XQueryKeymap` = Keylogger + RAT ohne Exploit, allein durch Design).
4. **Sandbox-Bruch** — eine Browser-Erweiterung oder Flatpak-App könnte trivial aus ihrem Container ausbrechen, indem sie fremde Fenster liest.
5. **Umgehung von Verschlüsselung** — nach der Entschlüsselung ist alles wieder Pixel.

### Lösungen der drei Plattformen

**Windows — historisch schwach, wird nachgebessert**
- `BitBlt`/DXGI benötigen bis heute **keine explizite Nutzerzustimmung** für klassische Desktop-Apps. Die Grenze ist die **Session-Isolation** (Session 0 vs. interaktive Session) und **UIPI/Mandatory Integrity Control**: ein Prozess niedriger Integrität kann Fenster höherer Integrität nicht manipulieren; der „secure desktop" (UAC-Prompt, Anmeldebildschirm, Ctrl+Alt+Entf) läuft auf einem eigenen Desktop-Objekt und ist nicht erfassbar.
- **Opt-out der Zielanwendung**: `SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE)` → das Fenster erscheint in fremden Aufnahmen gar nicht (bzw. `WDA_MONITOR` schwarz). Nutzen u. a. DRM-Player und Passwortmanager. Zusätzlich blockiert die GPU bei **Hardware-Content-Protection (PlayReady/HDCP)** den Auslesepfad.
- **UWP/AppContainer** brauchen die entsprechende Capability; `Windows.Graphics.Capture` erzwingt den Picker und zeigt den **gelben Rahmen** als Indikator — genau das, was `BitBlt` fehlt.
- Der Recall-Streit hat gezeigt, wie brisant systemweite Dauer-Screenshots sind: Ergebnis waren Opt-in, VBS-Enclave-Verschlüsselung und Windows-Hello-Bindung.

**macOS — striktes Consent-Modell (TCC)**
- Berechtigung **„Bildschirm- & Systemaudioaufnahme"**, pro App, mit systemmodalem Prompt beim ersten Zugriff; ohne sie liefern die APIs nur Desktop-Hintergrund und Menüleiste statt Fensterinhalten.
- Die Zustimmung ist an **Bundle-ID + Code-Signatur (Designated Requirement)** gebunden — ein nacktes ausführbares Binary ohne `.app`-Bundle erscheint auf aktuellen Versionen gar nicht erst in den Systemeinstellungen. Wird die App neu signiert oder verändert, verfällt das Recht.
- **Sichtbarer Indikator** in der Menüleiste während laufender Aufnahme, plus wiederkehrende Erinnerungen bei dauerhafter Nutzung; `SCContentSharingPicker` als systemeigene, nicht fälschbare Auswahl. Die TCC-Datenbank selbst ist SIP-geschützt.

**Wayland — Sicherheit durch Protokolldesign**
- Ein Client sieht **nur seine eigenen Surfaces**. Es existiert kein Kernprotokoll zum Lesen fremder Pixel oder zum globalen Input-Grab — das Problem wird nicht durch Rechteprüfung gelöst, sondern durch Abwesenheit des Primitivs.
- Der Compositor ist der Policy-Entscheider. Zugriff läuft über das **Portal** mit Nutzerauswahl im Compositor-eigenen Dialog; die App bekommt einen PipeWire-Stream und sieht nur, was der Nutzer freigegeben hat. Ein `restore_token` erlaubt begrenztes Wiederverwenden ohne erneutes Nachfragen.
- Für Werkzeuge, die den Dialog nicht wollen (Screenshot-Tools, Remote-Desktop), gibt es die **privilegierten Protokolle** `ext-image-copy-capture-v1`; deren Freigabe erfolgt über eine Compositor-Allowlist bzw. `wl_security_context`, das sandboxed Clients markiert.
- Praktischer Preis: der bekannte Ärger mit Portal-Backends, fehlender Fenster-Einzelaufnahme in manchen Compositors und der Notwendigkeit, jedes Tool an mehrere Backends anzupassen.

### Für ein *eigenes* Tool folgt daraus
- Nie einen „Bildschirm-Lese-Syscall" als eigene privilegierte Komponente bauen (kein Kernel-Treiber, kein setuid-Helper) — immer über den Plattform-Berechtigungspfad gehen; das Tool wäre sonst selbst der universelle Bypass.
- Das Tool wird zum lohnenden Ziel: Screenshots enthalten Geheimnisse. Also: keine automatische Cloud-Synchronisation ohne Opt-in, Verlauf lokal und begrenzt, klare Anzeige laufender Aufnahmen, keine stillen Hintergrundaufnahmen.
- **Metadaten**: EXIF/XMP nach Möglichkeit gar nicht erst schreiben (keine Geräte-/Nutzernamen, keine Pfade, keine Zeitzonen-Leaks).

---

## (d) Was ein einfacher Editor können muss

**Pflicht (in dieser Reihenfolge der Nutzungshäufigkeit):**
1. **Zuschneiden** mit Anfassern, Seitenverhältnis-Lock, ganzzahlige Pixelkoordinaten.
2. **Rechteck / Ellipse** (Rahmen oder gefüllt), **Linie**, **Pfeil** — Pfeil braucht eine korrekt konstruierte Spitze: Schaftrichtung normieren, zwei Punkte im Winkel ±20–30° zur Schaftachse, Spitzenlänge proportional zur Strichstärke (typ. 4–6×); Shift = 45°-Rasterung.
3. **Freihand-Stift**, geglättet über Catmull-Rom-/quadratische Bézier-Interpolation der Zeigerpunkte, sonst sieht es kantig aus.
4. **Text**: Textbox mit Caret, Schriftgröße, Farbe, Hintergrundplatte oder Kontur für Lesbarkeit auf beliebigem Untergrund.
5. **Marker/Highlighter**: halbtransparente Füllung, Multiply-Blend.
6. **Verpixeln / Weichzeichnen** für Redaktion.
7. **Nummerierte Schritt-Marken** (①②③) — für Anleitungen extrem verbreitet.
8. **Undo/Redo** (Command-Stack), **Objektmodell statt Pixel-Malen**: Annotationen als verschieb-/löschbare Objekte, erst beim Export rasterisieren. Deutlich bessere UX und Voraussetzung für nachträgliches Ändern.
9. **Kopieren in Zwischenablage**, Speichern, Drag-out.
10. Nice-to-have: Rahmen/Schlagschatten, abgerundete Ecken, Hintergrund-Padding mit Farbverlauf (heutiger „Social-Media-Look").

**Wichtig zur Verpixelung — Sicherheitsdetail:**
- **Mosaik ist nicht zwingend sicher.** Bei kleinen Blockgrößen und bekanntem Schriftsatz ist Text rekonstruierbar (Depixelierung durch Ausprobieren aller Kandidaten-Renderings und Vergleich der Blockmittelwerte — vgl. das `Unredacter`-Ergebnis gegen `pixelation`). Für echte Redaktion: **volldeckende Fläche in Volltonfarbe** (Schwarzbalken), Blockgröße sonst mindestens ~1/4 der Zeichenhöhe.
- **Gauß-Blur ist noch schlechter** als Mosaik (Tiefpass, teilweise invertierbar).
- Die Redaktion muss auf den **Ausgabepixeln** stattfinden, nicht nur als Overlay-Objekt in einer Projektdatei — sonst enthält die exportierte Datei bei Formaten mit Ebenen den Klartext.
- **„Acropalypse"-Falle (CVE-2023-21036 / CVE-2023-28303):** Wird beim Zuschneiden eine bestehende Datei zum Überschreiben geöffnet, aber **nicht auf Länge 0 gekürzt**, bleiben die Reste des größeren Originalbildes hinter dem neuen `IEND` stehen und sind rekonstruierbar. Regel: **immer neu erstellen bzw. `O_TRUNC`**, oder in temporäre Datei schreiben und atomar umbenennen.

---

## (e) Bildformate und Aufwand eines eigenen PNG-Kodierers

### Formatwahl
| Format | Rolle |
|---|---|
| **PNG** | Standard-Default. Verlustfrei, Alpha, ideal für UI-Screenshots mit großen Flächen und scharfen Kanten. |
| **JPEG** | nur für foto-/videolastige Inhalte oder Größenlimits; kein Alpha, sichtbare Ringing-Artefakte an Textkanten → für UI ungeeignet. |
| **WebP** | lossless meist ~20–30 % kleiner als PNG, lossy mit Alpha; breit unterstützt. |
| **AVIF / HEIC** | beste Kompression, teures Encoding, Patent-/Support-Fragen; HEIC ist auf macOS/iOS nativ. |
| **BMP/TIFF** | nur als Interoperabilitäts-/Zwischenablageformat. |
| **GIF / APNG / WebP-animiert** | kurze Bildschirm-Loops. |
| **MP4 (H.264/HEVC) bzw. WebM (VP9/AV1)** | Bildschirmvideo; für Screencasts sinnvoll: Hardware-Encoder (Media Foundation / VideoToolbox / VAAPI), hohe Keyframe-Dichte, `tune=stillimage`-artige Einstellungen bzw. 4:4:4-Chroma, weil 4:2:0 farbigen Text ausfranst. |
| **PDF/SVG** | Anhängen von Annotationen als Vektor, Dokumentation. |
| **Zwischenablage** | Windows `CF_DIBV5` + registriertes `"PNG"`-Format (DIB verliert sonst Alpha); macOS `NSPasteboard` mit `public.png`/`public.tiff`; Wayland `wl_data_source` MIME `image/png`. |

### Eigener PNG-Kodierer — Aufwandsvergleich

**Gemeinsamer Rumpf (in beiden Fällen nötig, ~150–250 Zeilen):**
- 8-Byte Signatur `89 50 4E 47 0D 0A 1A 0A`
- Chunk-Framing: Länge (BE u32), Typ, Daten, **CRC-32** (IEEE, Polynom `0xEDB88320`, über Typ+Daten) — Tabellenberechnung ~15 Zeilen
- `IHDR` (Breite, Höhe, Bittiefe 8, Farbtyp 2=RGB / 6=RGBA, Kompression 0, Filter 0, Interlace 0), optional `pHYs` für DPI, dann `IDAT`, `IEND`
- Scanline-Aufbereitung: **pro Zeile ein führendes Filterbyte**

**Variante A — „unkomprimiertes PNG" (nur Stored/Uncompressed-Deflate-Blöcke):**
- zlib-Rahmen: 2 Byte Header (`78 01`) + 4 Byte **Adler-32** am Ende (~10 Zeilen)
- Deflate-Stored-Block: 5 Byte Header pro Block — 1 Byte `0x00`/`0x01` (BFINAL), dann `LEN` als Little-Endian u16 (max. **65535**), dann `~LEN`; danach die Rohbytes 1:1
- Filter-Typ 0 (None) für jede Zeile
- **Aufwand: ~100–150 Zeilen, keine Bitmanipulation, keine Huffman-Tabellen, in wenigen Stunden korrekt und komplett testbar.** Kein LZ77-Fenster, kein Bit-Writer nötig, weil Stored-Blöcke byte-aligned sind.
- **Overhead: verschwindend gering, ~0,0076 %** (5 Byte je 64 KiB) plus 1 Byte pro Zeile plus 6 Byte zlib-Rahmen.
- **Aber: die Datei ist praktisch die Rohgröße.** Beispiel 1920×1080 RGBA: 1920·4+1 = 7681 B/Zeile × 1080 ≈ **8,3 MB**. Ein echter PNG-Kodierer liefert für denselben UI-Screenshot typischerweise **200–600 KB**, also **Faktor 15–40**. Für Screenshots ist das besonders drastisch, weil UI-Flächen extrem redundant sind.
- Praktisch brauchbar als: Zwischenablage-/IPC-Transport, Debug-Dump, Notfall-Fallback, Bootstrapping in Umgebungen ohne zlib.

**Variante B — echter Deflate:**
- **Stufe 1, nur Fixed-Huffman + LZ77:** Bit-Writer (LSB-first!), Hash-Tabelle über 3-Byte-Präfixe, Hash-Chain-Match-Suche mit begrenzter Kettenlänge, feste Code-Tabellen aus RFC 1951 (Literale 0–287, Längen 3–258, 30 Distanzcodes bis 32768). **~400–700 Zeilen**, liefert grob 60–75 % der zlib-Level-6-Kompression.
- **Stufe 2, Dynamic Huffman:** Häufigkeiten zählen, Huffman-Baum bauen mit **Längenbegrenzung auf 15 Bit** (Package-Merge oder heuristisches Nachjustieren), kanonische Codes, dann die Code-Längen selbst per Code-Length-Alphabet (Symbole 16/17/18 für Runs) codieren, Blockgrenzen heuristisch setzen. **+400–800 Zeilen** und der klassische Ort für subtile Bugs.
- **Stufe 3, PNG-Filter (der eigentliche Hebel):** Filtertypen 1–4 (Sub, Up, Average, Paeth). Adaptive Wahl pro Zeile nach der Standardheuristik „minimiere die Summe der absoluten Werte der gefilterten Bytes (als signed interpretiert)". Bringt bei Screenshots oft mehr als die Feinabstimmung des Deflate-Teils. **~100 Zeilen**, sehr gutes Aufwand/Nutzen-Verhältnis.
- **Gesamt: ~1200–2000 Zeilen, realistisch 1–3 Wochen** inklusive Fuzzing gegen einen Referenz-Decoder und Vergleich mit `pngcheck`/libpng.

**Empfehlung:** Referenz-Deflate nicht selbst schreiben, sondern **miniz** (Single-File, ~3000 LOC, Public Domain/MIT) oder zlib/zlib-ng/libdeflate einbinden — das sind ~10 Zeilen Integrationscode für die volle Kompression. Der eigene Stored-Block-Encoder ist dennoch wertvoll als abhängigkeitsfreier Pfad und als Lernstück.

**Zwei Screenshot-spezifische Zusatzoptimierungen:**
- **Palettierung (Farbtyp 3, `PLTE`)**: reine UI-Screenshots haben oft < 256 Farben → 8 statt 32 Bit pro Pixel *vor* Deflate, typisch nochmals Faktor 2–4. Farbzählung via Hash-Set, Fallback auf Truecolor bei Überschreitung. Genau das macht `pngquant`.
- **Alpha weglassen**, wenn alle Pixel opak sind (Farbtyp 2 statt 6 → 25 % weniger Rohdaten). Bei Vollbildaufnahmen fast immer der Fall.

---

## Kompakte Zusammenfassung

- **(a)** Erwartet werden heute: Vollbild, Einzelfenster, Rechteck, Freiform, UI-Element-Snap, verzögerte Aufnahme, Bildlauf-Aufnahme und Bildschirmvideo — plus Zwischenablage-Sofortkopie, OCR und Aufnahmeverlauf. Scroll-Capture ist der aufwendigste Modus (Stitching per Phasenkorrelation oder semantisch via Accessibility-API) und braucht zusätzlich Input-Injection.
- **(b)** Der Compositor (DWM / WindowServer / Wayland-Compositor) besitzt als Einziger das Gesamtbild; Zugriff über DXGI Desktop Duplication bzw. `Windows.Graphics.Capture`, ScreenCaptureKit, oder Portal/PipeWire bzw. `ext-image-copy-capture-v1`. Die Auswahl läuft über ein transparentes, always-on-top Overlay mit Pointer-Grab; entscheidend ist das **Freeze-Frame-Muster** — erst aufnehmen, dann das Standbild im Overlay anzeigen und nur zuschneiden.
- **(c)** Ein universeller Screen-Read-Primitiv aggregiert die gesamte Vertraulichkeit des Systems und umgeht jede Datei-/Prozessisolation; kombiniert mit Input-Injection ist er ein vollständiges RAT. Windows löst es historisch nur über Session/Integrity-Isolation plus App-seitiges Opt-out (`WDA_EXCLUDEFROMCAPTURE`) und den Picker mit gelbem Rahmen; macOS über TCC-Consent gebunden an Bundle-ID und Signatur plus Menüleisten-Indikator; Wayland durch Wegfall des Primitivs — Zugriff nur über Portal mit Compositor-eigenem Auswahldialog oder explizit privilegierte Protokolle.
- **(d)** Zuschneiden, Rechteck/Ellipse/Linie/Pfeil, Freihand, Text mit Kontur, Highlighter, nummerierte Marken, Verpixeln, Undo/Redo auf einem Objektmodell. Sicherheitskritisch: Mosaik und Blur sind teilweise umkehrbar (Volltonbalken verwenden), Redaktion muss die Ausgabepixel treffen, und die Datei muss beim Speichern **getrunkiert** werden (Acropalypse).
- **(e)** PNG als Default, WebP/AVIF als kleinere Alternativen, JPEG nur für Fotos, MP4/WebM für Video. Ein PNG-Encoder mit **Stored-Deflate-Blöcken** ist mit ~100–150 Zeilen an einem Tag machbar und hat nur ~0,008 % Formatoverhead — erzeugt aber Dateien in Rohgröße, bei 1080p RGBA rund 8,3 MB statt 200–600 KB, also Faktor 15–40. Echter Deflate mit dynamischen Huffman-Tabellen und adaptiven PNG-Filtern kostet ~1200–2000 Zeilen und ein bis drei Wochen; pragmatisch bindet man miniz/zlib ein und investiert die Eigenleistung stattdessen in **adaptive Filter und Palettierung**, wo bei Screenshots der größte Gewinn liegt.

**Sources:**
- [XDG Desktop Portal – ArchWiki](https://wiki.archlinux.org/title/XDG_Desktop_Portal)
- [Image Copy Capture protocol – Wayland Explorer](https://wayland.app/protocols/ext-image-copy-capture-v1)
- [Wayland Merges New Screen Capture Protocols – Phoronix](https://www.phoronix.com/news/Wayland-Merges-Screen-Capture)
- [Making a Wayland Screen Capturing Protocol – Andri Yngvason](https://andri.yngvason.is/making-a-wayland-screen-capturing-protocol.html)
- [ScreenCaptureKit – Axiom](https://charleswiltgen.github.io/Axiom/skills/macos/screencapturekit)
- [macOS Input Monitoring, Screen Capture & Accessibility – HackTricks](https://hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-input-monitoring-screen-capture-accessibility.html)
- [Question about deprecated CGDisplayCreateImage() – Apple Developer Forums](https://developer.apple.com/forums/thread/748798)
- [Removing the Yellow Border Capture Indicator – Microsoft Learn Q&A](https://learn.microsoft.com/en-us/answers/questions/108678/how-to-remove-yellow-boarder-capture-indicator-fro)
- [Ways to capture the screen – Microsoft Learn](https://learn.microsoft.com/nl-nl/archive/blogs/dsui_team/ways-to-capture-the-screen)
- [DirectX Graphics Infrastructure – Wikipedia](https://en.wikipedia.org/wiki/DirectX_Graphics_Infrastructure)
- [Producing Uncompressed PNG Files – Nigel Tao](https://nigeltao.github.io/blog/2025/uncompressed-png.html)
- [A minimal encoder for uncompressed PNGs – main is usually a function](http://mainisusuallyafunction.blogspot.com/2012/04/minimal-encoder-for-uncompressed-pngs.html)
- [PNG Specification: Deflate/Inflate Compression](http://www.libpng.org/pub/png/spec/1.2/PNG-Compression.html)
- [Compression and Filtering – PNG: The Definitive Guide](http://www.libpng.org/pub/png/book/chapter09.html)
- [RFC 1950 – ZLIB Compressed Data Format](https://datatracker.ietf.org/doc/html/rfc1950)
- [Making an uncompressed PNG image file – Entropymine](https://entropymine.wordpress.com/2023/11/28/making-an-uncompressed-png-image-file/)

---

### Teilaufgabe 5: Recherchiere, was ein BILDBETRACHTER und ein MEDIENPLAYER an Dateiformaten koennen muessen, damit ein Nutzer nicht auf ein anderes Programm ausweichen muss. Beantworte konkret: (a) Welche Bildformate sind heute wirklich noetig - PNG, JPEG, GIF (auch animiert), BMP, WebP, HEIC, SVG, TIFF? Sortiere nach Haeufigkeit im Alltag und schaetze den Dekodier-Aufwand fuer eine EIGENE Umsetzung ohne fremde Bibliotheken, mit ungefaehren Codegroessen. (b) Wie funktioniert ein JPEG-Dekodierer im Grundsatz und wie viel Arbeit ist eine eigene Umsetzung ehrlich? (c) Was erwartet man von einem Bildbetrachter an Bedienung (Zoom, Drehen, Diashow, Miniaturansichten, naechstes Bild im Ordner, EXIF-Drehung)? (d) Was macht VLC besonders, also was erwartet Justin wohl mit 'kann was VLC kann' - und welcher Teil davon ist fuer ein selbstgebautes OS realistisch, welcher nicht? Sei ehrlich und trenne klar zwischen machbar und unrealistisch. Antworte auf Deutsch.
# Recherche: Formatunterstützung für Bildbetrachter & Medienplayer

*(Annahme: Eigenes OS, C/C++/Rust-artig, keine fremden Bibliotheken, ein bis zwei Entwickler. Alle LOC-Angaben = eigener, lesbarer Code ohne SIMD-Optimierung; Aufwand = erfahrener Systemprogrammierer.)*

---

## (a) Bildformate – Priorität und ehrlicher Eigenbau-Aufwand

### Häufigkeit im Alltag (lokale Dateien auf einem Desktop, nicht Web-Traffic)

| # | Format | Woher es kommt | Ohne Support passiert… |
|---|---|---|---|
| 1 | **JPEG** | Kameras, Handys, Downloads, ~70 % aller Websites | Betrachter ist wertlos |
| 2 | **PNG** | Screenshots, UI-Assets, Logos, Transparenz | Betrachter ist wertlos |
| 3 | **GIF (animiert)** | Memes, Chats, alte Web-Assets | Nutzer weicht aus |
| 4 | **WebP** | Alles was aus Chrome/Firefox „Bild speichern" kommt; ~20 % der Websites | Sehr sichtbare Lücke, häufigste Beschwerde bei jungen Viewern |
| 5 | **HEIC/HEIF** | iPhone-Fotos ab iOS 11 (Default!) | Jeder Apple-Nutzer ist raus |
| 6 | **BMP** | Windows-Altlasten, eigene Screenshots, Testbilder | Selten – aber so billig, dass Weglassen dumm wäre |
| 7 | **SVG** | Logos, Icons, Design-/Dev-Dateien | Ärgerlich, aber „Ausweichen" wird akzeptiert |
| 8 | **TIFF** | Scanner, Fax, Druckvorstufe, Multipage-Dokumente | Nischig, Zielgruppe klein aber laut |
| 9 | *(AVIF)* | Wächst schnell, wird WebP mittelfristig ablösen | Heute noch verzeihbar |
| 10 | *(ICO, PPM/PGM, RAW: CR2/NEF/ARW)* | ICO trivial mitnehmen; RAW = eigenes Projekt | RAW klar aus dem Scope streichen |

### Dekodier-Aufwand bei Eigenbau

| Format | Kerntechnik | LOC (eigen) | Aufwand | Bewertung |
|---|---|---|---|---|
| **BMP** | Header + Zeilen kopieren; 1/4/8/24/32 bit, RLE4/8, BITFIELDS, bottom-up | 250–500 | 1–2 Tage | **Sofort machen.** Bester Aufwand/Nutzen im ganzen Projekt |
| **PPM/PGM/TGA** | Trivial | 100–300 | 0,5–1 Tag | Nett für eigene Tools/Debug |
| **GIF** | LZW-Dekoder, Paletten, Interlace, Animation mit Disposal-Modi + Transparenz | 600–900 | 3–6 Tage | **Machen.** LZW ist die einzige echte Hürde und die ist klein |
| **PNG** | Eigener **Inflate** (Deflate/zlib) + 5 Zeilenfilter + Adam7-Interlace + Bittiefen 1/2/4/8/16 + Palette + tRNS + CRC | 1200–1800 (davon 400–700 nur Inflate) | 1–2 Wochen | **Muss.** Inflate lohnt sich doppelt: brauchst du später für ZIP, WebP-Lossless, TIFF-Deflate |
| **JPEG (Baseline)** | siehe (b) | 1500–2000 | 1–2 Wochen | **Muss** |
| **JPEG (+ Progressive, CMYK, Restart-Recovery)** | siehe (b) | +600–900 | +2–3 Wochen | Progressive ist im Web-Download-Alltag häufig – nicht optional |
| **TIFF** | Container leicht (IFD, beide Endianness), Codec-Zoo schwer: PackBits, LZW, Deflate, CCITT G3/G4, JPEG-in-TIFF, Tiles vs. Strips, Planar, WhiteIsZero, CMYK, YCbCr | 800–1500 (Minimalset) / 3000+ (real) | 1 Woche / 4+ Wochen | Nur Minimalset (unkompr. + PackBits + LZW + Deflate). CCITT G4 nur wenn Scanner-Nutzer Zielgruppe sind |
| **WebP** | Zwei komplett getrennte Codecs: **VP8** (lossy: Bool-Arithmetikdekoder, Intra-Prädiktion, 4×4-DCT/WHT, Loop-Filter) **+ VP8L** (lossless: Huffman, Color-Cache, Backward-Refs, 4 Transforms) + Alpha-Chunk + RIFF-Container + ANMF-Animation | 2500–4000 (VP8) + 1500–2500 (VP8L) + ~800 (Rest) ≈ **6000–8000** | **6–10 Wochen** | Der ehrliche Schmerzpunkt. Pragmatik: **erst nur VP8L + Alpha** (viele gespeicherte Web-Bilder sind lossless), lossy nachziehen |
| **HEIC/HEIF** | ISOBMFF-Container mit Item-Properties + **kompletter HEVC-Intra-Dekoder**: CABAC, CTU-Quadtree, 35 Intra-Modi, Transformationen 4–32, Deblocking, SAO, 10 bit; iPhone speichert oft ein **Kachel-Grid** aus vielen Einzelbildern | 15.000–30.000 | **4–8 Monate** | **Unrealistisch als Eigenbau.** Trick: HEIC-Dateien enthalten meist ein eingebettetes JPEG-Preview – ISOBMFF parsen und das Preview anzeigen kostet ~300 LOC und deckt „ich will das Foto sehen" zu 90 % ab. Ehrlich kennzeichnen („Vorschau") |
| **SVG** | Kein Dekoder, ein **Renderer**: XML-Parser, Pfad-Grammatik, Bezier-Flattening, Scanline-Fill (nonzero/evenodd), Anti-Aliasing, Stroking mit Joins/Caps/Dashes, Transforms, Gradients, Clip/Mask, **CSS**, **Text = braucht kompletten Font-Renderer** | 3000–5000 für brauchbares Subset (Referenz: NanoSVG ≈ 3000 Parser + 1400 Rasterizer, ohne Text/CSS) | 4–8 Wochen fürs Subset | Subset schafft ~70–80 % aller Icons/Logos. Voller SVG = Browser-Klasse, nie „fertig" |
| **AVIF** | AV1-Intra-Dekoder | 30.000+ | Personenjahre | **Klar streichen** |

**Empfohlene Ausbaustufen:**
1. **Stufe 1 (≈ 4–6 Wochen):** BMP, PNG (+ eigener Inflate), JPEG Baseline, GIF animiert, ICO. → deckt gefühlt 85 % aller Doppelklicks.
2. **Stufe 2 (≈ 4–6 Wochen):** JPEG Progressive + EXIF, TIFF-Minimalset, HEIC-Preview-Fallback.
3. **Stufe 3 (≈ 8–12 Wochen):** WebP komplett, SVG-Subset.
4. **Nie:** AVIF, JPEG2000, RAW, JPEG-XL, volles HEVC.

---

## (b) Wie ein JPEG-Dekoder funktioniert – und was er wirklich kostet

### Ablauf Baseline-JPEG

1. **Marker-Parser.** Datei ist eine Kette von `0xFF xx`-Markern: `SOI`, `APPn` (JFIF/EXIF), `DQT` (Quantisierungstabellen), `SOF0` (Bildgröße, Komponenten, Subsampling-Faktoren), `DHT` (Huffman-Tabellen), `DRI` (Restart-Intervall), `SOS` (Beginn der Bilddaten), `EOI`.
2. **Huffman-Tabellen aufbauen** aus Codelängen-Zählern (kanonischer Huffman). Praktisch: Fast-Lookup-Tabelle mit 9 Bit Index, Rest als Slow-Path.
3. **Bitstream lesen** mit *Byte-Stuffing*: ein `0xFF` in den Daten steht als `0xFF 0x00` – muss beim Nachfüllen entfernt werden. Klassische Fehlerquelle Nr. 1.
4. **Pro MCU** (Minimum Coded Unit, z. B. 16×16 Pixel bei 4:2:0) und pro Block 8×8:
   - **DC-Koeffizient** differenziell zum Vorgänger-Block derselben Komponente.
   - **AC-Koeffizienten** als (Runlength-of-Zeros, Size)-Paare, in **Zickzack-Reihenfolge**, bis EOB.
5. **Dequantisieren:** Koeffizient × Wert aus der Quantisierungstabelle.
6. **Inverse DCT 8×8.** Separabel: 8 Zeilen-IDCTs + 8 Spalten-IDCTs. Fixpunkt-AAN/Loeffler-Variante, ~150 LOC. Naiv-mathematisch geht auch, ist aber ~20× langsamer.
7. **Level-Shift** (+128) und Clamping auf 0…255.
8. **Chroma-Upsampling** 4:2:0 / 4:2:2 / 4:4:4 (erst Nearest, später bilinear).
9. **YCbCr → RGB** (Fixpunkt-Matrix).
10. **Restart-Marker** `RSTn`: Bitstream byte-alignen, DC-Prädiktoren zurücksetzen – erlaubt Resync bei kaputten Dateien.

### Was den Aufwand wirklich treibt (nicht der Kern, die Realität)

- **Progressive JPEG:** Mehrere Scans über dasselbe Bild, mit *Spectral Selection* (Koeffizientenbereich) und *Successive Approximation* (Bitebenen), plus EOB-Run-Logik. Das ist praktisch ein zweiter, komplizierterer Dekoderpfad und braucht einen Vollbild-Koeffizientenpuffer (Speicher!). Sehr verbreitet bei Web-Bildern.
- **Adobe/CMYK-JPEGs:** APP14-Marker, 4 Komponenten, YCCK, teilweise **invertierte** Werte (Photoshop). Sieht sonst aus wie ein Farbnegativ.
- **EXIF-Orientation:** Foto steht sonst quer. Gehört zwingend zum Baseline-Feature.
- **Defekte/abgeschnittene Dateien:** Der Nutzer erwartet die halbe angezeigte Bildhälfte, keinen Fehlerdialog. Robustheit = viel Code.
- **Selten/streichbar:** Arithmetisch codiertes JPEG, 12-bit, hierarchisches JPEG, Lossless-JPEG.
- **Sicherheit:** Untrusted Input. Jeder Index, jede Größenangabe, jede Tabelle muss geprüft werden – sonst hast du einen Heap-Overflow im Kernel-nahen Code.

### Ehrliche Zahlen

| Meilenstein | Aufwand | LOC |
|---|---|---|
| Erstes korrekt dekodiertes 4:4:4-Baseline-Testbild | 2–4 Tage | ~800 |
| Alle Subsamplings, Restart, EXIF-Rotation, sauberes Clamping | +1 Woche | ~1500 |
| Progressive + CMYK + Fehlertoleranz + Fuzzing-fest | +2–4 Wochen | ~2200–2800 |
| Performance (SIMD-IDCT, Multithreading, Downscale-beim-Dekodieren für Thumbnails) | +2–3 Wochen | +500 |

**Referenzpunkt:** `stb_image.h` – der bekannteste minimalistische Dekoder – braucht für JPEG ca. **2.500 Zeilen** (Zeilen 1585–4081); die Ur-Version vor 10 Jahren waren ~1.250 Zeilen. Das ist die realistische Bandbreite: **1.300 Zeilen für „geht meistens", 2.500 für „geht immer".**

**Fazit:** JPEG ist der einzige komplexe Bilddekoder, der sich als Eigenbau wirklich lohnt – gut dokumentiert (ITU T.81), verifizierbar (Referenzbilder), endlich, und du bekommst als Bonus **MJPEG-Video** fast geschenkt (siehe d).

---

## (c) Bedienungserwartungen an einen Bildbetrachter

### Muss (sonst wird sofort ausgewichen)

- **Start unter ~200 ms**, auch beim Doppelklick in einem Ordner mit 5.000 Bildern (Ordner **asynchron** scannen, nicht blockierend).
- **Weiter/Zurück im Ordner** mit Pfeiltasten/Leertaste/Mausrad, in derselben Sortierung wie der Dateimanager, mit **natürlicher Sortierung** (`img2.jpg` vor `img10.jpg`). Nächstes und voriges Bild im Hintergrund **vorladen** → Blättern fühlt sich instant an.
- **Fit-to-Window ⇄ 100 % (1:1)** per Klick/Taste, Zoom per Mausrad **auf den Cursor zentriert**, Pan per Ziehen.
- **EXIF-Auto-Rotation** beim Laden (nicht optional).
- **Drehen 90° links/rechts + Spiegeln**, Rotation für die Session gemerkt.
- **Vollbild** (F11/Enter/Doppelklick), ohne UI-Rest.
- **Sinnvolle Skalierung:** beim Verkleinern bilinear/Mitchell (nicht Nearest → Moiré), beim Vergrößern über ~200 % Nearest anbieten (Pixelart/Screenshots).
- **Alpha korrekt**: Schachbrett oder wählbare Hintergrundfarbe.
- **Animiertes GIF/WebP** mit korrektem Timing, Pause/Einzelbild.
- **Große Bilder** (100 MP, Panoramen) ohne Absturz – Speicherbudget + progressives Anzeigen.
- **Drag & Drop** rein, Dateizuordnung, Fenstergeometrie merken.

### Stark erwartet

- **Miniaturansichten** als Filmstreifen oder Rasteransicht, mit **persistentem Thumbnail-Cache** (sonst unbrauchbar) und Erzeugung im Hintergrund-Thread. Bei JPEG: EXIF-Thumbnail nutzen bzw. DCT-Scaled-Decode (1/2, 1/4, 1/8) – 8× schneller.
- **Diashow**: Intervall einstellbar, Schleife, zufällig, Pause per Klick, Übergang optional.
- **Info-Panel**: Maße, Dateigröße, Format/Bittiefe, EXIF (Kamera, Objektiv, Blende/Zeit/ISO, Aufnahmedatum), ggf. GPS.
- **Kopieren in die Zwischenablage**, **Löschen** (in Papierkorb, mit Undo), Umbenennen, „Im Ordner zeigen".
- **Komplette Tastaturbedienung** – Bildbetrachter werden mit der Tastatur benutzt.

### Nice-to-have / Grenze zum Bildeditor

Zuschneiden, Größe ändern, Speichern-unter/Format-Konvertierung, Helligkeit/Kontrast, Stapelumbenennung, Vergleichsansicht, Multipage-TIFF-Navigation, Farbmanagement (ICC-Profile – sonst sehen iPhone-P3-Fotos flau aus), Sortierung nach Datum/Größe, einfache Ordnernavigation.

---

## (d) „Kann was VLC kann" – was Justin wohl meint, und was davon geht

### Was VLC objektiv besonders macht

1. **Spielt praktisch alles ohne Konfiguration.** Bringt alle Codecs selbst mit (libavcodec/FFmpeg + eigene Demuxer) – kein Codec-Pack, keine Systemabhängigkeit. Das ist *der* Ruf.
2. **Extrem robust:** abgeschnittene Downloads, kaputte Header, falsche Dateiendungen, Dateien die noch heruntergeladen werden – VLC spielt trotzdem.
3. **Container- und Codec-Breite:** MP4/MKV/AVI/TS/FLV/WebM/OGG × H.264/H.265/AV1/VP9/MPEG-2/MJPEG × AAC/MP3/AC3/DTS/FLAC/Opus/Vorbis.
4. **Netzwerk:** HTTP, HLS, DASH, RTSP, UDP-Multicast, SMB/FTP-Shares, YouTube-URLs.
5. **Optische Medien:** DVD/Blu-ray, ISO-Images, Menüs.
6. **Untertitel:** SRT/SUB/ASS mit Styling, Verzögerung live justierbar, Auto-Fund der `.srt` neben der Videodatei.
7. **Spuren & Audio:** Mehrere Audio-/Untertitelspuren, Audio-Delay, Equalizer, Normalisierung, Kanal-Downmix.
8. **Wiedergabe-Extras:** Geschwindigkeit, Frame-by-Frame, Snapshot, Resume-Position, Playlists, Deinterlacing, Video-Filter, Transcoding/Streaming-Server, Bildschirmaufnahme, Casting.
9. **Hardware-Dekodierung** (DXVA/VA-API/VideoToolbox) → 4K auf schwacher Hardware.

### Was Justin wahrscheinlich tatsächlich meint

Nicht die Streaming-Server-Features. „Kann was VLC kann" heißt in 95 % der Fälle:

> *„Ich doppelklicke irgendeine Video- oder Musikdatei und sie läuft einfach – mit Bild und Ton synchron, Fortschrittsleiste, Spulen, Lautstärke, Vollbild, Pause mit Leertaste. Ohne dass ich was installieren oder einstellen muss."*

Das ist eine **UX-Erwartung**, keine Codec-Liste. Und dieser Teil ist erreichbar – wenn man den Dateibestand klein hält.

### Realistisch machbar (eigenes OS, eigener Code)

| Baustein | Aufwand | Anmerkung |
|---|---|---|
| **Audiotreiber (Intel HDA)**: Codec-Verbs, Widget-Graph, BDL-DMA, Ringpuffer, Interrupts | 2.000–4.000 LOC, **3–6 Wochen** | **Der eigentliche Blocker.** Ohne den ist alles andere sinnlos. Zuerst machen |
| **WAV/PCM + AIFF + ADPCM** | 200–400 LOC, 2 Tage | Erster hörbarer Ton |
| **FLAC-Dekoder** | 1.000–1.500 LOC, 1–2 Wochen | **Bester Einstieg in Codecs:** Rice-Coding + LPC, lossless ⇒ bitgenau gegen Referenz prüfbar (MD5 steht im Header) |
| **MP3-Dekoder** | 2.000–3.000 LOC, **3–5 Wochen** | Huffman, Bit-Reservoir, Alias-Reduction, IMDCT, Polyphase-Synthese. Fummelig, aber endlich und gut dokumentiert |
| **Ogg Vorbis** | 4.000–5.500 LOC, 6–8 Wochen | Codebooks, Floor1, Residue, MDCT. Referenz `stb_vorbis` ≈ 5.500 LOC |
| **AAC-LC** | 4.000–6.000 LOC, 6–10 Wochen | Nötig für praktisch jedes MP4 |
| **MJPEG in AVI/MOV** | 300 LOC **auf den JPEG-Dekoder obendrauf** | **Der Geheimtipp:** du hast in 2 Tagen echtes, abspielbares Video |
| **Demuxer AVI/RIFF** | 500–800 LOC, 1 Woche | Einfachster Container |
| **Demuxer MP4/ISOBMFF** | 1.000–2.000 LOC, 2 Wochen | Sample-Tables, Chunk-Offsets, Seek-Index; Bonus: teilt sich Code mit HEIC |
| **Demuxer MKV/EBML** | 1.000–1.500 LOC, 2 Wochen | |
| **A/V-Sync-Engine**: Audio als Masterclock, PTS-Vergleich, Frame-Dropping, Puffer-Threads | 500–1.000 LOC, 2 Wochen | Konzeptionell die Stelle, an der Hobby-Player scheitern. Unbedingt sauber planen |
| **SRT-Untertitel** | 200 LOC, 2 Tage | ASS mit Styling: deutlich teurer |
| **Player-UI**: Seekbar, Lautstärke, Vollbild, Playlist, Resume, Tastatursteuerung | 2 Wochen | |
| **Videoausgabe**: YUV→RGB, Skalierung, tearingfreier Blit | 1 Woche | Braucht brauchbaren Framebuffer-Pfad |

**Realistisches ehrliches Zielprofil (~4–7 Monate):** WAV, FLAC, MP3, (Vorbis) + MJPEG-Video in AVI/MOV + MP4/MKV-Demuxing + saubere Bedienung. Das ist ein *guter* Player – nur kein universeller.

### Nicht realistisch (klar so kommunizieren)

| Feature | Warum nicht |
|---|---|
| **H.264-Dekoder (eigen)** | 10.000–20.000 LOC, **3–6 Monate**, danach noch Conformance-Streams. Ohne SIMD + Multithreading schafft naives C etwa 480p, nicht 1080p60. Für einen Player, der „einfach läuft", zu wenig |
| **H.265 / VP9 / AV1** | Ein Vielfaches davon. `dav1d` (AV1) sind zig Personenjahre. **Kategorisch ausschließen** |
| **Hardware-Dekodierung** | Setzt einen echten GPU-Treiber mit Video-Engine-Support voraus – eigenes Großprojekt, NDA-/Doku-Probleme |
| **DVD/Blu-ray** | CSS/AACS-Entschlüsselung, Menü-VMs, rechtlich heikel |
| **HLS/DASH/RTSP-Streaming** | Braucht kompletten TCP/IP-Stack **plus TLS** (TLS allein ist ein Monatsprojekt) plus Netzwerk-Treiber |
| **Transcoding / Streaming-Server / Casting** | Encoder statt Decoder – doppelter Aufwand, Null Nutzen für Justins Erwartung |
| **„Spielt wirklich alles"** | VLCs Alleinstellungsmerkmal *ist* die 30-jährige Codec-Sammelarbeit von FFmpeg. Das ist per Definition nicht replizierbar |

### Die entscheidende strategische Frage

**Wenn die Regel „keine fremden Bibliotheken" verhandelbar ist, ändert sich alles.** Einen Port von FFmpeg/libavcodec auf das eigene OS zu bringen (Teil-libc, `malloc`, Datei-I/O, Threads) kostet **2–6 Wochen** und liefert *sofort* echte VLC-Breite inklusive H.264/H.265/AV1. Das ist ein Faktor 20–50 weniger Arbeit als Eigenbau, bei ungleich besserem Ergebnis. Lizenz: FFmpeg ist LGPL-2.1+ (dynamisch linkbar), `dav1d` BSD, `stb_image`/`minimp3`/`stb_vorbis` Public Domain/MIT.

**Empfehlung:** Eigenbau dort, wo er lehrreich und endlich ist (BMP, GIF, PNG+Inflate, JPEG, FLAC, WAV, Demuxer, Sync-Engine, UI, Audiotreiber). Portierung/Verzicht dort, wo der Eigenbau Monate für ein schlechteres Resultat kostet (H.264+, HEIC, WebP-lossy, AVIF). Und Justin gegenüber die Erwartung ehrlich umformulieren: **„VLC-Gefühl" (robust, konfigurationsfrei, gute Bedienung) ist das Ziel – „VLC-Codec-Umfang" ist es nicht.**

---

**Sources:**
- [JPEG vs. WebP usage statistics – W3Techs](https://w3techs.com/technologies/comparison/im-jpeg,im-webp)
- [Best Image Formats in 2026: WebP vs AVIF vs JPEG vs PNG](https://onlineimageshrinker.com/blog/best-image-formats-2026)
- [Usage statistics of image file formats on websites](https://scanse.io/blog/usage-statistics-image-file-formats/)
- [stb_image.h – nothings/stb (JPEG-Dekoder-Umfang)](https://github.com/nothings/stb/blob/master/stb_image.h)
- [How to extract JPEG decoder source code from stb_image.h – Discussion #1714](https://github.com/nothings/stb/discussions/1714)
- [Exif – Wikipedia (Orientation-Tag)](https://en.wikipedia.org/wiki/Exif)