Pelajaran Bahasa Assembly FFmpeg

• Pelajaran Bahasa Assembly FFmpeg adalah materi pembelajaran open source yang dirancang untuk membantu memahami cara kerja internal komputer secara mendalam
• Repositori ini menyediakan contoh nyata bahasa assembly yang digunakan di FFmpeg serta tugas praktik yang berfokus pada latihan
• Pengetahuan tentang pointer dalam bahasa C dan matematika tingkat sekolah menengah merupakan prasyarat untuk belajar
• Melalui materi ini, pembelajar dapat mengembangkan kemampuan untuk berkontribusi langsung pada proyek open source FFmpeg
• Dukungan tanya jawab dan diskusi tersedia melalui kanal Discord

---

Pengenalan Pelajaran Bahasa Assembly FFmpeg

• FFmpeg School of Assembly Language adalah pelajaran open source yang dibuat untuk memulai salah satu perjalanan paling menarik, menantang, dan memuaskan dalam pemrograman
• Melalui pelajaran ini, Anda dapat mempelajari bagaimana bahasa assembly ditulis di FFmpeg lewat kode nyata, serta memahami secara sistematis apa yang terjadi di dalam komputer

Pengetahuan yang Diperlukan

• Pemahaman tentang bahasa C, terutama konsep pointer, merupakan hal yang wajib
  • Jika belum mengenal C, Anda perlu mempelajari terlebih dahulu buku "The C Programming Language"
• Pengetahuan matematika tingkat sekolah menengah (skalar dan vektor, penjumlahan, perkalian, dan sebagainya) juga diperlukan

Struktur Pelajaran dan Cara Memanfaatkannya

• Repositori GitHub ini mencakup pelajaran bertahap dan tugas yang sesuai untuk setiap pelajaran (tugas belum diunggah)
• Setelah menyelesaikan seluruh proses, Anda akan memiliki kemampuan praktis untuk berkontribusi langsung pada proyek FFmpeg

Dukungan Komunitas

