لطالما راودني الفضول لمعرفة مدى توافق برامج الترميز المختلفة مع مشاركة الشاشة عبر WebRTC. لذلك، قررتُ أن أكتشف ذلك بنفسي من خلال اختبار أكثرها شيوعًا: VP8، وVP9، وH.264، وAV1.
للتأكد من دقة النتائج، أجريتُ اختباراتٍ على مجموعة متنوعة من أنواع المحتوى وظروف الشبكة. لم أعتمد فقط على الانطباعات البصرية، بل استخدمتُ مقارناتٍ إطارية، وحسبتُ نسبة ذروة الإشارة إلى الضوضاء (PSNR)، وجمعتُ إحصاءات WebRTC مُفصّلة للحصول على رؤية واضحة ومستندة إلى البيانات.
وللمضي قدمًا، قمتُ بإنشاء إضافة مخصصة لمتصفح كروم تتتبع استخدام وحدة المعالجة المركزية أثناء الترميز وفك التشفير. وقد أتاح لي ذلك رؤيةً واضحةً لكيفية تأثير كل برنامج ترميز على أداء النظام - فالجودة ممتازة، ولكن ليس إذا كان جهاز الكمبيوتر الخاص بك يعمل بكامل طاقته في محاولة مواكبة الأداء.
لقد راجعتُ مقاييس رئيسية مثل معدل البت، ومعدل الإطارات، والدقة، والتكميم (QP)، ونسبة الإشارة إلى الضوضاء (PSNR)، وحمل وحدة المعالجة المركزية. بناءً على كل ذلك، توصلتُ إلى بعض التوصيات العملية لمساعدة أي شخص يحاول تحسين مشاركة الشاشة عبر WebRTC لحالات استخدامه الخاصة.
حول التجربة
لماذا مشاركة الشاشة ليست بهذه البساطة كما تبدو
إذا سبق لك مشاركة شاشتك أثناء مكالمة فيديو ولاحظت انخفاض الجودة أو تقطع الفيديو، فأنت لست وحدك. الحفاظ على مشاركة الشاشة واضحة وسلسة أصعب مما يبدو.
المشكلة؟ تكمن المشكلة في التنوع. بعض المحتوى يكون ثابتًا، مثل عرض شرائح أو مستند. وفي أحيان أخرى، تُشارك فيديوهات عالية الحركة. تتطلب هذه الأنواع المختلفة من المحتوى قدرات مختلفة تمامًا من برنامج الترميز. على سبيل المثال، يستهلك الفيديو سريع الحركة قدرًا هائلًا من عرض النطاق الترددي، بينما الصور الثابتة أكثر حساسية لتأثيرات الضغط التي قد تجعلها تبدو ضبابية أو متكتلة.
أضف إلى ذلك مشاكل الإنترنت الواقعية، مثل فقدان الحزم أو انخفاض عرض النطاق الترددي، وستزداد الأمور تعقيدًا. لذلك، يُعد اختيار برنامج الترميز المناسب - وضبط آلية عمله - أمرًا بالغ الأهمية لضمان مشاركة شاشة عالية الجودة وسريعة الاستجابة.
هناك بالفعل الكثير من الأبحاث حول أداء برامج ترميز الفيديو في سيناريوهات البث العام. لكن لمشاركة الشاشة خصائصها الخاصة. فالأمر لا يقتصر على مشاهدة الفيديو فحسب، بل يشمل التفاعل الفوري، وأنواع المحتوى متنوعة. هذا يعني أن الأبحاث المعتادة لا تنطبق دائمًا.
ما الذي أعتزم القيام به
أردتُ التعمق أكثر في حالة الاستخدام هذه. كان هدفي هو معرفة أداء برامج الترميز المختلفة عند مشاركة الشاشة، خاصةً في ظل القيود الواقعية، مثل تنوع أنواع المحتوى وظروف الشبكة غير المتوقعة.
لتحقيق ذلك، صممتُ طريقةً لتقييم جودة مشاركة الشاشة بأقصى دقة ممكنة - ليس فقط بناءً على مظهرها، بل استنادًا إلى مقاييس وبيانات دقيقة. وخلال هذه العملية، تعلمتُ الكثير عن برامج الترميز الأنسب، وكيفية ضبطها بدقة لتحسين الأداء في تطبيقات الوقت الفعلي.
سرعان ما اتضح أمر واحد: أداء مشاركة الشاشة يعتمد في الواقع على ما تشاركه. يختلف أداء الفيديو السريع تمامًا عن أداء مستند ثابت أو تصفح بطيء لصفحة ويب.
لضمان عدالة وتناسق النتائج، حرصتُ على أن يُجرى كل اختبار بنفس الشروط - نفس الدقة، نفس نقطة البداية، ونفس المدة. بهذه الطريقة، كنتُ واثقًا من أن النتائج تتعلق بأداء برنامج الترميز، وليس بمتغير عرضي.
لقد قمت بإنشاء حالتي اختبار مختلفتين لمحاكاة مواقف مشاركة الشاشة في الحياة الواقعية:
- فيديو عالي الحركة - كان هذا مقطعًا حقيقيًا لراكبي دراجات نارية ينطلقون بسرعة عبر غابة. حركة سريعة، ومناظر طبيعية مفصلة، وبيئة بصرية متغيرة باستمرار - مثالية لتجاوز حدود الضغط.
- نصّ يتم تمريره تلقائيًا - أنشأتُ صفحة HTML بسيطة تحتوي على نصوص وصور، ثم استخدمتُ جافا سكريبت لتمريرها بسرعة ثابتة. يُحاكي هذا استخدامًا شائعًا كمشاركة مستند أو قراءة صفحة ويب.
لقد أعطاني هذان النوعان من المحتوى مزيجًا جيدًا لاختبار كيفية تعامل كل برنامج ترميز مع التحديات المختلفة - من مواكبة الحركة إلى الحفاظ على الوضوح في المشاهد الأكثر ثباتًا.
كيف أقوم بإعداد كل شيء
لاختبار برامج الترميز بشكل صحيح، كنتُ بحاجة إلى إعداد قوي يلتقط كل شيء - سواءً ما يُرسل أو ما يُستقبل. بدأتُ باستخدام أداة تُسمى webrtc-sandbox (يمكنكم التعرّف على هذه الأداة وغيرها الكثير في منشوري السابق: " تعلّم WebRTC عمليًا: أفضل الأدوات والعروض التوضيحية ")، وهي أداة رائعة للتلاعب بالمكونات الداخلية لـ WebRTC. انتهيتُ بتعديلها بشكل كبير لتحسين مشاركة الشاشة والتأكد من إمكانية تسجيل كلٍّ من تدفقات الفيديو الصادرة والواردة. وفّر لي كل تشغيل تجريبي ملفي فيديو - أحدهما لما يُرسل والآخر لما يُستقبل - استخدمتهما لاحقًا للتحليل جنبًا إلى جنب.
لكنني لم أتوقف عند الفيديو، بل أردتُ أيضًا تتبُّع ما يحدث في الخفاء. لذلك، استخرجتُ إحصائيات WebRTC مُفصّلة مباشرةً من مُتصفّح Chrome. أتاحت لي هذه الإحصائيات فرصةً للاطلاع على أداء كل برنامج ترميز وسلوك الشبكة المُحاكاة خلال كل اختبار.
كان استخدام وحدة المعالجة المركزية (CPU) أحد أهم العوامل المؤثرة، وقد اتضح أن ذلك كان صعبًا بعض الشيء. لا تسمح النسخة العادية من كروم للمكونات الإضافية بمراقبة استهلاك وحدة المعالجة المركزية لكل علامة تبويب على حدة، لذلك استخدمتُ إصدارًا تطويريًا من المتصفح وكتبتُ مكونًا إضافيًا خاصًا بي للتغلب على ذلك.
ركزتُ تحديدًا على قياس استخدام وحدة المعالجة المركزية (CPU) من علامة التبويب التي كانت تُرسل أو تستقبل مشاركة الشاشة. بهذه الطريقة، استبعدتُ مهام العرض غير ذات الصلة من أجزاء أخرى من المتصفح. ولأن الإرسال والاستقبال حدثا في علامة التبويب نفسها، كانت الأرقام التي حصلتُ عليها عرضًا مُجمّعًا - ولكنه لا يزال قريبًا جدًا مما تراه في حالة استخدام واقعية. (ملاحظة: عادةً ما يكون تأثير التشفير على وحدة المعالجة المركزية أكبر من تأثير فك التشفير).
جمع البيانات: بعد 157 اختبارًا لاحقًا...
بعد أن أصبح الإعداد جاهزًا، حان وقت إجراء التجارب الفعلية - وقد أجريتُ العديد منها. كررتُ الاختبارات على نفس الجهاز مرارًا وتكرارًا، مستخدمًا ظروف شبكة وإعدادات ترميز مختلفة لاختبار مدى ثبات النتائج. في المجمل، جمعتُ 157 نقطة بيانات ، مع التأكد من تمثيل جميع ظروف الاختبار بشكل جيد.
لقد منحتني هذه البيانات مجموعة بيانات متينة للعمل عليها، وسمح لي بإجراء تحليل متعمق لكيفية عمل مشاركة الشاشة في WebRTC في سيناريوهات مختلفة. إليك ما كنت أختبره تحديدًا:
- نوع الفيديو :
لقد استخدمت نوعين من محتوى مشاركة الشاشة لتعكس حالات الاستخدام الشائعة:- فيديو عالي الحركة - لقطات من العالم الحقيقي مع الكثير من التغييرات في البكسل في كل إطار.
- نص يتم تمريره تلقائيًا - صور ثابتة في الغالب، ولكن مع تغيير موضع البكسلات أثناء تمرير النص.
- الترميز :
لقد قمت باختبار برامج الترميز الأربعة الأكثر شيوعًا لمشاركة الشاشة:- AV1
- H.264
- نائب الرئيس 8
- نائب الرئيس 9
- عرض النطاق الترددي للشبكة :
نظرًا لأن النطاق الترددي يلعب دورًا كبيرًا في جودة الفيديو (خاصةً في مكالمات الفيديو)، فقد قمت بمحاكاة مجموعة متنوعة من ظروف الشبكة لمعرفة مدى قدرة كل برنامج ترميز على التعامل مع النطاق الترددي الضيق أو المتقلب.
من خلال مزج هذه المتغيرات ومطابقتها بطريقة منظمة، تمكنت من محاكاة سيناريوهات مشاركة الشاشة في العالم الحقيقي - النوع الذي قد تواجهه في مكالمة فيديو، أو أثناء عرض توضيحي مباشر، أو في جلسة تعاونية عن بعد.
إصلاح الأخطاء: كيف جعلت الاختبارات أكثر موثوقية
كما هو الحال في معظم التجارب، لم تسر التجارب الأولى بسلاسة كما كنت آمل. ظهرت مشكلتان رئيسيتان على الفور:
- بدء يدوي = توقيت غير دقيق. في البداية، كنت أبدأ مشاركة الشاشة يدويًا - بالنقر على زرّ حرفيًا لبدء التشغيل. المشكلة؟ كان من شبه المستحيل مزامنة بداية التسجيل مع بداية محتوى الفيديو. هذا يعني أن كل اختبار تشغيل كان له توقيت مختلف قليلاً، مما أفسد المقارنات.
- الإرسال مقابل الاستلام = عدم تزامن. حتى مع التوقيت المناسب، فإن للفيديو المباشر خصائصه الخاصة. فبسبب التشفير وفك التشفير وتأخيرات الشبكة، لم تتطابق التدفقات المرسلة والمستلمة تمامًا. وهذا جعل مقارنة جودة كل إطار على حدة شبه مستحيلة.
ولحل هذه المشكلات، قمت بإجراء بعض التحسينات الرئيسية:
- المزامنة البرمجية : بدلًا من بدء كل شيء يدويًا، كتبتُ بعض الشيفرة البرمجية لمزامنة بداية الفيديو أو النص المتحرك مع عملية التسجيل. بهذه الطريقة، بدأ كل اختبار تشغيل في نفس اللحظة تمامًا من كلا الطرفين - وهكذا حُلّت المشكلة.
- مطابقة إطارات رمز الاستجابة السريعة : لمعالجة مشكلة عدم التزامن، أضفتُ رمز استجابة سريعة صغيرًا إلى الفيديو المُشارك. كان هذا الرمز الصغير بمثابة ختم زمني، حيث مكّنني من مطابقة الإطارات بين التدفقات المُرسَلة والمُستقبَلة بدقة. وفجأةً، أصبح تحليل الإطار بإطار ممكنًا (وبدقة أكبر بكثير).
كان هناك أمرٌ آخر كان عليّ مراعاته: معدل البت المتكيف في WebRTC . من ميزات WebRTC الرائعة ضبط جودة الفيديو تلقائيًا بناءً على النطاق الترددي المتاح. لكن هذا الضبط لا يحدث فورًا، بل يستغرق بضع ثوانٍ للاستقرار. لذلك، أضفتُ مهلة قصيرة قبل بدء التسجيل الفعلي. هذا أعطى النظام وقتًا للاستقرار عند معدل البت المستهدف، وبالتالي ستعكس النتائج الجودة الفعلية التي ستحصل عليها بعد استقرار الأداء.
لقد أدت هذه التغييرات إلى جعل التجربة أكثر موثوقية وأعطتني الثقة في أن البيانات التي كنت أجمعها تعكس بالفعل كيفية سلوك مشاركة الشاشة في العالم الحقيقي.
ما قمت بقياسه (ولماذا هذا مهم)
لقد قمت بجمع الكثير من البيانات أثناء هذه الاختبارات، ولكن للحفاظ على الأمور واضحة وسهلة المقارنة، ركزت على عدد قليل من المقاييس الأساسية التي تحكي قصة كيفية أداء كل برنامج ترميز في سيناريو مشاركة الشاشة.
وهذا ما نظرت إليه:
- معدل الإطارات
هذا يُخبرني بعدد الإطارات في الثانية التي تم ترميزها وإرسالها واستقبالها بالفعل. إنه مؤشر جيد على سلاسة بث الفيديو - فكلما ارتفع معدل الإطارات، زادت سلاسة التجربة. - دقة
تعتمد الدقة على مدى الحفاظ على التفاصيل البصرية. تتبعتُ عدد البكسلات لكل إطار في كل مرحلة (إرسال واستقبال) لمعرفة ما إذا كانت برامج الترميز تحافظ على جودة الصورة أم تتراجع لتوفير النطاق الترددي. - جودة الفيديو
لقد استخدمت هنا عددًا من المقاييس الرئيسية:- معامل التكميم (QP) - معامل التكميم المنخفض يعني عمومًا جودة أفضل.
- نسبة الإشارة إلى الضوضاء القصوى (PSNR) - تُعطي هذه النسبة دلالة رقمية على مدى اختلاف الفيديو المُستقبَل عن الفيديو الأصلي. كلما كانت أعلى، كان ذلك أفضل.
- استخدام وحدة المعالجة المركزية
أداء برامج الترميز لا يقتصر على ما تراه، بل يتعلق أيضًا بما يفعله جهازك خلف الكواليس. قمتُ بقياس مقدار طاقة وحدة المعالجة المركزية المستخدمة للترميز وفك التشفير خلال كل اختبار، مع معايرة هذه الطاقة بمرور الوقت، لمعرفة أي برامج الترميز خفيفة الوزن وأيها تستهلك موارد الجهاز.
باستخدام هذه المقاييس، تمكنتُ من مقارنة برامج الترميز ليس فقط من حيث الجودة، بل أيضًا من حيث السلاسة والكفاءة ومتطلباتها. ساعد ذلك في كشف مواطن تميز كل برنامج ترميز - ومواطن ضعفه - في ظروف مشاركة الشاشة الواقعية.
وأخيرا وصلنا إلى النتائج
ما مدى أهمية نوع المحتوى؟ أكثر بكثير مما تظن
من أكثر النتائج المدهشة التي توصلتُ إليها من تجاربي مدى تأثير نوع المحتوى الذي تُشاركه على أداء مشاركة الشاشة، سواءً من حيث جودة الفيديو أو استهلاك الموارد. وقد انطبق هذا على جميع برامج الترميز التي اختبرتها.
الفكرة وراء ذلك بسيطة للغاية: عندما يتغير عدد أكبر من البكسلات من إطار لآخر (كما في فيديو سريع الحركة)، يضطر النظام إلى العمل بجهد أكبر. هذا يعني الحاجة إلى نطاق ترددي أكبر، وضرورة بذل وحدة المعالجة المركزية (CPU) جهدًا أكبر لمواكبة هذا التغير.
لنأخذ AV1 كمثال. عندما استخدمته لمشاركة شاشة بدقة 1.5 ميجابكسل، اختلف عرض النطاق الترددي المطلوب اختلافًا كبيرًا تبعًا لما تتم مشاركته. في إحدى الحالات، حيث كان المحتوى أكثر ديناميكية، اضطر AV1 إلى دفع بيانات أكبر بكثير للحفاظ على سلاسة البث. وقد وثّقتُ ذلك في الرسم البياني التالي ، الذي يوضح مدى تأثير تعقيد المحتوى بشكل كبير على استخدام عرض النطاق الترددي.
ولكن الأمر لا يتعلق فقط بالنطاق الترددي - بل إن جهازك يشعر به أيضًا.
يوضح الرسم البياني التالي كيفية تغير استخدام وحدة المعالجة المركزية بناءً على المحتوى المُشارك. وباستخدام AV1 كمثال، يمكنك أن ترى بوضوح أن الرسومات الأكثر تعقيدًا تتطلب طاقة أكبر بكثير من وحدة المعالجة المركزية للحفاظ على نفس معدل الإطارات والدقة.
هذا ليس مجرد أمر يخص AV1. تعتمد جميع برامج الترميز على نفس المبادئ الأساسية لترميز الفيديو وفك ترميزه، لذا يُتوقع منها أداءً متشابهًا - لكن البيانات تُظهر نتيجة مختلفة. لا يتغير حمل وحدة المعالجة المركزية (CPU) بتغير المحتوى فحسب، بل يتغير أيضًا بناءً على برنامج الترميز المستخدم.
لتسهيل المقارنة، أعددتُ الجدول التالي ، الذي يوضح مقدار استهلاك كل برنامج ترميز لوحدة المعالجة المركزية (CPU) عند بث فيديو بدقة 1.5 ميجابكسل بمعدل حوالي 24 إطارًا في الثانية - وهو إعداد نموذجي لمشاركة الشاشة بسلاسة. تُبرز النتائج بعض الاختلافات الرئيسية في كفاءة كل برنامج ترميز عند استخدام أجهزتك.
برنامج الترميز/وحدة المعالجة المركزية | AV1 | H264 | نائب الرئيس 8 | نائب الرئيس 9 |
|---|---|---|---|---|
حركة | 287% | 213% | 270% | 364% |
نص | 175% | 130% | 179% | 198% |
لذا، إذا كنت تُنشئ أو تُحسّن شيئًا يعتمد على مشاركة الشاشة عبر WebRTC، فالخلاصة واضحة: المحتوى واختيارك لبرنامج الترميز مهمان للغاية.
مواجهة الترميز: معدلات الإطارات، وحمل وحدة المعالجة المركزية، والتكاليف الحقيقية للجودة
عند مشاركة الشاشة، أول ما يُلاحظ هو سلاسة (أو عدم سلاسة) الفيديو. وهنا يأتي دور معدل الإطارات . إذا كنت تُشارك محتوى عالي الحركة، مثل تشغيل الفيديو أو الرسوم المتحركة، فإن معدل الإطارات الأعلى ضروري لتجنب البث المتقطع الذي يصعب مشاهدته.
في هذا الجزء من التجربة، ركزتُ على أداء معدل الإطارات عبر برامج ترميز مختلفة، مع الحفاظ على ثبات جميع العوامل الأخرى: نفس الدقة (حوالي 1.5 ميجابكسل) ونفس المحتوى لكل اختبار. استخدمتُ إعداد contentHint WebRTC لضمان ثبات الدقة في جميع الاختبارات.
في الصورة التالية ، يمكنك رؤية كيفية تعامل برامج الترميز المختلفة مع المحتوى عالي الحركة مع زيادة عرض النطاق الترددي. على المحور السيني: معدل البت (ميغابت في الثانية). على المحور الصادي: معدل الإطارات (إطارات في الثانية).
وهنا ما برز:
- لقد تقدمت تقنيتا H.264 و AV1 عندما وصل النطاق الترددي إلى 2 ميجابايت في الثانية أو أكثر، حيث قدما كلاهما أكثر من 20 إطارًا في الثانية - وهي تجربة سلسة يمكن تحقيقها حتى مع اتصال 3G لائق.
- لم يُوفق VP8 و VP9 في تحقيق هذا الأداء. فقد ظلا يعملان بنصف معدل الإطارات تقريبًا في نفس الظروف، وكانا بحاجة إلى سرعة 4 ميجابت في الثانية أو أكثر ليشعرا بالكفاءة - وهو أمر غير واقعي دائمًا على الشبكات منخفضة الأداء.
ثم انتقلت إلى محتوى الحركة المنخفضة - صفحة نصية تتحرك ببطء - لمعرفة كيفية أداء برامج الترميز عندما لا يتغير الكثير بين الإطارات.
ليس من المستغرب أن يكون أداء كلٍّ من H.264 و AV1 أفضل في هذا السيناريو، حيث تفوّق AV1 . يعود الفضل في ذلك إلى ميزة " نسخ الكتلة الداخلية" ، التي تُمكّن AV1 من تخطي إعادة ترميز أجزاء الشاشة التي لم تتغير. إنها فعّالة للغاية لمشاركة الشاشة الثابتة أو شبه الثابتة.
في الرسم البياني التالي ، يمكنك رؤية مدى كفاءة AV1 في التعامل مع مواقف الحركة المنخفضة هذه، مع الحفاظ على استخدام النطاق الترددي منخفضًا بشكل مثير للإعجاب مع الحفاظ على جودة بصرية عالية.
ولكن هناك مقايضة.
قد يوفر AV1 صورًا وضغطًا أفضل، ولكنه يستهلك أيضًا قدرًا أكبر من وحدة المعالجة المركزية . توضح الصورة التالية ذلك بوضوح: يزداد استخدام وحدة المعالجة المركزية في AV1 باستمرار مع زيادة معدل البت، متفوقًا على H.264 بفارق كبير. يتميز H.264 هنا بميزة كبيرة بفضل تسريع الأجهزة واسع النطاق، مما يحافظ على انخفاض حمل وحدة المعالجة المركزية واستقراره.
من المثير للاهتمام أن VP9 يستهلك وحدة معالجة مركزية أكبر من AV1، متبعًا نفس النهج، ولكن بذروات أعلى. يعتمد كلٌّ من VP9 وAV1 على خوارزميات معقدة لتقديم جودة عالية، ولكن هذا يأتي بثمن: فهما يُثقلان كاهل معالجك.
حدث مفاجأة عند إعادة النظر في محتوى الحركة المنخفضة . هذه المرة، بدت VP8 وVP9 فعالتين للغاية - حيث استخدمتا وحدة معالجة مركزية أقل من AV1، كما هو موضح في الرسم البياني التالي .
على الرغم من تصميم AV1 مع مراعاة مشاركة الشاشة، إلا أنه لا يزال يستهلك معظم وحدة المعالجة المركزية. لماذا؟ كل هذه التحسينات التي تُساعده على ضغط مقاطع الفيديو عالية الحركة تُضيف أيضًا تكلفة إضافية - حتى مع عدم وجود الكثير من الأحداث على الشاشة.
ما هو السبب الرئيسي وراء ذلك؟ لا يزال AV1 يفتقر إلى دعم واسع النطاق للترميز عبر الأجهزة . مع أن فك التشفير سهل نسبيًا، إلا أن الترميز لا يزال يُجرى في الغالب برمجيًا - وهي مهمة تتطلب الكثير من وحدة المعالجة المركزية، خاصةً في سيناريوهات الوقت الفعلي مثل مشاركة الشاشة حيث يحدث كلٌّ من الترميز وفك التشفير باستمرار.
هنا تكمن الصعوبة في الأجهزة المحمولة مثل أجهزة الكمبيوتر المحمولة والأجهزة اللوحية. فبدون تسريع الأجهزة، قد تستنزف برامج الترميز مثل AV1 الطاقة وتستهلك الموارد بسرعة، وهو أمر غير مثالي للاستخدام أثناء التنقل. وإلى أن يصبح دعم الأجهزة الأفضل أكثر شيوعًا، فإن ميزات AV1 المتقدمة تأتي بتكلفة أداء ملحوظة.
برامج الترميز والدقة: ماذا يحدث عندما تعطي الأولوية لمعدل الإطارات؟
حتى الآن، جاءت النتائج التي شاركتها من اختبارات حافظت على ثبات الدقة. عند انخفاض عرض النطاق الترددي، كان النظام يستجيب بخفض معدل الإطارات - وهو أمر منطقي لأشياء مثل المحتوى الثابت أو النصوص. ولكن ماذا لو كان الهدف هو الحفاظ على سلاسة الحركة ، حتى لو كان ذلك يعني التضحية بالدقة؟
لاستكشاف هذا، أجريتُ مجموعة جديدة من التجارب حيث تم ضبط WebRTC لإعطاء الأولوية لمعدل الإطارات . تم ذلك باستخدام إعداد contentHint في WebRTC، والذي يتيح لك تحديد ما هو الأهم - دقة عالية أم حركة سلسة.
كنتُ أهدف إلى الحفاظ على معدل إطارات ثابت عند 30 إطارًا في الثانية ، وهو المعدل المعروف على نطاق واسع بأنه الأمثل لمشاهدة سلسة ومريحة. كان تحقيق هذا المعدل الثابت صعبًا - فالبث التكيفي يعني وجود بعض التقلبات دائمًا - لكن النتائج قدمت رؤية قيّمة حول كيفية تعامل كل برنامج ترميز مع هذا التوازن.
للمساعدة في تحليل هذا السلوك، قدمت مقياسًا جديدًا:
عدد البكسلات المرسلة في الثانية = معدل الإطارات × الدقة
يُعطي هذا صورةً أكثر شمولاً من مجرد النظر إلى عدد الإطارات في الثانية أو الدقة فقط. فهو يُظهر مقدار البيانات المرئية التي يُرسلها برنامج الترميز فعلياً في الثانية الواحدة في ظل ظروف مُختلفة.
في مجال الفيديو عالي الحركة، تصدّر AV1 مجددًا وبفارق ملحوظ. حتى عند معدلات بت منخفضة، نجح في نقل عدد بكسلات أكبر بكثير في الثانية مقارنةً بأي برنامج ترميز آخر. يُظهر هذا بوضوح مدى كفاءة AV1 في التعامل مع المحتوى الديناميكي عند ضغط النظام للحفاظ على معدل إطارات مرتفع. يُرجى الاطلاع على الرسم البياني التالي :
عندما انتقلتُ إلى محتوى منخفض الحركة - مثل صفحة ويب ذات نص متحرك - أصبح مستوى الأداء أكثر تكافؤًا. أصبح أداء جميع برامج الترميز أكثر تناسقًا كما هو موضح في الصورة التالية . مع ذلك، حافظ AV1 على تفوقه ، خاصةً عند معدلات البت الأعلى. ساعدته تحسينات الضغط في الحفاظ على إنتاجية عالية دون زيادة كبيرة في استهلاك الموارد.
ماذا يعني كل هذا عمليا؟
حسنًا، إذا كانت حالة الاستخدام الخاصة بك تتضمن صورًا ديناميكية عالية الحركة - مثل مقاطع الفيديو التوضيحية أو الرسوم المتحركة المباشرة أو بث الألعاب - فإن إعطاء الأولوية لمعدل الإطارات يمكن أن يحدث فرقًا كبيرًا ، ويثبت AV1 أنه قادر بشكل خاص في هذه البيئة.
حتى مع المحتوى ذي الحركة البطيئة، يُظهر AV1 أداءً قويًا. مع أن الفرق قد يكون أصغر، إلا أنه يُرسل باستمرار بيانات بصرية أكثر، ما يعني جودة أفضل بنفس النطاق الترددي أو أقل، وذلك بفضل استراتيجيات الضغط المتقدمة.
في كلتا الحالتين، أثبت مقياس "عدد البكسلات المرسلة في الثانية" فائدته في فهم كيفية موازنة برامج الترميز بين الدقة ومعدل الإطارات عند محدودية النطاق الترددي. ويعزز أداء AV1 في هذه الظروف من مكانته كأفضل خيار، شريطة أن يتمكن نظامك من تلبية متطلبات وحدة المعالجة المركزية الإضافية.
ما مدى نقاء الصورة؟ لنتحدث عن PSNR
إلى جانب معدلات الإطارات والدقة واستهلاك وحدة المعالجة المركزية، هناك عامل مهم آخر في عملية مشاركة الشاشة: ما مدى تقارب الصورة المستلمة مع الصورة الأصلية؟ وهنا يأتي دور نسبة الإشارة إلى الضوضاء القصوى (PSNR) .
نسبة الإشارة إلى الضوضاء (PSNR) هي مقياس شائع الاستخدام لقياس جودة الفيديو المضغوط. فهي تُبيّن مقدار التشوه - أو "الضوضاء" - المُدخل أثناء الترميز. تُقاس بالديسيبل (dB) ، والقاعدة العامة بسيطة: كلما زادت، كان ذلك أفضل . تعني نسبة الإشارة إلى الضوضاء (PSNR) العالية أن الصورة تبدو مطابقة تقريبًا للأصل؛ بينما تعني الدرجة المنخفضة وجود تدهور أكثر وضوحًا.
لوضع هذا في سياقه، اختبرت قيم PSNR عبر برامج الترميز في حالتين مختلفتين: الأولى حيث تكون الدقة هي الأولوية، والثانية حيث يكون معدل الإطارات هو الأولوية. استخدم كلا الاختبارين نفس محتوى الفيديو عالي الحركة للحفاظ على الاتساق.
في هذا الإعداد، حيث يكون الوضوح هو المحور (حتى لو انتهى الفيديو ببعض التقطع)، كان أداء H.264 ممتازًا ، حيث قدم صورًا واضحة مع أدنى حد من التشوه. إنه خيار قوي عندما لا تكون السلاسة بالغة الأهمية.
عندما يتحول الهدف إلى الحفاظ على سلاسة الحركة، يتفوق AV1 ، خاصةً عند معدلات البت العالية. فهو يحافظ على جودة الصورة حتى أثناء الضغط الشديد للوصول إلى أهداف معدل الإطارات.
رغم أن اختلافات نسبة الإشارة إلى الضوضاء (PSNR) بين برامج الترميز ليست دائمًا كبيرة، إلا أنها تُبرز التنازلات التي تُقدم عليها عند اختيار برنامج ترميز. يُعطي بعضها الأولوية للوضوح، بينما يسعى البعض الآخر إلى سلاسة الحركة - وحسب حالة استخدامك، قد يكون أحدهما أنسب من الآخر.
ثم أجريت نفس الاختبارات مرة أخرى، هذه المرة باستخدام محتوى نصي متحرك - وهو شيء يؤكد حقًا أهمية الدقة والوضوح.
عند إعطاء الأولوية للحركة، تبدو قيم PSNR لجميع برامج الترميز متشابهة إلى حد كبير. لا يتغير المحتوى كثيرًا، لذا فإن اختلافات استراتيجية الضغط لا تؤثر كثيرًا على جودة الصورة الإجمالية.
هنا تبدأ الأمور بالإثارة. مع إعطاء الأولوية للدقة، يتفوق AV1 على برامج الترميز الأخرى بفارق كبير ، خاصةً عند معدلات البت العالية. أداؤه هنا استثنائي.
لماذا؟ يتضمن AV1 تحسينات خاصة للتعامل مع المحتوى الثابت والمتكرر، مثل النصوص. هذه التحسينات تُمكّنه من الحفاظ على دقة أعلى للصور ، وتجنب العيوب، وضغط البيانات بكفاءة أكبر. هذا يجعل AV1 خيارًا رائعًا لحالات استخدام مثل مشاركة المستندات أو شرح التعليمات البرمجية - أي مكان تكون فيه التفاصيل الواضحة والقابلة للقراءة مهمة حقًا .
باختصار، يُساعد معدل الإشارة إلى الضوضاء (PSNR) على إبراز بُعد دقيق ولكنه مهم في جودة مشاركة الشاشة. سواءً أكنت تُعطي الأولوية للحركة أم للحدة، فإن فهم كيفية عمل برامج الترميز تحت قيود مختلفة يُمكّنك من اختيار البرنامج الأنسب.
ما هي مشكلة جودة الطباعة؟ فهم الضغط مقابل الجودة
هناك عامل مهم آخر في جودة مشاركة الشاشة، وهو ما يُسمى بمعامل التكميم ( QP) . إذا تساءلت يومًا عمّا يتحكم في مقدار التفاصيل المفقودة أثناء الضغط، فهذا هو.
بمصطلحات بسيطة، يخبر QP المشفر بمدى قوة ضغط الفيديو .
- إن QP المنخفض يعني ضغطًا أقل وجودة صورة أفضل.
- إن ارتفاع QP يعني المزيد من الضغط - مما يوفر النطاق الترددي، ولكن يمكن أن يجعل الفيديو يبدو أسوأ.
بينما يُعطينا PSNR نتيجةً - مقدار جودة الصورة المُحافظ عليها - يُخبرنا QP بما كان المُشفِّر يهدف إليه . لذا، راجعتُ كليهما.
في هذه الدراسة:
- تم سحب قيم QP من مقاييس WebRTC القياسية.
- تم قياس PSNR بعد ذلك عن طريق مقارنة كل إطار أصلي بإصداره المستلم.
هنا بدأت الأمور تزداد إثارة. سجّل AV1 أفضل نتائج PSNR ، ما يعني أنه حافظ على جودة الصورة بشكل أفضل، ولكنه سجّل أيضًا قيم QP أعلى بأربع مرات من برامج الترميز الأخرى. قد يبدو هذا متناقضًا للوهلة الأولى.
لكن المشكلة تكمن في أن كل برنامج ترميز يُعرّف ويُعالج QP بشكل مختلف ، لذا لا يُمكن مقارنة القيم مباشرةً. فقيمة QP ٥٠ في برنامج ترميز لا تعني بالضرورة نفس مستوى الضغط المُستخدم في برنامج ترميز آخر.
مع ذلك، تُشير اتجاهات جودة الصورة إلى أمرٍ مفيد. لاحظتُ في جميع برامج الترميز أنه مع زيادة عرض النطاق الترددي، ينخفض جودة الصورة . وهذا منطقي، فمع زيادة عرض النطاق الترددي، تستطيع برامج الترميز تقليل الضغط وتحسين جودة الصورة.
لذلك، على الرغم من أننا لا نستطيع ترتيب أرقام QP جنبًا إلى جنب عبر برامج الترميز، فإنها لا تزال تُظهر كيف يقوم كل برنامج ترميز بضبط الضغط بشكل ديناميكي استنادًا إلى ظروف الشبكة المتاحة.
خلاصة القول: جودة الإشارة (QP) ليست درجة جودة، بل هي إعداد . لكن تتبع كيفية تغيرها مع عرض النطاق الترددي يُعطي فكرةً مفيدةً عن عمل المُرمِّز خلف الكواليس. وعند دمجها مع نسبة الإشارة إلى الضوضاء (PSNR)، تُعطي صورةً أكثر اكتمالاً عن سلوك المُرمِّز.
الأفكار النهائية: ماذا يعني كل هذا بالنسبة لمشاركة الشاشة عبر WebRTC
بعد التعمق في كيفية أداء WebRTC تحت الغطاء، هناك شيء واحد واضح: ليست كل برامج الترميز متساوية - والاختيار الأفضل يعتمد حقًا على أولوياتك وبيئتك.
وفيما يلي أهم النقاط المستفادة من تجاربي:
AV1: أفضل جودة وأعلى تكلفة
قدّم AV1 باستمرار أفضل جودة بصرية ، سواءً كنت أشارك مقاطع فيديو سريعة الحركة أو نصوصًا بطيئة التمرير. ضغطه وتحسيناته المتقدمة تجعله فعالًا للغاية، ولكن هذا له ثمن. AV1 يستهلك الكثير من موارد المعالج ، ولأن دعم الأجهزة لا يزال في طور اللحاق بالركب، فهو ليس مثاليًا للأجهزة منخفضة الطاقة أو الأجهزة المحمولة حتى الآن .
H.264: الجهاز الشامل القوي
إذا كنت تبحث عن توازن بين الأداء والكفاءة ، فلا يزال H.264 خيارًا ممتازًا. فهو مدعوم على نطاق واسع، ومُسرّع بالعتاد على معظم المنصات، ويُؤدي وظيفته بكفاءة في جميع السيناريوهات تقريبًا، خاصةً عندما تكون موارد النظام أو عمر البطارية مصدر قلق.
المحتوى أهم مما تعتقد
يؤثر نوع المحتوى الذي تشاركه تأثيرًا كبيرًا على الأداء. يتطلب الفيديو عالي الحركة استهلاكًا أكبر بكثير من وحدة المعالجة المركزية (CPU) ونطاق ترددي أكبر بكثير من المحتوى الثابت كالمستندات أو النصوص. اختيار برنامج الترميز المناسب والإعدادات المناسبة لمحتواك يُحدث فرقًا كبيرًا في الجودة واستهلاك الموارد.
استخدام وحدة المعالجة المركزية ليس مجرد حاشية سفلية
بفضل إضافة كروم مخصصة صممتها، تمكنتُ من قياس استخدام وحدة المعالجة المركزية بدقة أثناء مشاركة الشاشة. أظهرت النتائج اختلافات كبيرة في متطلبات كل برنامج ترميز ، وهو أمر بالغ الأهمية على الأجهزة المحمولة أو في البيئات الحساسة للطاقة.
ما التالي؟ إلى أين يمكن أن يتجه هذا البحث؟
فتحت هذه التجربة الباب أمام خطواتٍ قادمةٍ مثيرة. وهنا أعتقد أن الأعمال المستقبلية قد تُحدث تأثيرًا أكبر:
الاختبار على الأجهزة المحمولة
حتى الآن، أُجريت جميع الاختبارات على أجهزة الكمبيوتر المكتبية، ولكن مشاركة الشاشة شائعة بنفس القدر (إن لم تكن أكثر) على الهواتف والأجهزة اللوحية . سيُعطي اختبار أداء هذه الترميزات على الأجهزة المحمولة صورةً أكثر شمولاً، خاصةً من حيث الاستجابة واستهلاك الطاقة.
كفاءة الطاقة
بالحديث عن الطاقة، لا تستهلك برامج الترميز طاقة المعالج فحسب، بل تستهلك أيضًا عمر البطارية . ينبغي أن تستكشف الأبحاث المستقبلية برامج الترميز الأكثر كفاءة في استهلاك الطاقة ، خاصةً لجلسات مشاركة الشاشة الطويلة على الأجهزة المحمولة.
ضبط الترميز المدعوم بالذكاء الاصطناعي
تخيّل لو أن WebRTC قادر على ضبط إعدادات الترميز تلقائيًا بناءً على المحتوى الحالي وسرعة الشبكة. يُمكن للذكاء الاصطناعي أن يُتيح ذلك ، مُحققًا التوازن المثالي بين الجودة والأداء بشكل ديناميكي وفي الوقت الفعلي.
اختتام الأمر
اختيار برامج الترميز ليس مجرد قرار فني، بل يؤثر بشكل مباشر على جودة تجربة مشاركة الشاشة وسلاسة أدائها واستهلاك الموارد . سواء كنت تُنشئ أداة لمؤتمرات الفيديو، أو منصة تعاون، أو تُحسّن سير عملك، فإن فهم كيفية عمل هذه البرامج في ظروف مختلفة يُساعدك على اتخاذ قرارات أكثر ذكاءً وفعالية.
مع استمرار تطور تقنية WebRTC، ستتطور الأدوات والتقنيات المتعلقة بها. آمل أن تساعد هذه المناقشة المعمقة الآخرين على فهم ما يجري خلف الكواليس بشكل أفضل، وكيفية تحقيق أقصى استفادة من مجموعة أدوات مشاركة الشاشة الخاصة بهم.
هل تريد استكشاف البيانات بنفسك؟
إذا كنت مهتمًا بالبحث بشكل أعمق في النتائج أو إجراء تحليلك الخاص، فقد قمت بإتاحة مجموعة البيانات الكاملة من هذه الدراسة هنا:
تنزيل مجموعة البيانات على Kaggle
يتضمن مقاييس أولية لمعدل الإطارات، والدقة، ونسبة الإشارة إلى الضوضاء (PSNR)، ونسبة جودة الصورة (QP)، واستخدام وحدة المعالجة المركزية (CPU)، وغيرها - جميعها مُرتبة حسب برنامج الترميز، ونوع المحتوى، وحالة النطاق الترددي. لا تتردد في استخدامه لتجاربك الخاصة، أو لإجراء مقاييس الأداء، أو لمجرد استكشاف كيفية عمل WebRTC في سيناريوهات مختلفة.
