FFmpeg असेंबली भाषा लेसन

 (github.com/FFmpeg)
3 पॉइंट द्वारा GN⁺ 2025-08-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FFmpeg असेंबली भाषा लेसन कंप्यूटर के अंदरूनी कामकाज को गहराई से समझने के लिए डिज़ाइन किया गया एक open source learning resource है
  • यह repository FFmpeg में इस्तेमाल होने वाली assembly language के वास्तविक उदाहरण और प्रैक्टिस-केंद्रित असाइनमेंट प्रदान करती है
  • सीखने के लिए C language pointers और हाई-स्कूल स्तर के गणित का ज्ञान पूर्व-आवश्यक है
  • इसके ज़रिए FFmpeg open source project में सीधे योगदान देने की क्षमता विकसित की जा सकती है
  • Discord channel के माध्यम से सवाल और चर्चा के लिए सहायता उपलब्ध है

FFmpeg असेंबली भाषा लेसन परिचय

  • FFmpeg School of Assembly Language एक open source lesson है, जिसे प्रोग्रामिंग की सबसे रोचक, चुनौतीपूर्ण और संतोषजनक यात्राओं में से एक शुरू करने में मदद के लिए बनाया गया है
  • इस lesson के माध्यम से FFmpeg में assembly language कैसे लिखी जाती है इसे वास्तविक code के साथ सीखा जा सकता है, और यह भी व्यवस्थित रूप से समझा जा सकता है कि कंप्यूटर के भीतर क्या हो रहा है

आवश्यक ज्ञान

  • C language की समझ, खासकर pointers की अवधारणा, अनिवार्य है
    • यदि C नहीं आती है, तो पहले "The C Programming Language" किताब पढ़ना आवश्यक हो सकता है
  • हाई-स्कूल स्तर का गणित (scalar और vector, addition, multiplication आदि) का ज्ञान पहले से होना चाहिए

lesson की संरचना और उपयोग का तरीका

  • इस GitHub repository में चरणबद्ध lessons और प्रत्येक lesson से जुड़े असाइनमेंट शामिल हैं (असाइनमेंट अभी अपलोड नहीं किए गए हैं)
  • पूरा कोर्स समाप्त करने पर FFmpeg project में सीधे योगदान देने की व्यावहारिक क्षमता हासिल हो जाएगी

