اسمي "ديل كارتيس"، وأنا رئيس فريق الهندسة المسؤول عن تشغيل الوسائط في Chromium. يتولّى فريقي واجهات برمجة التطبيقات الموجّهة إلى الويب لتشغيل الفيديو، مثل MSE و WebCodecs، والعمليات الداخلية الخاصة بالمنصة والمتعلقة بفك ترميز الصوت والفيديو وتحويله إلى تنسيق قابل للعرض.
في هذه المقالة، سأشرح لك بنية عرض الفيديو في Chromium. على الرغم من أنّ بعض التفاصيل حول قابلية التوسيع قد تكون خاصة بمتصفّح Chromium، تنطبق معظم المفاهيم والتصاميم التي تمت مناقشتها هنا على محرّكات العرض الأخرى وحتى تطبيقات التشغيل الأصلية.
تغيّرت بنية تشغيل Chromium بشكل كبير على مرّ السنين. على الرغم من أنّنا لم نبدأ بفكرة هرم النجاح كما هو موضّح في المشاركة الأولى من هذه السلسلة، followed في النهاية خطوات مشابهة: الموثوقية والأداء ثم قابلية التوسيع.
في البداية، كانت عملية معالجة الفيديوهات بسيطة جدًا، إذ كانت تستخدِم حلقة for لاختيار البرنامج الذي يفك ترميز إطارات الفيديو لإرسالها إلى أداة الدمج. وقد كان هذا النهج موثوقًا به لسنوات، ولكن مع زيادة تعقيد الويب، أدّت الحاجة إلى تحسين الأداء والكفاءة إلى إجراء تغييرات على البنية الأساسية. وقد تطلّبت العديد من التحسينات استخدام عناصر أساسية خاصة بنظام التشغيل، وبالتالي كان علينا أيضًا تحسين البنية لتكون أكثر قابلية للتوسيع من أجل الوصول إلى جميع منصات Chromium.
يمكن تقسيم عملية عرض الفيديو إلى خطوتَين: اختيار المحتوى الذي تريد عرضه وتقديم هذه المعلومات بكفاءة. لتسهيل القراءة، سأتناول عملية العرض الفعّال قبل الخوض في كيفية اختيار Chromium لما يتم عرضه.
بعض المصطلحات والتنسيق
بما أنّ هذه المقالة تركّز على المعالجة، سأتناول فقط بشكلٍ موجز جوانب فك ترميز وفك التشفير في مسار المعالجة.
يتطلب فك التشفير وفك الترميز في عالمنا الحديث الذي يهتم بالأمان قدرًا كبيرًا من الحذر. أدوات تحليل الترميز الثنائي هي بيئات مستهدَفة غنية، ويحتوي تشغيل الوسائط على الكثير من عمليات تحليل الترميز الثنائي. وبالتالي، تكون مشاكل الأمان في برامج تحليل الوسائط شائعة للغاية.
تطبّق Chromium استراتيجية الدفاع المتعدّد للحدّ من خطر حدوث مشاكل أمنية للمستخدمين. من الناحية العملية، يعني ذلك أنّ فك ترميز الوسائط وفك ترميز البرامج يتمان دائمًا في عملية ذات امتيازات منخفضة، في حين يتم فك ترميز الأجهزة في عملية ذات امتيازات كافية للتواصل مع وحدة معالجة الرسومات في النظام.
تُعرف آلية التواصل بين العمليات في Chromium باسم Mojo. لن نتطرق إلى تفاصيل Mojo في هذه المقالة، لأنّه يشكّل حجر أساس في مسار الوسائط القابل للتوسيع في Chromium، ويُعدّ واجهة تجريدية بين العمليات. من المهم معرفة ذلك أثناء الاطّلاع على مسار التشغيل، لأنّه يوضّح عملية التنسيق المعقدة للمكونات التي تتفاعل بين العمليات المختلفة لتلقّي الوسائط، وإزالتها من حزمة الترميز، وفك ترميزها، وعرضها أخيرًا.
عدد كبير جدًا من المقاطع
لفهم قنوات عرض الفيديوهات الحالية، يجب معرفة سبب تميّز الفيديو: معدل نقل البيانات. يستهلك تشغيل الفيديوهات بدقة 3840×2160 (4K) بمعدّل 60 لقطة في الثانية معدّل نقل بيانات بذاكرة يتراوح بين 9 و12 غيغابايت في الثانية. على الرغم من أنّ الأنظمة الحديثة قد تحقّق ذروة في معدل نقل البيانات تبلغ مئات الغيغابايت في الثانية، لا يزال تشغيل الفيديو يمثّل جزءًا كبيرًا من هذا المعدل. بدون الانتباه، يمكن أن يتضاعف إجمالي معدل نقل البيانات بسهولة بسبب عمليات النسخ أو الانتقالات بين ذاكرة وحدة معالجة الرسومات وذاكرة وحدة المعالجة المركزية.
إنّ الهدف من أيّ محرّك تشغيل فيديو حديث يراعي الكفاءة هو تقليل معدل نقل البيانات بين وحدة فك التشفير وخطوة المعالجة النهائية. لهذا السبب، تم فصل عملية عرض الفيديو إلى حد كبير عن مسار العرض الرئيسي في Chromium. على وجه التحديد، من منظور مسار المعالجة الرئيسي للعرض، يُعدّ الفيديو مجرد ثقب بحجم ثابت ودرجة تمويه. يحقّق Chromium ذلك باستخدام مفهوم يُعرف باسم السطوح، حيث يتواصل كل فيديو مباشرةً مع Viz.
نظرًا لانتشار أجهزة الحوسبة الجوّالة، أصبح التركيز بشكل كبير في الجيل الحالي على الأداء والكفاءة. نتيجةً لذلك، أصبحت عملية فك التشفير والعرض مرتبطة ببعضها أكثر من أي وقت مضى على مستوى الأجهزة، ما يؤدي إلى ظهور الفيديو على أنّه ثقب معتم، حتى على نظام التشغيل نفسه. غالبًا ما توفّر برامج الترميز على مستوى النظام الأساسي وحدات تخزين مؤقتة غير شفافة يمرّرها متصفّح Chrome إلى نظام الدمج على مستوى النظام الأساسي في شكل طبقات.
ولكل نظام أساسي شكله الخاص من التراكبات التي تعمل واجهات برمجة التطبيقات لفك ترميز النظام الأساسي معًا. يتضمّن نظام التشغيل Windows Direct Composition وMedia Foundation Transforms، ويحتوي نظام التشغيل macOS على CoreAnimation Layers وVideoToolbox، ويحتوي نظام التشغيل Android على SurfaceView وMediaCodec، ويحتوي نظام التشغيل Linux على VASurfaces وVA-API. تعالج واجهتا OverlayProcessor و mojo::VideoDecoder على التوالي العناصر المجردة في Chromium لهذه المفاهيم.
في بعض الحالات، من الممكن ربط هذه المخازن المؤقتة بذاكرة النظام، ولا تحتاج حتى إلى أن تكون غير شفافة ولا تستهلك أيّ عرض نطاق إلى أن يتم الوصول إليها. ويُطلِق Chrome على هذه المخازن المؤقتة اسم GpuMemoryBuffers. في نظام التشغيل Windows، يتم دعم هذه العناصر باستخدام مخازن ذاكرة DXGI، وعلى نظام التشغيل macOS IOSurfaces، وعلى نظام التشغيل Android AHardwareBuffers، وعلى نظام التشغيل Linux مخازن ذاكرة DMA. على الرغم من أنّ تشغيل الفيديو بشكل عام لا يحتاج إلى هذا الوصول، فإنّ وحدات التخزين المؤقت هذه مهمة لتسجيل الفيديو لضمان الحد الأدنى من معدل نقل البيانات بين جهاز التسجيل وبرامج الترميز النهائية.
بما أنّ وحدة معالجة الرسومات هي المسؤولة غالبًا عن فك الترميز والعرض، يضمن استخدام هذه المخازن المؤقتة غير الشفافة (غالبًا) عدم خروج بيانات الفيديو ذات النطاق الترددي العالي من وحدة معالجة الرسومات. كما ناقشنا سابقًا، إنّ إبقاء البيانات في وحدة معالجة الرسومات مهم جدًا للكفاءة، خاصةً عند استخدام درجات الدقة العالية ومعدّلات عرض اللقطات العالية.
كلما زادت إمكاناتنا للاستفادة من العناصر الأساسية لنظام التشغيل، مثل العناصر التي تظهر على سطح الفيديو وذاكرة التخزين المؤقت لوحدة معالجة الرسومات، يقل معدل نقل البيانات الذي يتم إنفاقه على نقل وحدات بايت الفيديو بشكل غير ضروري. يمكن أن يؤدي الاحتفاظ بكل المحتوى في مكان واحد، بدءًا من فك التشفير ووصولاً إلى العرض، إلى تحقيق كفاءة عالية في استخدام الطاقة. على سبيل المثال، عندما فعّل Chromium ميزة "العناصر التي تظهر على سطح الفيديو" على نظام التشغيل macOS، انخفض استهلاك الطاقة أثناء تشغيل الفيديوهات في وضع ملء الشاشة إلى النصف. على الأنظمة الأساسية الأخرى، مثل Windows و Android و ChromeOS، يمكننا استخدام التراكبات حتى في الحالات التي لا تكون فيها الشاشة في وضع ملء الشاشة، ما يوفر ما يصل إلى% 50 من المساحة في كل مكان تقريبًا.
العرض
بعد أن ناقشنا آليات العرض المثلى، يمكننا الحديث عن كيفية اختيار Chromium لما يجب عرضه. تستخدِم حِزمة تشغيل Chromium بنية مستندة إلى "السحب"، أي أنّ كل مكوّن في الحِزمة يطلب مدخلاته من المكوّن الذي تحته بترتيب هرمي. في أعلى الحزمة، يتم عرض لقطات الصوت والفيديو، ويليه فك التشفير، ثم إزالة الترميز، وأخيراً الإدخال/الإخراج. يُشغِّل كل إطار صوت معروض ساعة تُستخدَم لاختيار لقطات الفيديو لعرضها عند دمجها مع فاصل عرض.
في كل فاصل عرض (كل تحديث للشاشة)، يتم توجيه وحدة عرض الفيديو إلى تقديم إطار فيديو من خلال CompositorFrameSink مُرفق بالعنصر SurfaceLayer المذكور سابقًا. بالنسبة إلى المحتوى الذي يتضمن معدل عرض اللقطات أقل من معدل العرض، يعني ذلك عرض اللقطة نفسها أكثر من مرة، بينما إذا كان معدل عرض اللقطات أكبر من معدل العرض، لن يتم عرض بعض اللقطات مطلقًا.
هناك الكثير من الأمور التي يجب مراعاتها عند مزامنة الصوت والفيديو بطرق ترضي المشاهدين. يمكنك الاطّلاع على Project Butter لمناقشة أطول حول كيفية تحقيق سلاسة الفيديو المثلى في Chromium. ويوضّح هذا القسم كيفية تقسيم عملية عرض الفيديو إلى تسلسلات مثالية تمثّل عدد المرات التي يجب عرض كل لقطة فيها. على سبيل المثال: "لقطة واحدة في كل فاصل عرض ([1]، 60 لقطة في الثانية بمعدّل 60 هرتز)"، "لقطة واحدة في كل فاصلَين ([2]، 30 لقطة في الثانية بمعدّل 60 هرتز)"، أو أنماط أكثر تعقيدًا مثل [2:3:2:3:2] (25 لقطة في الثانية بمعدّل 60 هرتز) تغطي لقطات متعددة وفاصل عرض متعدد وكلما كان معالِج الفيديو أكثر التزامًا بهذا النمط المثالي، زادت احتمالية أن يلاحظ المستخدم سلاسة التشغيل.
على الرغم من أنّ معظم منصات Chromium تُعرِض اللقطات الواحدة تلو الأخرى، لا تفعل ذلك جميعها. تتيح لنا البنية القابلة للتوسيع عرض اللقطات دفعة واحدة أيضًا. يُعدّ التقديم المُجمَّع أسلوبًا لتحسين الأداء يتم من خلاله إبلاغ أداة الدمج على مستوى نظام التشغيل بإطارات متعددة مسبقًا ومعالجة عرضها وفقًا لجدول زمني يقدّمه التطبيق.
هل المستقبل الآن؟
لقد ركّزنا على كيفية استفادة Chromium من الوظائف الأساسية لنظام التشغيل لتقديم أفضل تجربة تشغيل. ماذا عن المواقع الإلكترونية التي تريد تقديم ميزات أكثر من تشغيل الفيديوهات الأساسية؟ هل يمكننا أن نقدّم لهم العناصر الأساسية القوية نفسها التي يستخدمها Chromium نفسه لإطلاق الجيل التالي من محتوى الويب؟
نعتقد أنّ الإجابة هي نعم. قابلية التوسيع هي أساس تفكيرنا في منصة الويب هذه الأيام. لقد عملنا مع مطوّرين ومتصفّحات أخرى لإنشاء تقنيات جديدة، مثل WebGPU و WebCodecs حتى يتمكّن مطوّرو الويب من استخدام العناصر الأساسية نفسها التي يستخدمها Chromium عند التواصل مع نظام التشغيل. توفّر WebGPU إمكانية استخدام مخازن وحدة معالجة الرسومات وتوفّر WebCodecs عناصر أساسية لفك التشفير والترميز على النظام الأساسي متوافقة مع أنظمة التخزين المؤقت للتراكبات ووحدة معالجة الرسومات المذكورة أعلاه.
نهاية البث
شكرًا على القراءة. نأمل أن تكون قد اكتسبت فهمًا أفضل لأنظمة التشغيل الحديثة و كيف يساهم Chromium في توفير مئات الملايين من ساعات المشاهدة كل يوم. إذا كنت تبحث عن مزيد من المراجع حول برامج الترميز والفيديوهات الحديثة على الويب، ننصحك بالاطّلاع على مقالة H.264 is magic (إنّ H.264 سحر) التي كتبها "سيد بالا"، ومقالة How Modern Video Players Work (آلية عمل مشغّلات الفيديو الحديثة) التي كتبتها "إيريكا بيفيس"، ومقالة Packaging award-winning shows with award-winning technology (تقديم عروض حائزة على جوائز باستخدام تكنولوجيا حائزة على جوائز) التي كتبها "سيريل كونكولاتو".
صورة توضيحية واحدة (الصورة الجميلة) من إنشاء "أونا كرافيتس"