मैं हूं डेल कर्टिस, Chromium में मीडिया प्लेबैक की इंजीनियरिंग लीड. मेरी टीम, MSE और WebCodecs जैसे वीडियो प्लेबैक के लिए वेब फ़ेसिंग एपीआई के साथ-साथ, ऑडियो और वीडियो को डिकोड करने, डिकोड करने, और रेंडर करने के लिए इस्तेमाल किए जाने वाले प्लैटफ़ॉर्म के हिसाब से काम करने वाले एपीआई के लिए ज़िम्मेदार है.
इस लेख में, हम आपको Chromium के वीडियो रेंडरिंग आर्किटेक्चर के बारे में जानकारी देंगे. एक्सटेंशन को बढ़ाने से जुड़ी कुछ जानकारी शायद Chromium के लिए है. हालांकि, यहां जिन सिद्धांतों और डिज़ाइन के बारे में बताया गया है वे दूसरे रेंडरिंग इंजन और यहां तक कि नेटिव प्लेबैक ऐप्लिकेशन पर भी लागू होते हैं.
पिछले कुछ सालों में, Chromium के वीडियो चलाने के आर्किटेक्चर में काफ़ी बदलाव हुए हैं. जैसा कि इस सीरीज़ की पहली पोस्ट में बताया गया था कि हमने सफलता के पिरामिड के बारे में शुरुआत नहीं की थी, लेकिन आखिरकार हमने इसी तरह के चरणों का पालन किया: भरोसा, परफ़ॉर्मेंस, और फिर ज़रूरत के हिसाब से विस्तार.
शुरुआत में, वीडियो रेंडर करना काफ़ी आसान था—सिर्फ़ लूप के लिए कंपोज़िटर को भेजने के लिए वीडियो फ़्रेम को डिकोड करने वाला सॉफ़्टवेयर चुनना. कई सालों तक यह भरोसेमंद साबित हुआ था, लेकिन जैसे-जैसे वेब की जटिलता बढ़ाई गई, वैसे-वैसे ज़्यादा परफ़ॉर्मेंस और दक्षता की ज़रूरत ने वास्तुकला में बदलाव किए. कई सुधारों के लिए, ओएस के लिए खास तौर पर बने प्रिमिटिव की ज़रूरत हुई; इसलिए, Chromium के सभी प्लैटफ़ॉर्म तक पहुंचने के लिए हमारे आर्किटेक्चर को भी ज़्यादा बेहतर बनाना पड़ा.
वीडियो रेंडरिंग को दो चरणों में बांटा जा सकता है: यह चुनना कि क्या जानकारी दी जाए और उसे बेहतर तरीके से डिलीवर किया जाए. पढ़ने में आसान बनाने के लिए, हम आपको बेहतर डिलीवरी की जानकारी देने से पहले, बताएंगे कि Chromium क्या डिलीवर करना है.
कुछ शर्तें और लेआउट
इस लेख में रेंडरिंग पर फ़ोकस किया गया है. इसलिए, हम पाइपलाइन के डीमक्सिंग और डिकोडिंग के बारे में सिर्फ़ थोड़ी देर के लिए बात करेंगे.
सुरक्षा को ध्यान में रखकर बनाई गई हमारी आधुनिक दुनिया में, डिकोड करने और डिमक्सिंग करने के लिए बहुत सावधानी की ज़रूरत होती है. बाइनरी पार्सर में ज़रूरत के मुताबिक टारगेट एनवायरमेंट होते हैं. साथ ही, मीडिया प्लेबैक में काफ़ी ज़्यादा बाइनरी पार्सिंग होती है. इसलिए, मीडिया पार्सर में सुरक्षा से जुड़ी समस्याएं बहुत आम हैं.
Chromium अपने उपयोगकर्ताओं को सुरक्षा से जुड़ी समस्याओं के जोखिम को कम करने के लिए, मज़बूत सुरक्षा के उपाय करता है. असल में, इसका मतलब है कि डीमक्सिंग और सॉफ़्टवेयर डिकोड करने की प्रोसेस, खास अधिकार वाली प्रोसेस में ही होती है. जबकि हार्डवेयर डिकोडिंग ऐसी प्रोसेस में होती है जिसमें सिस्टम के जीपीयू से बात करने की ज़रूरत होती है.
Chromium की क्रॉस-प्रोसेस कम्यूनिकेशन तकनीक को Mojo कहा जाता है. हम इस लेख में मोजो के बारे में ज़्यादा जानकारी नहीं देंगे, लेकिन यह प्रोसेस के बीच ऐब्स्ट्रैक्ट लेयर के तौर पर काम करता है. यह Chromium की एक्सटेंसिबल मीडिया पाइपलाइन की बुनियाद है. वीडियो चलाने की प्रोसेस में चलते हुए, इसके बारे में जानकारी रखना ज़रूरी है, क्योंकि यह मीडिया पाने, डिमक्स, डिकोड करने, और आखिर में डिसप्ले के लिए इंटरैक्ट करने वाले क्रॉस-प्रोसेस कॉम्पोनेंट के जटिल ऑर्केस्ट्रेशन को बताता है.
बहुत सारे बिट
आज की वीडियो रेंडरिंग पाइपलाइन को समझने के लिए यह जानना ज़रूरी है कि वीडियो खास क्यों है: बैंडविड्थ. 60 फ़्रेम प्रति सेकंड पर चलने वाला 3840x2160 (4K) रिज़ॉल्यूशन, 9 से 12 गीगाबिट/सेकंड मेमोरी बैंडविड्थ के बीच इस्तेमाल होता है. जबकि आधुनिक सिस्टम में सैकड़ों गीगाबिट प्रति सेकंड में उच्च बैंडविड्थ हो सकता है, फिर भी वीडियो प्लेबैक का एक बड़ा हिस्सा होता है. बिना सावधानी के, जीपीयू और सीपीयू मेमोरी के बीच कॉपी या ट्रिप होने की वजह से कुल बैंडविथ आसानी से गुणा हो सकता है.
दक्षता को ध्यान में रखते हुए किसी भी आधुनिक वीडियो प्लेबैक इंजन का लक्ष्य डीकोडर और अंतिम रेंडरिंग चरण के बीच बैंडविड्थ को कम करना होता है. इस वजह से, वीडियो रेंडरिंग को Chromium की मुख्य रेंडरिंग पाइपलाइन से काफ़ी हद तक अलग किया जाता है. खास तौर पर, हमारी मुख्य रेंडरिंग पाइपलाइन के नज़रिए से, वीडियो की ओपैसिटी के साथ सिर्फ़ एक तय साइज़ का होल है. Chromium इसके लिए, सरफ़ेस का इस्तेमाल करता है—इसमें हर वीडियो सीधे Viz से बात करता है.
मोबाइल कंप्यूटिंग की लोकप्रियता की वजह से, मौजूदा पीढ़ी में ऊर्जा और दक्षता पर बहुत ज़्यादा ध्यान दिया जा रहा है. इसकी वजह से, हार्डवेयर लेवल पर डिकोड और रेंडरिंग करने की प्रोसेस पहले से कहीं ज़्यादा आसान हो जाती है. इस वजह से, वीडियो एक छेद की तरह दिखता है और ओएस के लिए भी, ओएस के लिए ही सही ओपैसिटी का इस्तेमाल होता है! प्लैटफ़ॉर्म लेवल डिकोडर अक्सर सिर्फ़ ऐसे ओपेक बफ़र उपलब्ध कराते हैं जिन्हें Chromium, ओवरले के तौर पर प्लैटफ़ॉर्म लेवल के कंपोज़िटिंग सिस्टम में भेजता है.
हर प्लैटफ़ॉर्म के अपने खुद के ओवरले होते हैं जिनके साथ उनके प्लैटफ़ॉर्म डिकोडिंग एपीआई काम करते हैं. Windows में डायरेक्ट कंपोज़िशन और मीडिया फ़ाउंडेशन ट्रांसफ़ॉर्म, macOS में CoreAnimation लेयर और VideoToolbox, Android में SurfaceView और MediaCodec, और Linux में VASurfaces और VA-API मौजूद हैं. इन कॉन्सेप्ट के लिए, Chromium के ऐब्स्ट्रैक्टेशन OverlayProcessor और mojo::VideoDecoder इंटरफ़ेस से मैनेज किए जाते हैं.
कुछ मामलों में, इन बफ़र के लिए सिस्टम मेमोरी में मैप किया जा सकता है, इसलिए इन्हें ओपेक होने की ज़रूरत नहीं होती और जब तक इन्हें ऐक्सेस नहीं किया जाता, तब तक वे किसी बैंडविड्थ का इस्तेमाल भी नहीं करते. Chromium इन्हें GpuMemoryBuffers कहते हैं. Windows पर, ये macOS पर DXGI बफ़र, IOSurfaces, Android AHardwareBuffers, और Linux डीएमए बफ़र पर काम करते हैं. आम तौर पर, वीडियो चलाने के लिए इस ऐक्सेस की ज़रूरत नहीं होती. हालांकि, वीडियो कैप्चर करने के लिए ये बफ़र ज़रूरी हैं, ताकि कैप्चर किए गए डिवाइस और संभावित एन्कोडर के बीच कम बैंडविड्थ को पक्का किया जा सके.
आम तौर पर जीपीयू, डिकोड करने और दिखाने के लिए ज़िम्मेदार होता है. इसलिए, इन ओपेक बफ़र के इस्तेमाल से यह पक्का होता है कि ज़्यादा बैंडविड्थ वाले वीडियो का डेटा, जीपीयू के बाहर कभी नहीं रहेगा. जैसा कि हमने पहले बताया था, बेहतर परफ़ॉर्मेंस के लिए जीपीयू पर डेटा रखना बहुत ज़रूरी है. खास तौर पर, ज़्यादा रिज़ॉल्यूशन और फ़्रेम रेट पर.
हम ओवरले और जीपीयू बफ़र जैसे ओएस प्रिमिटिव का जितना ज़्यादा फ़ायदा उठा सकते हैं, उतना ही कम बैंडविड्थ, वीडियो बाइट को बिना ज़रूरत के शफ़ल करने में खर्च होता है. डीकोड करने से लेकर रेंडरिंग तक, हर चीज़ को एक जगह पर रखने से बिजली की खपत ज़्यादा हो सकती है. उदाहरण के लिए, जब Chromium ने macOS पर ओवरले चालू किए, तो फ़ुलस्क्रीन पर वीडियो चलाने के दौरान होने वाली बिजली की खपत आधी हो गई! Windows, Android, और ChromeOS जैसे दूसरे प्लैटफ़ॉर्म पर, हम बिना फ़ुल स्क्रीन वाले फ़ोन में भी ओवरले का इस्तेमाल कर सकते हैं. इससे हर जगह 50% तक की बचत हो सकती है.
रेंडर करना
हमने डिलीवरी के सबसे अच्छे तरीकों के बारे में बता दिया है. इसलिए, हम इस बात पर चर्चा कर सकते हैं कि Chromium यह कैसे चुनता है कि क्या डिलीवर करना है. Chromium का प्लेबैक स्टैक, "पुल" आधारित आर्किटेक्चर का इस्तेमाल करता है. इसका मतलब है कि स्टैक का हर कॉम्पोनेंट, हैरारकी के हिसाब से उसके नीचे मौजूद इनपुट का अनुरोध करता है. स्टैक के सबसे ऊपर ऑडियो और वीडियो फ़्रेम की रेंडरिंग दिख रही है. इसके बाद, नीचे दिया गया तरीका डिकोड करना, डीमक्सिंग, और आखिर में I/O है. रेंडर किया गया हर ऑडियो फ़्रेम एक घड़ी को आगे बढ़ा देता है. इसका इस्तेमाल, प्रज़ेंटेशन इंटरवल के साथ जोड़े जाने पर रेंडरिंग के लिए वीडियो फ़्रेम चुनने के लिए किया जाता है.
प्रज़ेंटेशन के हर इंटरवल (डिसप्ले के हर रीफ़्रेश) पर, वीडियो रेंडरर से एक वीडियो फ़्रेम उपलब्ध कराने के लिए कहा जाता है. यह फ़्रेम ऊपर बताए गए SurfaceLayer से अटैच किए गए CompositorFrameSink से जुड़ा होता है. अगर किसी वीडियो का फ़्रेम रेट, डिसप्ले रेट से कम है, तो इसका मतलब है कि एक ही फ़्रेम को एक से ज़्यादा बार दिखाया जा सकता है. वहीं, फ़्रेम रेट, डिसप्ले रेट से ज़्यादा होने पर, कुछ फ़्रेम कभी नहीं दिखाए जाते.
दर्शकों को पसंद आने वाले ऑडियो और वीडियो को सिंक करने के अलावा, और भी बहुत कुछ है. Chromium में वीडियो को एक जैसा दिखाने का तरीका जानने के लिए, प्रोजेक्ट बटर देखें. इस बारे में ज़्यादा जानकारी पाएं. इसमें यह बताया गया है कि वीडियो रेंडरिंग को सही क्रम में कैसे बांटा जा सकता है. इससे यह पता चलता है कि हर फ़्रेम को कितनी बार दिखाया जाना चाहिए. उदाहरण के लिए: "हर डिसप्ले इंटरवल ([1], 60 हर्ट्ज़ में 60 FPS)", "हर दो इंटरवल में 1 फ़्रेम ([2], 60 हर्ट्ज़ में 30 FPS (फ़्रेम प्रति सेकंड))" या [2:3:2:3:2] (60 हर्ट्ज़ में 25 FPS (फ़्रेम प्रति सेकंड) और अलग-अलग फ़्रेम को कवर करते हुए) जैसे ज़्यादा जटिल पैटर्न. अगर वीडियो रेंडरर इस पैटर्न के हिसाब से काम करता है, तो इस बात की संभावना बढ़ जाती है कि वीडियो आसानी से चलेगा.
ज़्यादातर Chromium प्लैटफ़ॉर्म, फ़्रेम के हिसाब से फ़्रेम रेंडर करते हैं. हालांकि, कुछ पर ऐसा नहीं होता. हमारी स्क्रीन एक्सटेंसिबल फ़ॉर्मैट, बैच में रेंडर करने की सुविधा भी देता है. बैच रेंडरिंग, परफ़ॉर्मेंस की एक तकनीक है. इसमें ओएस लेवल कंपोज़िटर को कई फ़्रेम के बारे में पहले ही जानकारी दे दी जाती है. साथ ही, उन्हें ऐप्लिकेशन से तय किए गए समय के शेड्यूल के हिसाब से रिलीज़ किया जाता है.
भविष्य क्या है?
हमने इस बात पर फ़ोकस किया है कि कक्षा में वीडियो चलाने का सबसे अच्छा अनुभव देने के लिए, Chromium, ओएस प्रिमिटिव का इस्तेमाल कैसे करता है. लेकिन उन वेबसाइटों का क्या होगा जो बेसिक वीडियो प्लेबैक से आगे की सुविधाएं देना चाहती हैं? क्या हम उन्हें ऐसे ही बेहतरीन टूल उपलब्ध करा सकते हैं जिनका इस्तेमाल Chromium खुद, वेब कॉन्टेंट की अगली पीढ़ी के लिए करने के लिए करता है?
हमें लगता है कि इसका जवाब हां है! आज के समय में, वेब प्लैटफ़ॉर्म को लेकर हमारी सोच का स्तर पूरी तरह से तैयार है. हम WebGPU और WebCodecs जैसी नई टेक्नोलॉजी बनाने के लिए, दूसरे ब्राउज़र और डेवलपर के साथ काम कर रहे हैं. इससे, वेब डेवलपर भी उन प्रिमिटिव का इस्तेमाल कर सकते हैं जिन्हें Chromium, ओएस से बात करते समय इस्तेमाल करता है. WebGPU, GPU बफ़र के लिए काम करता है. WebCodecs, प्लैटफ़ॉर्म डिकोड करने और कोड में बदलने के लिए इस्तेमाल करता है. यह ऊपर बताए गए ओवरले और जीपीयू बफ़र सिस्टम के साथ काम करता है.
स्ट्रीम खत्म होने का समय
पढ़ने के लिए धन्यवाद! हमें उम्मीद है कि आपको नए प्लेबैक सिस्टम के बारे में बेहतर जानकारी मिलेगी. साथ ही, यह भी पता चल गया होगा कि Chromium हर दिन देखने का कुल समय करोड़ों घंटे कैसे बढ़ाता है. अगर आपको कोडेक और मॉडर्न वेब वीडियो के बारे में और पढ़ना है, तो मेरा सुझाव है कि सिड बाला का H.264 जादुई है, एरिका बीव्स का हामी मॉडर्न वीडियो प्लेयर्स वर्क, और सिरिल कॉनकोलाटो का लिखा, अवार्ड जीतने वाली टेक्नोलॉजी की मदद से अवॉर्ड जीतने वाले शो की पैकेजिंग.
यूना क्रावेट्स का एक इलस्ट्रेशन (जो खूबसूरत है!).