FFmpeg-Assembler-Sprachlektionen

 (github.com/FFmpeg)
3 Punkte von GN⁺ 2025-08-19 | 1 Kommentare | Auf WhatsApp teilen
  • FFmpeg-Assembler-Sprachlektionen sind als Open-Source-Lernmaterial konzipiert, um ein tiefes Verständnis der internen Funktionsweise von Computern zu ermöglichen
  • Dieses Repository bietet praxisnahe Beispiele und auf Übungen fokussierte Aufgaben zur in FFmpeg verwendeten Assemblersprache
  • C-Zeiger und Mathematik auf Oberstufenniveau sind Voraussetzungen für das Lernen
  • Dadurch kann man die Fähigkeit entwickeln, direkt zum FFmpeg-Open-Source-Projekt beizutragen
  • Über einen Discord-Kanal werden Unterstützung für Fragen und Diskussionen angeboten

Einführung in die FFmpeg-Assembler-Sprachlektionen

  • FFmpeg School of Assembly Language ist eine Open-Source-Lektion, die dafür geschaffen wurde, den Start in eine der interessantesten, anspruchsvollsten und lohnendsten Reisen im Programmieren zu ermöglichen
  • Durch diese Lektion kann man anhand echten Codes lernen, wie Assemblersprache in FFmpeg geschrieben wird, und systematisch verstehen, was im Inneren eines Computers geschieht

Erforderliche Kenntnisse

  • Verständnis von C, insbesondere das Konzept von Zeigern, ist unerlässlich
    • Wer C nicht kennt, sollte zunächst das Buch "The C Programming Language" durcharbeiten
  • Vorkenntnisse in Mathematik auf Oberstufenniveau (Skalare und Vektoren, Addition, Multiplikation usw.) werden vorausgesetzt

Aufbau der Lektionen und Nutzung

  • Dieses GitHub-Repository enthält schrittweise Lektionen und zu jeder Lektion passende Aufgaben (die Aufgaben sind noch nicht hochgeladen)
  • Wer den gesamten Kurs absolviert, erlangt die praktischen Fähigkeiten, direkt zum FFmpeg-Projekt beizutragen

Community-Unterstützung

Mehrsprachige Übersetzungen

  • Die Lektionen sind auch auf Französisch und Spanisch verfügbar, was die Zugänglichkeit für Entwickler aus verschiedenen Sprachräumen erhöht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-19
