FFmpeg, मल्टीथ्रेडेड ट्रांसकोडिंग पाइपलाइन पेश

 (ffmpeg.org)
2 पॉइंट द्वारा GN⁺ 2023-11-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FFmpeg CLI की मल्टीथ्रेडेड ट्रांसकोडिंग लगभग 2 साल के काम और 700 से अधिक तैयारी कमिट्स के बाद अपने पहले “पूरी तरह कार्यशील” रूप में पेश की गई है
  • बदलाव का दायरा बड़ा होने के कारण कुछ फ़ीचर्स के टूटे होने की संभावना बनी हुई है, और वास्तविक मर्ज से पहले टेस्टिंग और रिव्यू प्रमुख कार्य बने हुए हैं
  • -fix_sub_duration_heartbeat के लिए डिकोडर, एन्कोडर और muxer के बीच सिंक्रोनाइज़ेशन की धारणा होने से async execution में non-deterministic behavior से बचना कठिन है
  • threading overhead आम तौर पर कम है, लेकिन जिन कार्यों में प्रति पैकेट काम बहुत कम है, उनमें performance gain से अधिक इसकी लागत दिख सकती है
  • यदि bottleneck किसी एक component में केंद्रित न हो और हर component पहले से पूरी तरह multithreaded न हो, तो multicore वातावरण में CPU utilization और वास्तविक processing time में बड़ा सुधार हो सकता है

FFmpeg CLI मल्टीथ्रेडिंग पैच के मुख्य बिंदु

  • लगभग 2 साल के काम और 700 से अधिक तैयारी कमिट्स के बाद, मल्टीथ्रेडेड FFmpeg CLI का पहला “fully functional” संस्करण patch set के रूप में जारी किया गया है
  • बदलाव का पैमाना बड़ा होने के कारण अभी भी ऐसे breakage की संभावना है जो पकड़ी नहीं गई हो, इसलिए वास्तविक use case पर आधारित टेस्टिंग और रिव्यू की ज़रूरत है
  • सामान्य स्थितियों में threading overhead कम है, लेकिन जिन workloads में प्रति पैकेट काम बहुत कम है, वहाँ overhead महत्वपूर्ण हो सकता है
  • यदि transcoding किसी एक component से नियंत्रित नहीं होती और हर component पहले से अपनी multithreading से saturation पर नहीं है, तो multicore systems में CPU utilization और execution time बेहतर हो सकते हैं

संचालन सीमाएँ और ज्ञात समस्याएँ

  • -fix_sub_duration_heartbeat विकल्प मौजूदा संरचना में अलग-अलग components के बीच synchronization को मानकर चलता है
    • लक्ष्य प्रवाह encoder·muxer से decoder तक जाने वाला synchronization है
    • जब हर component async तरीके से चलता है, तो व्यवहार मूल रूप से non-deterministic हो जाता है
    • अभी भी इसका व्यवहार अनुमान लगाना कठिन है, लेकिन उसी विकल्प के साथ चलाने पर अलग-अलग runs में परिणाम deterministic रहते हैं
    • 16/24 patch में यह विकल्प disable किया गया है, और इसके लिए बेहतर handling की ज़रूरत है

24-पैच सेट की संरचना

  • patch set कुल 24 पैच से बना है
    • 01-09/24 तैयारी वाले fixes हैं, और इन्हें बाकी series से पहले push किया जा सकता है
    • 10-17/24 encoding और filtering को threads में ले जाते हैं और ज़रूरी तैयारी बदलाव करते हैं
      • इस चरण की threading “नकली” threading है, जहाँ main thread दूसरे threads के पूरा होने का इंतज़ार करता है, इसलिए यह वास्तविक parallel execution नहीं है
      • अस्थायी overhead बड़ा हो सकता है या कुछ corner cases टूट सकते हैं, इसलिए पूरा set तैयार होने के बाद ही push करना अधिक उचित है
    • 18/24 सबसे बड़ा एकल patch है, जो transcode scheduler जोड़ता है, लेकिन उस चरण पर यह अभी वास्तव में काम नहीं करता
    • 19-24/24 अलग-अलग components को scheduler उपयोग करने वाले तरीके में बदलते हैं
      • इन्हें review के लिए अलग किया गया है, लेकिन अंतिम push में इन्हें मिलाया जाना चाहिए
  • संबंधित सामग्री हाल की VDD प्रस्तुति वीडियो और ffmpeg_threading branch में देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2023-11-07
