FFmpeg 8.0 रिलीज़

 (ffmpeg.org)
2 पॉइंट द्वारा GN⁺ 2025-08-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FFmpeg 8.0 "Huffman" में Vulkan compute-आधारित codec और hardware-accelerated decoding·encoding, साथ ही कई नए file formats और filters जोड़े गए हैं
  • infrastructure को पूरी तरह आधुनिक बनाया गया है, और contribution process तथा code quality भी मज़बूत की गई है
  • VVC decoder stabilization, xHE-AAC decoder, MV-HEVC और LC-EVC support सहित प्रमुख audio और video codec क्षेत्रों में भी प्रगति हुई है
  • यह open source multimedia technology के विकास में केंद्रीय भूमिका निभाते हुए लगातार feature improvements और security enhancements जारी रखे हुए है

FFmpeg परिचय

  • FFmpeg एक पूर्ण सामान्य-उद्देश्य multimedia processing toolkit है, जो audio और video को record, convert, stream करने के लिए लचीला और शक्तिशाली solution है
  • ffmpeg -i input.mp4 output.avi जैसे सरल command से video और audio processing की जा सकती है

23 अगस्त 2025, FFmpeg 8.0 "Huffman" रिलीज़

  • FFmpeg 8.0 "Huffman" जारी किया गया है। कई बार की देरी और infrastructure modernization प्रक्रिया के बाद, अब तक का सबसे व्यापक release सामने आया है
  • नई सुविधाओं में APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728 जैसे native decoders का जोड़ना, VVC decoder में IBC, ACT, Palette Mode support का सुदृढ़ीकरण, और Vulkan compute-आधारित FFv1 (encode·decode), ProRes RAW (केवल decode) जैसे codecs शामिल हैं
  • Vulkan-आधारित hardware-accelerated decoding (जैसे VP9, VVC, H264/5) और encoding (AV1, H264/5), विभिन्न नए formats (MCC, G.728, Whip, APV) और filters (colordetect, pad_cuda, scale_d3d11, Whisper आदि) पेश किए गए हैं
  • Vulkan 1.3 पर चलने वाली compute shader-आधारित decoder और encoder families नई जोड़ी गई हैं। यह संरचना अलग special hardware accelerator की आवश्यकता के बिना काम करती है और hwaccel API की तरह ही कार्य करती है। encoder का उपयोग करते समय नया encoder निर्दिष्ट करना होगा, और फिलहाल केवल FFv1 (encode·decode) तथा ProRes RAW (decode) supported हैं। ProRes (दोनों दिशाओं में) और VC-2 (दोनों दिशाओं में) तैयारी में हैं
  • यह संरचना केवल parallel decoding optimized codecs पर लागू की जा सकती है, और भविष्य में अधिक विविध क्षेत्रों में उच्च performance improvement तथा non-linear video editing·lossless recording जैसे नए उपयोग की उम्मीद है
  • project infrastructure भी बड़े पैमाने पर modernize किया गया है। mailing list server को पूरी तरह बदल दिया गया है, और अब code.ffmpeg.org पर Forgejo-आधारित code collaboration supported है
  • users को latest version में upgrade करने की सिफारिश की जाती है

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

