मैंने अल्ट्रा-फास्ट गेम स्ट्रीमिंग वीडियो कोडेक PyroWave खुद डिज़ाइन किया

 (themaister.net)
4 पॉइंट द्वारा GN⁺ 2025-07-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • गेम स्ट्रीमिंग के लिए बेहद कम लेटेंसी एक अनिवार्य शर्त है
  • PyroWave, motion prediction और entropy coding को हटाकर अत्यधिक गति हासिल करता है
  • यह Discrete Wavelet Transform (DWT) आधारित तरीका है, जो पारंपरिक DCT codec से अलग है
  • 32×32 ब्लॉक-स्तरीय parallel processing और तेज rate control implementation के कारण GPU पर encoding/decoding बहुत तेज है
  • quality evaluation में H.264/HEVC/AV1 आदि से तुलना करने पर भी कुछ स्थितियों में पर्याप्त परिणाम दिखते हैं

गेम स्ट्रीमिंग की ultra-low latency आवश्यकता और मौजूदा तरीकों की सीमाएँ

  • हाल के समय में gameplay streaming की मांग बढ़ने के साथ, नेटवर्क के जरिए एक डिवाइस से दूसरे डिवाइस तक real-time transmission महत्वपूर्ण हो गया है
  • DMA, rendering, encoding, transmission, decoding और display output तक हर चरण में जुड़ने वाली लेटेंसी पूरे अनुभव पर बड़ा असर डालती है
  • पारंपरिक समाधान H.264, HEVC, AV1 जैसे GPU-accelerated video codec का उपयोग करना है
  • लेकिन streaming में B-frame जैसे high-compression techniques का उपयोग नहीं किया जा सकता, इसलिए latency और bitrate की पाबंदियाँ काफ़ी कड़ी हो जाती हैं

डिज़ाइन दर्शन: motion prediction और entropy coding को हटाना

motion prediction हटाना – Intra-Only तरीका

  • मौजूदा video codec के motion prediction को हटाकर हर frame को अलग-अलग माना गया है
  • इसका परिणाम यह है कि bitrate बढ़ता है, लेकिन error resilience, सादगी और quality consistency जैसे पहलुओं में फायदे मिलते हैं
  • digital cinema आदि में भी Intra-only तरीके के उपयोग का अनुभव मौजूद है
  • इससे यह इंटरनेट streaming के लिए उपयुक्त नहीं रहता, लेकिन LAN जैसे high-bandwidth environment में अच्छे परिणाम दे सकता है

entropy coding हटाना

  • entropy coding, GPU parallel processing के लिए अनुकूल नहीं है, इसलिए इसे पूरी तरह हटाया गया है
  • जो क्षेत्र अब तक केवल ASIC या विशेष हार्डवेयर तक सीमित था, उसे software approach से साकार किया गया है
  • FFmpeg में मौजूद न रहने वाले ultra-low latency codec क्षेत्र में नई दिशा खोली गई है

Wavelet transform (DWT) का उपयोग करने वाला नया approach

  • पारंपरिक codec के DCT की जगह Discrete Wavelet Transform (DWT) अपनाया गया है
  • wavelet transform, graphics programmer के लिए परिचित mip-map structure जैसा है
  • image को कई band में विभाजित किया जाता है और हर band पर quantization लागू किया जाता है
  • high-frequency band को अधिक मज़बूती से quantize करके visual characteristics का अधिकतम उपयोग किया जाता है
  • यह प्रक्रिया rate control से भी जुड़ी होती है

wavelet-आधारित codec के प्रमुख artifact और सीमाएँ

  • JPEG के blocking artifact की जगह wavelet में मुख्य रूप से blur या ringing effect दिखाई देता है
  • हाल के गेम्स में TAA से आने वाले blur effect के साथ यह मिल जाने के कारण, व्यवहार में यह बहुत बड़ी समस्या न भी हो

हाई-स्पीड bitstream packing और parallelization

  • 32×32 coefficient block को स्वतंत्र रूप से प्रोसेस किया जाता है, ताकि packet loss होने पर प्रभाव केवल स्थानीय blur तक सीमित रहे
  • 8×8, 4×2 sub-block संरचना के जरिए GPU workgroup-स्तर की parallel processing को optimize किया गया है
  • bitplane encoding का उपयोग किया गया है, लेकिन जटिल entropy coding के बिना raw bit data को स्टोर किया जाता है
  • SSBO 8-bit storage जैसी GPU-friendly तकनीकों से memory efficiency और processing speed को अधिकतम किया गया है