कम्युनिटी सहायता

  • Discord server (https://discord.com/invite/Ks5MhUhqfB) के माध्यम से प्रश्नोत्तर और चर्चा में भाग लिया जा सकता है

बहुभाषी अनुवाद

  • lesson फ्रेंच और स्पैनिश में भी उपलब्ध हैं, जिससे अलग-अलग भाषाई पृष्ठभूमि वाले डेवलपर्स के लिए पहुँच आसान होती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-19
Hacker News राय
  • सिर्फ FFMPEG के पैमाने की कल्पना करना ही प्रभावशाली लगता है; बहुत छोटा performance improvement भी हज़ारों, लाखों घंटे की computation बचा सकता है। यह सच में बेहद उपयोगी प्रोजेक्ट है
    • मुझे FFMPEG टीम का performance के प्रति जुनून शानदार लगता है। काश हर प्रोजेक्ट इसी रवैये से काम करता
    • बस, काश इसमें पारंपरिक अर्थों में एक ठोस API होती—imperative command interface नहीं, बल्कि सचमुच library के रूप में—क्योंकि अभी इसकी अपनी भाषा जैसी command line को समझना आसान नहीं है
  • इस पर पिछली चर्चा 2025-02-22 को हुई थी, और 222 comments हैं यहाँ देखे जा सकते हैं
  • जिज्ञासा है कि compiler द्वारा बने non-optimized assembly की वजह से पैदा होने वाले hotspots को वास्तव में कैसे खोजा जाता है, और यह भी कि architecture-specific assembly की जगह LLVM IR जैसी intermediate representation सीधे लिखना कितना सार्थक है
    • बहुत से लोग जिन समस्याओं के बारे में सोचते हैं, वे असली issues से अलग होती हैं। असल में मामला “non-optimized assembly” का नहीं, बल्कि C compiler से सामान्यतः जितनी उम्मीद की जा सकती है उतने स्तर का है। मुख्य कारण ये हैं: loops के लिए सामान्य C implementation होती है और hardware-specific asm/SIMD versions अलग से जोड़े जाते हैं, लेकिन हर platform की SIMD विशेषताएँ अलग होने से इन्हें generalize करना मुश्किल है; compiler version के अंतर की वजह से सभी users को हमेशा सबसे अच्छी implementation नहीं मिलती; C का memory model और char * का उपयोग optimization में बाधा डालते हैं; intrinsics और auto-vectorization features कभी-कभी एक-दूसरे से टकराते भी हैं; और Intel C में intrinsics के मामले में Microsoft द्वारा बनाए गए जटिल function names के कारण कभी-कभी assembly ज़्यादा पढ़ने योग्य लगती है
    • आम तौर पर vtune या uprof जैसे tools से ISA level पर benchmark hotspots का विश्लेषण किया जाता है; ARM के tools के बारे में मुझे ज़्यादा जानकारी नहीं है। LLVM IR जैसी intermediate representation इंसान द्वारा सीधे लिखने का व्यावहारिक महत्व बहुत कम है। ज़्यादातर मामलों में सीधे assembly सिर्फ architecture-specific समस्याओं के लिए लिखी जाती है। C/C++ compilers आम तौर on optimized code अच्छी तरह बनाते हैं, लेकिन vectorized code के लिए अक्सर algorithm itself बदलना पड़ता है, intrinsics का उपयोग अपरिहार्य हो जाता है, और उस स्थिति में code कम portable होकर assembly जैसा दिखने लगता है। इसके अलावा compiler-generated code overhead भी होता है। इसलिए कई बार सीधे assembly लिखना बेहतर पड़ता है ताकि register allocation, instruction ordering वगैरह पर इंसान खुद ध्यान दे सके। अंततः hand-coded assembly, compiler-generated code से बेहतर है या नहीं, यह सिर्फ मापकर ही पता चल सकता है; benchmark अनिवार्य है
    • LLVM IR को सीधे लिखने का खास मतलब नहीं है। अगर लक्ष्य vector code है, तो पहले vectorization directives (pragmas) आज़माने चाहिए; वह न चले तो intrinsics या ISPC जैसी language का उपयोग ज़्यादा प्रभावी है। IR से कोई खास लाभ नहीं मिलता। अगर आप compiler की register allocation या instruction selection समस्याओं को खुद संभालना भी चाहें, तो IR में लिखने पर भी compiler अंततः उसे अपने तरीके से code में बदल देगा। नतीजतन IR एक अस्थिर परत जोड़ता है जो उपयोग में और कठिन है। सबसे अच्छा hand-coded assembly बनाना हो तो सीधे assembly लिखना ही सही है
  • अफ़सोस है कि यह उदाहरणों की शुरुआत किसी असली assembler जैसे NASM पर हाथ-से-करने वाली सरल introduction से नहीं करता
  • मुझे उम्मीद थी कि इसमें प्रोजेक्ट के लंबे अनुभव से निकली insights या know-how मिलेगी, लेकिन इसे पढ़कर ffmpeg से सीधा जुड़ाव उतना महसूस नहीं हुआ। कम-से-कम कुछ chapters देखने पर यह बस एक सामान्य assembly introduction जैसा लगा
  • लगता है कि FFmpeg Assembly Lessons के लिए ज़रूरी mathematics lecture materials भी GitHub repository में शामिल कर दिए जाएँ तो शुरुआत करना आसान होगा, क्योंकि तब सारी सामग्री एक ही जगह मिल जाएगी
    • मैं लेखक नहीं हूँ, लेकिन अगर कोई पाठक सिर्फ C programming की बुनियादी जानकारी रखता है और सच में video codec में योगदान देना चाहता है, तो Cooley-Tukey algorithm जैसी चीज़ों तक पहुँचने से पहले काफ़ी background knowledge कवर करनी पड़ती है—और वह भी सिर्फ बुनियादी हिस्सा है
  • जिज्ञासा है कि यह assembly code अलग-अलग CPU पर portability कैसे सुनिश्चित करता है
    • मेरा मानना है कि सामान्य C में चलने वाला implementation baseline का काम करता है, और प्रमुख architectures के लिए hand-written assembly versions मौजूद हैं
    • वास्तव में यह सिर्फ x86-64 को target करता है
  • इसे पढ़ना बहुत दिलचस्प लगा; domain-specific tutorial कहीं बेहतर लगते हैं
  • इसमें nasm के macro preprocessor का काफ़ी ज़्यादा इस्तेमाल किया गया है, जिससे इसे किसी दूसरे assembler में port करना काफ़ी मुश्किल हो सकता है
    • वैसे किसी दूसरे assembler में port करने की ज़रूरत ही क्यों पड़ेगी, यह भी सवाल है
    • जानना चाहूँगा कि ऐसा किन हिस्सों में हुआ; lesson code में तो वास्तव में बहुत कम code है