Lecciones de lenguaje ensamblador de FFmpeg

 (github.com/FFmpeg)
3 puntos por GN⁺ 2025-08-19 | 1 comentarios | Compartir por WhatsApp
  • Lecciones de lenguaje ensamblador de FFmpeg es un material de aprendizaje de código abierto diseñado para permitir una comprensión profunda del funcionamiento interno de las computadoras
  • Este repositorio ofrece ejemplos reales del lenguaje ensamblador utilizado en FFmpeg y ejercicios prácticos centrados en la práctica
  • El conocimiento de punteros en C y de matemáticas de nivel preparatoria es un requisito previo para el aprendizaje
  • A través de esto, es posible desarrollar la capacidad de contribuir directamente al proyecto de código abierto FFmpeg
  • Se ofrece soporte para preguntas y discusión a través de un canal de Discord

Introducción a las lecciones de lenguaje ensamblador de FFmpeg

  • FFmpeg School of Assembly Language es una lección de código abierto creada para que puedas iniciar uno de los viajes más interesantes, desafiantes y gratificantes en la programación
  • A través de esta lección, puedes aprender con código real cómo se escribe el lenguaje ensamblador en FFmpeg y comprender de manera sistemática qué está ocurriendo dentro de la computadora

Conocimientos requeridos

  • Es indispensable comprender el lenguaje C, especialmente el concepto de punteros
    • Si no conoces C, primero necesitas estudiar el libro "The C Programming Language"
  • Se requieren conocimientos de matemáticas de nivel preparatoria (escalares y vectores, suma, multiplicación, etc.)

Estructura de las lecciones y cómo aprovecharlas

  • Este repositorio de GitHub incluye lecciones paso a paso y tareas correspondientes a cada lección (las tareas aún no se han subido)
  • Al completar todo el proceso, adquirirás capacidades prácticas para contribuir directamente al proyecto FFmpeg

Soporte de la comunidad

Traducción a varios idiomas

  • Las lecciones también están disponibles en francés y español, lo que mejora la accesibilidad para desarrolladores de distintas comunidades lingüísticas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-19
Opiniones en Hacker News
  • Solo imaginar la escala de FFMPEG ya me parece impresionante; incluso una mejora de rendimiento muy pequeña puede ahorrar miles o decenas de miles de horas de cómputo, de verdad es un proyecto muy útil
    • Me parece admirable la obsesión del equipo de FFMPEG con el rendimiento; imagino lo bueno que sería si todos los proyectos tuvieran esa actitud
    • Eso sí, ojalá hubiera una API clara en el sentido tradicional (no imperativa, sino una biblioteca de verdad); no es fácil entender una línea de comandos que parece su propio lenguaje como ahora
  • Hubo una discusión anterior el 2025-02-22, con 222 comentarios disponible aquí
  • Me da curiosidad cómo encuentran en la práctica los hotspots causados por ensamblador no optimizado generado por el compilador, y también si tiene sentido escribir directamente una representación intermedia como LLVM IR en vez de ensamblador por arquitectura
    • Muchos de los problemas que la gente imagina no coinciden con los problemas reales; en la práctica no se trata de “ensamblador no optimizado”, sino del nivel esperable de un compilador de C. Los factores principales son estos: hay implementaciones generales en C para los bucles y versiones asm/SIMD adicionales según el hardware, pero las características SIMD cambian entre plataformas y eso dificulta generalizar, las diferencias entre versiones de compilador pueden impedir que todos los usuarios aprovechen la mejor implementación, el modelo de memoria de C y el uso de char * interfieren con la optimización, los intrinsics y la auto-vectorización a veces entran en conflicto, y en Intel C los intrinsics incluso pueden hacer que el ensamblador sea más legible que los nombres de función complicados creados por Microsoft
    • Normalmente se analizan los hotspots de benchmark a nivel ISA con herramientas como vtune o uprof; no conozco bien las herramientas para ARM. Escribir a mano una representación intermedia como LLVM IR realmente no aporta mucho en la práctica; en la mayoría de los casos solo se termina escribiendo ensamblador directamente para problemas específicos de cada arquitectura. Los compiladores de C/C++ por lo general generan buen código optimizado, pero el código vectorizado exige cambiar el algoritmo mismo, hace inevitable usar intrinsics y entonces el código pierde portabilidad y empieza a verse como ensamblador. Además, queda el overhead del código generado por el compilador, así que suele ser mejor escribirlo directamente en ensamblador y dejar en manos de la persona cosas como la asignación de registros o el orden de las instrucciones. Al final, solo midiendo se sabe si el ensamblador escrito a mano es mejor que el generado por el compilador; el benchmark es indispensable
    • Escribir LLVM IR directamente no tiene mucho sentido. Si el objetivo es código vectorial, conviene probar primero con pragmas de vectorización y, si eso falla, usar intrinsics o un lenguaje como ISPC. No hay ninguna ganancia real en usar IR. Aunque quieras resolver tú mismo problemas de asignación de registros o selección de instrucciones del compilador, si lo escribes en IR el compilador igual termina reconstruyéndolo en su propio código. En la práctica, el IR solo agrega una capa inestable y más difícil de usar. Si quieres hacer el mejor ensamblador escrito a mano, lo correcto es escribir ensamblador directamente
  • Es una pena que no empiece con una introducción sencilla para practicar los ejemplos en un ensamblador real como NASM
  • Esperaba ideas o trucos nacidos de la enorme experiencia acumulada en el proyecto, pero no sentí que conectara tan directamente con ffmpeg; viendo solo algunos capítulos, parece más bien contenido general de introducción al ensamblador
  • Pienso que estaría bien incluir también en el repositorio de GitHub el material de las clases de matemáticas necesarias para FFmpeg Assembly Lessons; sería más fácil empezar si todo el material estuviera en un solo lugar
    • No soy el autor, pero si una persona lectora solo conoce lo básico de programación en C y quiere contribuir a un códec de video real, hay bastante conocimiento previo que cubrir antes de llegar a temas como el algoritmo de Cooley-Tukey, y eso apenas sería lo básico
  • Me da curiosidad cómo este código ensamblador logra mantener portabilidad entre distintos CPU
    • Según yo, el procesamiento que corre en C genérico también sirve como baseline, y para las arquitecturas principales hay versiones de ensamblador escritas a mano
    • En realidad, solo apunta a x86-64
  • Me pareció una lectura muy interesante; siento que un tutorial especializado por dominio es mucho mejor
  • Hay bastante abuso del preprocesador de macros de nasm; probablemente eso haría bastante difícil migrarlo a otro ensamblador
    • Me pregunto para qué habría que migrarlo a otro ensamblador
    • Me da curiosidad en qué parte pasó eso; en el código del curso casi no hay código realmente