सटीक और तेज rate control

  • पारंपरिक entropy coding तरीके से अलग, हर block के लिए छोड़े जाने वाले bit की संख्या को बार-बार मापकर और सहेजकर उपयुक्त ratio adjust किया जाता है
  • global स्तर पर optimal rate-distortion range निकालकर CBR का सख्ती से पालन किया जाता है
  • wavelet-श्रेणी के codec की ताकत मानी जाने वाली bitplane-स्तर early termination को software में भी हासिल किया गया है

वास्तविक प्रदर्शन और दक्षता

  • 1080p 4:2:0 के आधार पर, RX 9070 XT GPU पर 0.13ms में encoding/decoding पूरा हो जाता है
  • DWT, quantization आदि हर processing stage में FP16 optimization का उपयोग कर quality और speed के trade-off को संतुलित किया गया है
  • प्रयोग में यह भी पाया गया कि 4K video के मामले में PCI-e transfer speed से भी GPU पर compress करके भेजना अधिक तेज है
  • dedicated hardware codec से भी अधिकतम 10 गुना से ज़्यादा गति हासिल की गई है

quality evaluation और अन्य codec से तुलना

  • comparison group: FFmpeg के GPU encoder(H.264/HEVC/AV1) में Intra-only, CBR, minimum latency mode
  • PyroWave, 200Mbps, 60fps की स्थिति में देखने पर compression artifact लगभग पहचानना मुश्किल है
  • अलग-अलग game scenes पर VMAF, SSIM, PSNR जैसे objective quality metrics में भी पर्याप्त परिणाम मिले हैं
  • कुछ metric (जैसे VMAF) में PyroWave को थोड़ा उदार स्कोर मिलता है, जबकि PSNR आदि में internal precision का प्रभाव अधिक दिखता है
  • image में blur या low-quality artifact मौजूद हैं, लेकिन आधुनिक game visuals और उपयोग के उद्देश्य को देखते हुए व्यावहारिक उपयोग में यह बड़ी समस्या नहीं है

निष्कर्ष

  • PyroWave, अत्यंत कम लेटेंसी और उच्च गति processing की ज़रूरत वाले local game streaming क्षेत्र में एक नवाचारी विकल्प पेश करता है
  • यह आधुनिक GPU architecture के साथ मिलकर parallel processing और CBR control के लिए विशेष रूप से अनुकूलित है
  • यह एक व्यक्तिगत project है, लेकिन DIY ultra-fast streaming solution के रूप में संतुष्टि का स्तर ऊँचा है

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

