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