Hacker-News-Kommentare
  • Allein sich die Größenordnung von FFmpeg vorzustellen, ist beeindruckend; selbst sehr kleine Performance-Verbesserungen sparen Tausende oder Zehntausende Stunden an Rechenzeit, wirklich ein nützliches Projekt
    • Ich finde die Besessenheit des FFmpeg-Teams von Performance großartig; man stellt sich vor, wie schön es wäre, wenn alle Projekte mit so einer Haltung arbeiten würden
    • Allerdings hätte ich gern eine echte API im traditionellen Sinn gehabt (nicht imperativ, sondern wirklich als Bibliothek); es ist nicht leicht, eine Kommandozeile zu verstehen, die sich wie eine eigene Sprache anfühlt
  • Es gab bereits am 2025-02-22 eine frühere Diskussion, mit 222 Kommentaren, hier zu finden
  • Ich frage mich, wie man Hotspots, die durch vom Compiler erzeugten nicht optimalen Assembler entstehen, in der Praxis tatsächlich findet, und ob es sinnvoll ist, statt architekturspezifischem Assembler direkt eine Zwischendarstellung wie LLVM IR zu schreiben
    • Viele der Probleme, die Leute sich vorstellen, sind nicht die tatsächlichen Issues; in Wirklichkeit geht es nicht um „nicht optimalen Assembler“, sondern eher um das Niveau, das man von einem C-Compiler erwarten kann. Die Hauptfaktoren sind folgende: Es gibt eine allgemeine C-Implementierung der Schleife und zusätzlich asm-/SIMD-Versionen für bestimmte Hardware, aber SIMD-Eigenschaften unterscheiden sich je nach Plattform, sodass Verallgemeinerung schwierig ist; Unterschiede zwischen Compilerversionen können dazu führen, dass nicht alle Nutzer die beste Implementierung verwenden können; das Speichermodell von C und die Verwendung von char * behindern Optimierungen; Intrinsics und Auto-Vektorisierung geraten manchmal miteinander in Konflikt; bei Intel C sind Intrinsics wegen der komplizierten, von Microsoft geschaffenen Funktionsnamen manchmal sogar schlechter lesbar als Assembler
    • Normalerweise analysiert man Benchmark-Hotspots auf ISA-Ebene mit Tools wie vtune oder uprof; bei Tools für ARM kenne ich mich nicht gut aus. Eine Zwischendarstellung wie LLVM IR direkt von Hand zu schreiben, hat in der Praxis keinen großen Sinn. In den meisten Fällen schreibt man Assembler nur direkt für architekturspezifische Probleme. C/C++-Compiler erzeugen im Allgemeinen gut optimierten Code, aber bei vektorisiertem Code muss man oft den Algorithmus selbst verändern, Intrinsics werden unvermeidlich, und dann wird der Code weniger portabel und sieht wie Assembler aus. Dazu kommt Overhead im vom Compiler erzeugten Code. Dann ist es oft besser, es gleich direkt in Assembler zu schreiben und Registerzuweisung oder Befehlsreihenfolge selbst im Blick zu behalten. Ob handgeschriebener Assembler am Ende besser ist als compilererzeugter, weiß man nur durch Messen; Benchmarks sind zwingend nötig
    • LLVM IR direkt zu schreiben, bringt wenig. Wenn das Ziel Vektorcode ist, sollte man zuerst Vektorisierungs-Direktiven (pragmas) ausprobieren und, wenn das scheitert, Intrinsics oder eine Sprache wie ISPC verwenden. Man gewinnt durch IR nichts. Selbst wenn man Probleme bei Registerzuweisung oder Befehlsauswahl des Compilers selbst lösen will, formt der Compiler es bei IR am Ende ohnehin wieder in seinen eigenen Code um. Letztlich fügt IR nur eine instabile und schwerer zu nutzende zusätzliche Ebene hinzu. Wenn man den besten handgeschriebenen Assembler erzeugen will, sollte man ihn einfach direkt in Assembler schreiben
  • Schade, dass es nicht mit einer einfachen Einführung beginnt, bei der man Beispiele tatsächlich mit einem Assembler wie NASM ausprobiert
  • Ich hatte auf Einsichten oder Know-how aus den vielen Erfahrungen des Projekts gehofft, aber ich habe nicht wirklich das Gefühl, dass es direkt mit ffmpeg verbunden ist; nachdem ich nur ein paar Kapitel gesehen habe, wirkt es eher wie eine allgemeine Einführung in Assembler
  • Ich denke, es wäre gut, wenn die für die FFmpeg Assembly Lessons nötigen Mathematik-Unterlagen ebenfalls im GitHub-Repository enthalten wären; wenn alles an einem Ort ist, wäre der Einstieg einfacher
    • Ich bin nicht der Autor, aber wenn ein Leser nur grundlegende C-Programmierkenntnisse hat und tatsächlich zu einem Video-Codec beitragen möchte, gibt es ziemlich viel Hintergrundwissen, das man behandeln muss, bevor man bei Dingen wie dem Cooley-Tukey-Algorithmus ankommt, und selbst das ist nur das Grundlegende
  • Ich frage mich, wie diese Assembler-Codes Portabilität über verschiedene CPUs hinweg sicherstellen
    • Meiner Meinung nach dient die allgemeine Verarbeitung in C auch als Baseline, und für die wichtigsten Architekturen gibt es handgeschriebene Assembler-Versionen
    • Tatsächlich ist nur x86-64 das Ziel
  • Sehr interessant zu lesen, ich finde domänenspezifische Tutorials deutlich besser
  • Es gibt Stellen, an denen der Makro-Präprozessor von nasm stark überstrapaziert wurde; das dürfte die Portierung auf andere Assembler ziemlich schwierig machen
    • Ich frage mich, warum man überhaupt auf einen anderen Assembler portieren müsste
    • Ich frage mich, an welchen Stellen das so war; im Unterrichtscode gibt es tatsächlich kaum Code