1 टिप्पणियां

 
GN⁺ 2025-07-30
Hacker News टिप्पणियाँ

  • BBC द्वारा विकसित VC-2 पर चर्चा है, जो एक intra-only wavelet-आधारित ultra-low-latency codec है। यह codec royalty-free है, और अभी के लिए ffmpeg तथा आधिकारिक BBC repository में केवल CPU-आधारित implementation मौजूद हैं। लेखक अपनी master's thesis के रूप में इसका CUDA-accelerated संस्करण बनाने की योजना रखता है। पिछले साल GSoC में बने Vulkan implementations अभी संतोषजनक नहीं हैं। लोग इस codec को ज़रूर देखें, ऐसी सिफारिश की गई है

    • पूछा गया कि Vulkan implementation क्यों कमज़ोर है, क्या इस पर थोड़ा और विस्तार से बताया जा सकता है। यह स्पष्ट किया गया कि सवाल आलोचना के लिए नहीं, बल्कि genuine जिज्ञासा से पूछा जा रहा है
    • VC-2 और JPEG XS के बीच image quality के अंतर पर व्यावहारिक अनुभव पूछा गया। आम तौर पर सुना है कि JPEG XS बेहतर visual quality देता है, लेकिन वास्तविक उपयोग में इसका अनुभव कैसा है, यह जानने की इच्छा जताई गई

  • यह लेख इस बात का शानदार उदाहरण है कि signal characteristics के हिसाब से distortion tolerance और trade-offs को कैसे ठीक से match किया जाए। भले ही आप codec design न कर रहे हों और सिर्फ चयन कर रहे हों, फिर भी इस प्रक्रिया को अपनाकर अच्छे नतीजे मिल सकते हैं। अगर ultra-low-latency क्षेत्र में रुचि है, तो VSF की वह report उपयोगी है जिसमें कई वैकल्पिक codecs की विशेषताएँ संक्षेप में दी गई हैं(लिंक)

  • मुझे video encoding की लगभग कोई समझ नहीं है, लेकिन मेरा मानना है कि अगर encoder गेम इंजन के साथ थोड़ा भी सहयोग करे, तो videogame streaming में कई व्यावहारिक तरीके आज भी छूट रहे हैं। उदाहरण के लिए, अधिकांश rendering engines में अपने उपयोग के लिए motion prediction buffers पहले से होते हैं, और इन्हें encoding के लिए भी लगभग मुफ्त में इस्तेमाल किया जा सकता है। अफसोस यह है कि शायद ऐसे विचारों को रोकने वाले patents हों, इसलिए व्यवहार में यह मुश्किल हो सकता है

    • यह रेखांकित किया गया कि H.264 के ‘motion vectors’ सिर्फ bit-स्तर की image compression तकनीक हैं, और वे वास्तविक 3D games में इस्तेमाल होने वाले motion vectors जैसे नहीं हैं। 3D games में motion vectors 3D space में objects की position change को दर्शाते हैं, जबकि H.264 में किसी मनमाने पिछले frame से pixel blocks कॉपी करके अंतर को JPEG-जैसे तरीके से encode किया जाता है। इसी block copy की वजह से bandwidth कम होने पर H.264 वीडियो चौकोर टुकड़ों में टूटा हुआ दिखने लगता है
    • 2-frame network latency वाले FPS game का उदाहरण देते हुए कहा गया कि यदि game engine UI और 3D world view को अलग framebuffers में दे, तो client पर mouse input मिलते ही server से आए पिछले frame में सिर्फ world view को पहले से shift किया जा सकता है। VR games पहले से input latency की भरपाई के लिए ऐसा ही करते हैं। यह परफेक्ट नहीं है, लेकिन बड़ा फर्क ला सकता है, और parallax भी depth map का उपयोग करके कुछ हद तक नकली रूप में बनाया जा सकता है
    • sensor-based video encoding की तरह, फोन के accelerometer या digital compass की जानकारी का उपयोग encoding hints देने के लिए किया जा सकता है(लिंक). 2D games के मामले में background और बड़े foreground objects के motion vectors बहुत सटीक दिए जा सकते हैं। overlays, HUD, scoreboards, subtitles जैसे 2D elements को अलग compression scheme से भेजकर pixel sharpness बढ़ाई जा सकती है। HN पर लोग इन विचारों को लेकर इतने संशय में हैं, यह आश्चर्यजनक बताया गया
    • मुझे भी यह बात हमेशा दिलचस्प लगी है। client थोड़ा बहुत compositing खुद संभाल सकता है। उदाहरण के लिए, background और foreground को अलग cadence पर render किया जा सकता है, या HUD के लिए priority के आधार पर अधिक स्पष्ट codec इस्तेमाल किया जा सकता है। Stadia के पास अपने first-party games होने के बावजूद वह साधारण video streaming approach पर टिका रहा, यह हमेशा हैरानी की बात थी। शायद उन्होंने कई प्रयोग किए हों, लेकिन पारंपरिक video codecs की तुलना में पर्याप्त लाभ न मिला हो
    • अगर यह 2D sprite game हो, तो encoder को बहुत सटीक motion vectors आसानी से दिए जा सकते हैं। 3D-rendered games में 3D objects के motion vectors को 2D encoding के अनुरूप बदलना व्यावहारिक रूप से कितना उपयोगी होगा, इस पर भरोसा नहीं है

  • एक सुझाव दिया गया कि LLM(large language model) हर frame के लिए गेम की स्थिति को कुछ वाक्यों में summarize करे और उसे network पर भेजा जाए, फिर receiver-side LLM उस text से frame को पुनर्निर्मित करे। real-time के लिए यह कठिन होगा और नुकसान भी बहुत होगा, लेकिन compression ratio बहुत बड़ा हो सकता है और यह मौजूदा trend के अनुरूप भी है

    • frame 1 का उदाहरण देते हुए कहा गया कि इसे ऐसे बताया जा सकता है: “आप पश्चिमी मैदान में खड़े हैं, और सफेद घर का सामने का दरवाज़ा तख्तों से बंद है। यहाँ एक छोटा mailbox है”
    • यह भी जोड़ा गया कि blockchain के जरिए ऐसे विवरण भेजे जाएँ तो उनका immutable record भी बनाया जा सकता है
    • उम्मीद जताई गई कि शायद कभी फिर वह समय आए जब games सीधे हर उपयोगकर्ता के कंप्यूटर पर चलें
    • ऊपर दिया गया विचार रोचक बताया गया

  • यह codec approach लगभग उसी तरह की है जैसा मैं अपने research project में इस्तेमाल करना चाहता था। संदर्भ के लिए कहा गया कि commercial projects में patent pool की वजह से paid standard JPEG-XS(लिंक1, लिंक2) कभी-कभी अधिक सुरक्षित विकल्प हो सकता है, क्योंकि वह भी ultra-low-latency का दावा करता है

    • JPEG-XS ultra-low-latency में मजबूत है, लेकिन अधिक bandwidth लेता है। हम इसका उपयोग फिल्म/TV post-production में real-time image streaming के लिए कर रहे हैं(उदाहरण लिंक). इसमें IntoPIX CUDA encoder/decoder और SRT low-latency transport का उपयोग होता है। अच्छे network पर कुल latency को 16ms के भीतर रखना पूरी तरह संभव है। data center और शहरी post-production studio के बीच, या देशों के बीच 1GbE links पर भी कई compression ratios के साथ उपयोग के मामले मौजूद हैं
    • यह स्पष्ट किया गया कि patent pool कोई safety net नहीं है। यह ऐसा है जैसे patent bridge पार करने के लिए पैसा देना पड़े, लेकिन उसके बाद कोई और patent समस्या आ जाए तो उसके लिए भी अलग से भुगतान करना पड़े

  • साझा किया गया कि VLC के संस्थापक एक ultra-low-latency streaming protocol पर काम कर रहे हैं, और इसके लिए एक interview(लिंक) तथा demo video(लिंक) भी साझा किए गए

    • इस क्षेत्र के अनुभव के आधार पर ज़ोर देकर कहा गया कि hardware encoders और H.264 की latency वास्तव में बहुत कम हो सकती है। NVENC में यदि extra features जैसे multi-frame prediction, B-frames आदि बंद कर दिए जाएँ, तो encoding लगभग तुरंत हो सकती है। जब तक ऐसे advanced processing algorithms से बचा जाए जिन्हें कई frames hold करने पड़ते हैं, GPU rendering खत्म होने के बाद <10ms में encoding संभव है
    • बताया गया कि linked video इस समय उपलब्ध नहीं है

  • यह देखा गया कि यह CODEC तरीका HTJ2K(High-Throughput JPEG 2000) जैसे algorithms पर आधारित है, और कहा गया कि यदि लेखक यह पढ़ रहे हों तो HTJ2K से इसके अंतर समझाना दिलचस्प होगा

  • समझाया गया कि यदि केवल local network streaming पर ध्यान हो, तो आधुनिक codecs की बहुत-सी विशेषताओं की ज़रूरत नहीं होती। यदि लगभग 100Mbps bandwidth उपलब्ध हो, तो processing को तेज और latency को कम रखा जा सकता है। उदाहरण के तौर पर Microsoft DXT codec का उल्लेख किया गया, जिसमें आधुनिक codecs की लगभग कोई सुविधा नहीं है(ना entropy encoding, ना motion compensation, ना deblocking), लेकिन 4~8x compression और hardware decoding के कारण कुल latency घटाने में यह फायदेमंद हो सकता है। हालांकि यह भी बताया गया कि optimization के बावजूद display स्वयं 30~100ms की अतिरिक्त latency जोड़ सकता है

  • कहा गया कि यह development result वास्तव में शानदार है, और उम्मीद है कि किसी दिन इसे Moonlight या इसी तरह के किसी project में इस्तेमाल किया जाएगा

    • जवाब में कहा गया कि मेरी भी यही सोच है, और अगर समय व कौशल होता तो मैं खुद Moonlight में इस codec का support जोड़ने की कोशिश करता। LAN पर Sunshine/Moonlight से Clair Obscure जैसे games stream करते समय पर्याप्त low latency बहुत ज़रूरी है

  • यह राय उद्धृत की गई कि यह codec अभी इतना niche और specialized है कि competing codecs के साथ तुलना सामग्री मिलना कठिन है, और इसी संदर्भ में H.264/AVC(zero-latency ffmpeg options) तथा JPEG XS के साथ benchmarks देखने की इच्छा जताई गई। ffmpeg command examples और detailed encoding parameters भी साझा किए गए