1 टिप्पणियां

 
GN⁺ 2025-08-23
Hacker News की राय

  • FFmpeg डेवलपर्स और contributors को धन्यवाद दिया

    • जब भी audio/video automation की ज़रूरत पड़ी, हमेशा FFmpeg का इस्तेमाल किया; ज़्यादातर online video tools भी इसी tool को core engine की तरह या UI wrapper के रूप में इस्तेमाल करते हैं
    • आज यह भी पता चला कि FFmpeg.Wasm प्रोजेक्ट मौजूद है (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • जनवरी 2024 में 1993 की एक animated फिल्म के frames को 15 मिनट के अंतराल पर extract करने, फिर Real-ESRGAN-ncnn-vulkan(https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) का इस्तेमाल करके upscale करने, और नतीजे वाले frames को दोबारा 4K में assemble करने का अनुभव साझा किया
    • यह भी सोचा कि अगर इस workflow में UI जोड़ दिया जाता, तो यह आजकल लोकप्रिय Topaz AI जैसे tool में बदल सकता था
    • upscaled sample image भी साझा की (नमूना छवि)
    • जब सीधे ffmpeg का इस्तेमाल नहीं भी करते, तब भी उसे embed करने वाले tools का अक्सर उपयोग करते हैं
      • हाल ही में पुराने DVD से निकाले गए low-quality anime को k4yt3x/video2x के जरिए upscale किया; install करना आसान था और libffmpeg built-in था
      • encoding के समय FFmpeg जैसे ही arguments इस्तेमाल किए जा सकते थे
      • सही arguments चुनने के लिए ffmpeg से छोटे scenes को कई parameter sets के साथ encode किया, फिर ffmpeg से still images निकालकर तुलना की

  • यह देखकर खुशी हुई कि FFmpeg ने compute shader आधारित video encoder और decoder पेश किए हैं

    • hardware पर व्यापक रूप से supported codecs लगभग H.264, H.265, AV1 ही हैं, इसलिए अच्छा होगा अगर दूसरे codecs को भी platform acceleration मिल सके (भले ही efficiency थोड़ी कम हो, तब भी इसका मतलब है)
    • नया ProRes encoder मौजूदा project में उपयोगी लग रहा है
    • यह बात समझ में आती है कि व्यापक रूप से इस्तेमाल होने वाले सामान्य codecs parallel decoding के लिए उपयुक्त नहीं हैं, इसलिए support मुश्किल है
    • इसमें tens of thousands of threads चाहिए होते हैं, लेकिन frames के बीच और tiles के बीच data dependency होने की वजह से parallelization आसान नहीं है
    • encoder शायद decoder की तुलना में थोड़ा ज्यादा flexible हो सकता है, लेकिन VP9(https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) जैसी चीज़ को compute shader से encode करना चुनौतीपूर्ण काम लगता है

    • video encoder/decoder को compute shader में implement किए जाने की खुशी की बात फिर से साझा की

      • पहले सिर्फ standardized in-silicon hardware interface हुआ करता था, इसलिए जब Vulkan आधारित encoder/decoder के general-purpose होने के बारे में पूछा था तो लोग हँसे थे
      • यह सुधार पुराने hardware पर भी उपलब्ध होना वाकई शानदार है; उम्मीद है इससे नए codecs और overall quality improvements के रास्ते खुलेंगे

    • decoder के हालिया रुझानों को 10 साल से ज़्यादा समय से नहीं देखा, लेकिन सहज रूप से लगता है कि GPU acceleration pixel data में बदलने वाली बाद की processing में काफी मददगार होगा

      • शुरुआती decompression CPU पर हो, फिर decompressed data को GPU पर भेजकर अंतिम conversion work (motion vector apply करना, iDCT आदि) किया जाए, ऐसा लगता है
      • अगर complete frame पहले से GPU texture के रूप में हो, तो display overhead भी कम होगा
      • यह जानने की जिज्ञासा है कि यह अनुमान कितना सही है

    • FFmpeg maintainers की प्रतिभा पर हर बार हैरानी होती है; इतना कठिन काम मुफ्त में करना बहुत बड़ी बात है

    • ये release notes बहुत दिलचस्प हैं

      • पिछले कुछ हफ्तों से WebGPU compute shader में ProRes decoder बनाया, और वह काफी तेज़ चलता है (लगता है Apple शायद अपना hardware acceleration इस्तेमाल करेगा)
      • यह path Android के नए APV codec के लिए भी अच्छी तरह fit बैठ सकता है
      • ProRes bitstream spec SMPTE को submit की गई है, लेकिन ProRes RAW के बारे में जानकारी ढूँढना मुश्किल था
      • software और compute आधारित implementation सामने आना बहुत रोचक लग रहा है; शायद ffmpeg developers ने reverse engineering की है
      • कोड को मोटे तौर पर देखने पर यह सामान्य ProRes से बहुत अलग नहीं लगा
      • ProRes spec document

  • FFmpeg इस्तेमाल करते समय हर बार प्रभावित होना पड़ता है (भले ही manual फिर से देखना पड़े या LLM की मदद लेनी पड़े, यहाँ तक कि जब visual options से command बनाने वाला GUI इस्तेमाल करूँ तब भी ऐसा ही लगता है)

    • अब यह एक अनिवार्य transcoding multitool जैसा बन गया है
    • Vulkan 1.3 आधारित processing को अपनाना अच्छा निर्णय लगता है
    • कल यह भी देखा कि Asahi Linux on Mac भी इसी standard को support करता है

    • FFmpeg arguments को ‘original prompt engineering’ कहना एक मज़ेदार अभिव्यक्ति बताई

    • LLM और FFmpeg, ImageMagick जैसे जटिल command-line tools एक शानदार combination हैं

      • सिर्फ natural language में मनचाहा काम बता दो और वह तुरंत हो जाए — यह लगभग perfect future UI/UX जैसा लगता है
      • उदाहरण के तौर पर एक scenario सोचा: folder की सभी images को किसी खास size में crop करना, saturation adjust करना, TIFF में save करना, video loop में assemble करना, और web के लिए encode करना — सब एक साथ

    • LLMs, FFmpeg के लिए interface के रूप में बेहतरीन काम करते हैं

      • इसे natural language में इस्तेमाल करने में मदद करने वाले कई tools हैं, और अपना script भी साझा किया (https://github.com/jjcm/llmpeg)

  • ffmpeg से जटिल CLI commands बनाने में 50% मेहनत बर्बाद होती है, और बाकी 50% shell escaping से लड़ने में — ऐसा मज़ाकिया लेकिन वास्तविक अनुभव साझा किया

    • खासकर जब video पर text चढ़ाना हो, तब text escaping बहुत मुश्किल लगती है
    • यह जिज्ञासा जताई कि Python में बहुत सारे arguments (filters आदि) के साथ ffmpeg को call करने का कोई perfect तरीका किसी ने खोजा है क्या (r-strings? heredocs? आदि)

  • यह पूछा कि FFmpeg के विभिन्न features को आसानी से संभालने वाला कोई अच्छा GUI frontend है क्या

    • कभी-कभी सिर्फ remux करना होता है, या बस उसी codec वाले video/audio streams को combine करना होता है

    • video combine करना सुनने में आसान लगता है, लेकिन असल में variables और issues काफी होते हैं

      • timebase, start offset, frame crop, FPS differences, B-frames, open GOP जैसी चीज़ों की वजह से कुछ playback environments में समस्या हो सकती है
      • audio में भी sample rate differences जैसी कई variables होती हैं
      • Lossless-Cut प्रोग्राम का ज़िक्र हुआ, और उसकी compatibility check feature उपयोगी बताई गई
      • लेकिन videos को MPEG-TS में convert करके फिर जोड़ना कई समस्याओं से बचने के लिए अच्छा तरीका है, और RAM disk पर इसे तेज़ी से किया जा सकता है
      • उदाहरण के तौर पर इस्तेमाल किए जा सकने वाले ffmpeg command-line sequence भी साझा किए

    • Handbrake यह भूमिका अच्छी तरह निभाता है

      • features के लिहाज़ से पर्याप्त है; थोड़ा पुराना लगता है, लेकिन अब भी उपयोगी है

    • Mac users के लिए ffWorks(https://www.ffworks.net/index.html) की सिफारिश की

      • ज़्यादातर features आसानी से उपलब्ध हैं, और batch processing तथा preset settings का भी support है
      • developer बहुत सक्रिय support देता है, इसलिए यह पसंदीदा apps में से एक है; इसकी क़ीमत समझकर donation भी किया है
      • Handbrake और Losslesscut भी शानदार हैं, लेकिन ffWorks की polish से टक्कर लेने वाला app दूसरे platforms पर शायद नहीं है

    • उनके लिए सबसे अच्छा frontend ChatGPT है

      • natural language में मनचाहा काम बताने पर यह काफी सटीक ffmpeg commands बना देता है

    • Lossless-cut प्रोग्राम देखने की सलाह दी

  • FFmpeg के Changelog को देखने के लिए यह लिंक साझा किया (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • इसे संक्षेप में दिलचस्प खबर बताया

    • यह पूछा कि यह वीडियो व्यंग्य है या गंभीर

  • निजी राय दी कि ffmpeg शायद ssl, zlib, sqlite के बाद चौथी सबसे ज़्यादा इस्तेमाल होने वाली library हो सकती है (इस मान्यता के साथ कि 2025 में video सचमुच हर जगह है)

    • इससे सहमत होना मुश्किल बताया, क्योंकि video processing मुख्य रूप से media प्राप्त करने वाले servers पर ज़रूरी होती है

      • यह भी कहा कि ज़्यादातर phones ffmpeg से video process नहीं करते

    • curl शायद उससे ऊपर हो सकता है, और "SSL" के कई implementations होने की वजह से आँकड़े बिखर जाएँगे

    • NixOS infra के fastly metric logs(https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md) को data source के रूप में सुझाया

    • Qt, libpng, libusb जैसी libraries ffmpeg से अधिक इस्तेमाल होती होंगी, ऐसा सोचा

    • Arch Linux की package statistics(https://pkgstats.archlinux.de/packages) भी देखने लायक बताई

  • Vulkan compute shader implementation खासकर FFv1 और ProRes RAW में शानदार लगती है

    • क्योंकि यह fixed-function hardware decoder को पूरी तरह bypass करती है, इसलिए memory bandwidth पर इसका क्या असर पड़ता है, यह जानने की जिज्ञासा है
    • FFv1 की context-adaptive arithmetic coding मूल रूप से sequential लगती है, इसलिए लगा कि इसे तेज़ करना मुश्किल होगा, लेकिन बहुत बड़ा speed-up मिलना चौंकाने वाला है
    • क्या कई symbols को एक साथ parallelize किया जा रहा है, या slice units में parallelization हो रही है — पारंपरिक रूप से arithmetic coding को GPU पर accelerate करना कठिन रहा है, इसलिए ffmpeg team ने कौन से trade-offs किए, यह जानने की इच्छा है
    • अगर किसी के पास उस implementation की profiling का अनुभव हो, तो entropy decoding stage की occupancy और bandwidth choices के बारे में सुनना अच्छा होगा

  • ffmpeg अनगिनत tools की नींव है

    • आम लोग अक्सर नहीं जानते कि media industry में ffmpeg का योगदान कितना बड़ा है
    • जब भी audio/video automation की ज़रूरत होती है, यही tool सबसे पहले याद आता है