Hacker News की राय

  • 4-core ARM server पर यह लगभग 2 गुना तेज़ हो गया, और parallelization overhead ज़्यादा नहीं दिखता
    ffmpeg_threading/ffmpeg ने 7.771 सेकंड लिए, पुराने ffmpeg ने 13.841 सेकंड लिए, और CPU उपयोग क्रमशः 218% और 114% था

    • यहाँ decoding पक्ष पर hardware acceleration इस्तेमाल नहीं किया गया था, और video output भी हटा दिया गया था
      सोच रहा हूँ कि NVIDIA card पर video decoding और encoding दोनों के लिए hardware acceleration इस्तेमाल करने पर क्या होगा: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • मुझे उत्सुकता है कि कौन-सा हिस्सा multithreading हो रहा है। video compression तो पहले से multithreaded है, और video decompression के बारे में निश्चित नहीं हूँ
      बाकी काम performance cost के लिहाज़ से अपेक्षाकृत छोटे लगते हैं, इसलिए improvement अच्छी है, लेकिन वास्तविक असर काफ़ी सीमित रहने की उम्मीद है

  • tweet के बजाय https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... link करना बेहतर होता
    tweet का मुख्य point भी आखिरकार यही link है

    • अब इसे बस post कह सकते हैं। 280-character limit भी अब नहीं है, और लंबे लेख बस default रूप से collapsed रहते हैं

  • इसे समझने के लिए VideoLAN Dev Days 2023 में Anton की presentation देखना अच्छा रहेगा: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • presentation अच्छी थी, और “Future directions” में बताए गए dynamic pipelines और “scripting (Lua?)” से उनका क्या मतलब था, यह जानने की उत्सुकता है
      इससे property animations को ज़्यादा powerful तरीके से संभालने की दिशा की कल्पना होती है
    • video में करीब 33 मिनट पर slide में दिखे Extras से जुड़ी समस्याएँ मैंने सच में बहुत झेली हैं
    • मैं presentation ज़रूर देखना चाहता हूँ, लेकिन audio quality इतनी खराब है कि ध्यान लगाना मुश्किल है। आजकल भी कोई इसे इतना बुरी तरह कैसे बिगाड़ सकता है, समझ नहीं आता
    • समझने में कठिन हिस्सा कौन-सा है, यह समझ नहीं आ रहा। क्या video transcoding क्षेत्र में multithreaded का मतलब अलग तरह से लिया जाता है?

  • tweet http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655... पर जाता है, और वहाँ से फिर code https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading को refer करता है

    • tweet patchset के official source, यानी mailing list, पर जाता है। आगे पढ़ने के लिए “Next in Thread” चुन सकते हैं

  • क्या यह अपने आप लागू होता है, या command-line parameters का जटिल combination बनाना पड़ेगा, यह जानना चाहता हूँ

  • सोच रहा हूँ कि ffmpeg का इस्तेमाल करने वाला कोई video editing software है क्या
    कभी सोचा था कि SVG से shapes draw करूँ और ffmpeg इस्तेमाल करूँ, या उस पर UI लगाऊँ, या सिर्फ़ text जोड़ने वाला कुछ बनाऊँ, लेकिन शुरू नहीं किया
    Avidemux कुछ-कुछ वैसा लगता है, और ffmpeg के अंदरूनी हिस्से काफ़ी raw हैं, इसलिए GUI से access कराने के लिए उनका इस्तेमाल नहीं होता; उस पर आधारित editor सुस्त, अजीब और maintain करना मुश्किल लगेगा
    command descriptor या pipeline viewer के साथ preview बनाने वाला modular editor जैसा कुछ संभव लगता है
    ffmpeg powerful है, लेकिन सिर्फ़ command line से इस्तेमाल होने की वजह से कुछ users के लिए बाधा बनता है। पहले मैंने random संख्या में clips लेकर xstack filter से mosaic बनाने वाली Python script लिखी थी, और यह आसान नहीं था

    • आप जिस middle ground की तलाश कर रहे हैं, उसके लिए VapourSynth सही हो सकता है। ffmpeg CLI के बजाय Python से video manipulate कर सकते हैं, और extensions की वजह से कई बार यह pure ffmpeg से ज़्यादा extensible और powerful होता है
      https://vsdb.top/
      https://www.vapoursynth.com/
      ffmpeg-based niche software में मैंने losslesscut देखा है: https://github.com/mifi/lossless-cut
      Staxrip भी बड़ा है: https://github.com/staxrip/staxrip
      हालाँकि “comprehensive” editor के बारे में ठीक से नहीं जानता
    • https://shotcut.org/ भी ffmpeg इस्तेमाल करता है
    • KDEnlive है। यह बेहतरीन free open-source video editing software है

  • Plex के लिए जो छोटा transcoding काम करता हूँ, वह तेज़ हो जाए तो अच्छा होगा
    मेरे graphics card में hardware transcoding support नहीं है, इसलिए उम्मीद है

  • मैं transcoding speed बढ़ाने के तरीके ढूँढ रहा था, एक था GPU acceleration, और दूसरा था threads की संख्या बढ़ाना
    लेकिन optimal thread count ढूँढना मुश्किल है

    • optimal value ढूँढने के लिए hyperparameter optimization का इस्तेमाल क्यों न करें? Sherpa या Scikit-optimize जैसे tools से thread count, input type, CPU type जैसे search space को explore किया जा सकता है
    • ज़्यादातर workloads में thread count को vCPU count के बराबर रखना ठीक रहता है। यानी hyperthreaded cores को 2 गिनें
      हालाँकि अगर संभव हो तो GPU acceleration कहीं बेहतर है

  • बड़े पैमाने पर ffmpeg deployment में license requirements क्या होंगी, यह जानना चाहता हूँ। किन मामलों में payment की ज़रूरत होती है?

    • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
      http://ffmpeg.org/legal.html
      यानी यह free है, लेकिन कुछ modules इस्तेमाल करने पर proprietary code के साथ मिलाने में समस्या आ सकती है
    • proprietary software के अंदर ffmpeg इस्तेमाल करने का आम तरीका यह है कि इस्तेमाल किए जा रहे ffmpeg version को statically compile करके executable से link करें, या proprietary software से उसे अलग executable के रूप में call कराएँ

  • FFmpeg में सुधार होते देखना अच्छा है। उम्मीद है जल्द ही Dolby AC4 support भी देखने को मिलेगा