• Anda dapat mengikuti tanya jawab dan diskusi melalui server Discord (https://discord.com/invite/Ks5MhUhqfB)

Terjemahan Multibahasa

• Pelajaran ini juga tersedia dalam bahasa Prancis dan Spanyol, sehingga lebih mudah diakses oleh pengembang dari berbagai latar bahasa

[GN⁺]

Komentar Hacker News

• Hanya dengan membayangkan skala FFMPEG saja sudah terasa mengagumkan; bahkan peningkatan performa yang sangat kecil pun bisa menghemat ribuan hingga puluhan ribu jam komputasi, benar-benar proyek yang berguna
  • Menurut saya, kegigihan tim FFMPEG terhadap performa itu keren; andai semua proyek punya sikap seperti itu, pasti luar biasa
  • Hanya saja, saya berharap ada API yang benar-benar jelas dalam arti tradisionalnya (bukan yang bersifat imperatif, melainkan benar-benar dalam bentuk library); memahami command line yang terasa seperti bahasa sendiri seperti sekarang ini tidak mudah
• Ada diskusi sebelumnya pada 2025-02-22, dengan 222 komentar, bisa dilihat di sini
• Saya penasaran bagaimana sebenarnya hotspot yang muncul karena assembly tidak optimal hasil keluaran compiler itu ditemukan, dan juga apakah ada gunanya menulis langsung representasi perantara seperti LLVM IR alih-alih assembly per arsitektur
  • Banyak masalah yang orang bayangkan ternyata berbeda dari isu yang sebenarnya; pada praktiknya ini bukan soal “assembly yang tidak optimal”, melainkan sudah berada pada tingkat yang wajar untuk yang bisa diharapkan dari compiler C. Faktor utamanya antara lain: ada implementasi C umum untuk loop dan ada versi asm/SIMD tambahan per perangkat keras, tetapi karakteristik SIMD berbeda di tiap platform sehingga sulit digeneralisasi; perbedaan versi compiler bisa membuat tidak semua pengguna memanfaatkan implementasi terbaik; model memori C dan penggunaan char * menghambat optimisasi; intrinsic dan auto-vectorization juga kadang saling bertabrakan; di Intel C, intrinsic justru kadang membuat assembly lebih mudah dibaca karena nama fungsi rumit buatan Microsoft
  • Biasanya hotspot benchmark pada level ISA dianalisis dengan alat seperti vtune atau uprof; saya kurang tahu alat untuk ARM. Menulis langsung representasi perantara seperti LLVM IR pada praktiknya tidak terlalu berarti; dalam kebanyakan kasus, assembly ditulis langsung hanya untuk masalah yang khas arsitektur. Compiler C/C++ umumnya sudah menghasilkan kode teroptimasi dengan baik, tetapi untuk kode yang divektorkan, algoritmanya sendiri sering harus diubah dan penggunaan intrinsic menjadi tak terhindarkan; dalam kasus seperti ini kodenya jadi kurang portabel dan mulai tampak seperti assembly. Ditambah lagi ada overhead dari kode yang dihasilkan compiler, jadi lebih baik langsung menulis dalam assembly dan membiarkan manusia sendiri yang memperhatikan alokasi register atau urutan instruksi. Pada akhirnya, apakah hand-coded assembly lebih baik daripada hasil compiler hanya bisa diketahui dengan mengukurnya; benchmark itu wajib
  • Menulis LLVM IR langsung tidak terlalu ada artinya; jika tujuannya untuk kode vektor, lebih baik coba dulu directive vectorization (pragmas), dan kalau gagal gunakan intrinsic atau bahasa seperti ISPC, itu lebih efisien. Tidak ada keuntungan yang didapat dari menulis IR. Bahkan jika ingin langsung menangani masalah alokasi register atau pemilihan instruksi compiler, saat ditulis dalam IR pun compiler pada akhirnya akan membangunnya kembali menjadi kode sesuai caranya sendiri. Akibatnya, IR hanya menambah lapisan yang tidak stabil dan lebih sulit digunakan. Jika ingin membuat hand-coded assembly terbaik, memang sebaiknya langsung menulis assembly
• Sayangnya, pengantar ini tidak dimulai dari latihan sederhana menggunakan assembler sungguhan seperti NASM
• Saya sempat berharap ada wawasan atau kiat yang lahir dari banyaknya pengalaman proyek ini, tetapi saya tidak terlalu merasakan keterkaitan langsung dengan ffmpeg; dari beberapa bab yang saya lihat, rasanya lebih seperti materi pengantar assembly yang umum
• Saya pikir akan bagus jika materi kuliah matematika yang diperlukan untuk FFmpeg Assembly Lessons juga dimasukkan ke repositori GitHub, supaya semua materi terkumpul di satu tempat dan lebih mudah untuk mulai
  • Saya bukan penulisnya, tetapi kalau pembacanya hanya punya dasar pemrograman C dan ingin benar-benar berkontribusi pada codec video, ada cukup banyak pengetahuan latar belakang yang perlu dibahas sebelum sampai ke hal seperti algoritma Cooley-Tukey, dan itu pun baru dasar-dasarnya saja
• Saya penasaran bagaimana kode assembly ini menjaga portabilitas di berbagai CPU
  • Menurut saya, pemrosesan yang berjalan dalam C umum juga berperan sebagai baseline, dan untuk arsitektur utama ada versi assembly yang ditulis manual
  • Pada praktiknya, targetnya hanya x86-64
• Sangat menarik untuk dibaca; menurut saya tutorial yang spesifik pada domain memang jauh lebih baik
• Ada bagian yang sangat berlebihan dalam penggunaan macro preprocessor milik nasm, sehingga sepertinya akan sangat sulit dipindahkan ke assembler lain
  • Saya malah bertanya-tanya kenapa harus repot memindahkannya ke assembler lain
  • Saya penasaran bagian mana yang seperti itu; dalam kode pelajarannya sendiri sebenarnya hampir tidak ada kode sama sekali