كيف يغيّر البث المتعدد المستخدمين سير عمل تحويل الترميز في Jellyfin

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

يحوّل البث متعدد المستخدمين Jellyfin من مسار تشغيل واحد إلى قائمة انتظار مشتركة يعتمد عنق زجاجتها على توافق كل عميل ومعدل البت الخاص به.

قد تبدأ الأسرة خلال دقائق ببث تلفزيوني واحد يعمل بالتشغيل المباشر، وجلسة واحدة على جهاز لوحي مع ترجمة، وجلسة واحدة على هاتف عن بُعد. ولا تستهلك هذه الطلبات الموارد نفسها: فقد يكتفي أحدها بقراءة التخزين، بينما يستهلك آخر الموارد في تضمين الترجمة ضمن تحويل فيديو، وقد يضيف العميل البعيد قيدًا على سرعة الرفع. إن فهم هذا الحمل غير المتوازن أكثر فائدة من مجرد عدّ المستخدمين.

يمكن لطلب مستخدم واحد أن يسلك أربعة مسارات مختلفة

يقارن Jellyfin أولًا حاوية الوسائط، وترميز الفيديو، وترميز الصوت، والترجمة، والدقة، ومعدل البت، بما يبلّغ العميل الطالب عن قدرته على تشغيله. ويحدد هذا الاختبار أحد أوضاع التشغيل المباشر، أو إعادة التغليف، أو تحويل الصوت، أو تحويل الفيديو بالكامل؛ لذلك يمكن لمستخدمين يفتحان العنوان نفسه أن يسببا أعباءً مختلفة جدًا على الخادم.

أما العميل الذي يقبل الملف الأصلي فيحوّل الخادم في الغالب إلى قارئ ملفات، بينما قد يحتاج متصفح غير متوافق إلى مرحلتي فك الترميز وإعادة الترميز. يوضح هذا الشرح العملي عن سلوك التشغيل المباشر سبب إزالة تجنب التحويل قدرًا كبيرًا من المعالجة من المسار.

والنتيجة الملحوظة هي حمل غير متماثل: قد يرتفع عدد التدفقات من دون زيادة مماثلة في استخدام وحدة المعالجة المركزية، إلى أن يتجاوز أحد الطلبات حدًا من حدود التوافق. لذلك فالوحدة الصحيحة ليست «المستخدمين»، بل مزيج الجلسات التي تعمل بالتشغيل المباشر، أو بإعادة التغليف، أو بتحويل الصوت، أو بتحويل الفيديو.

تتنافس التحويلات المتزامنة في مراحل محددة من خط المعالجة

التحويل الكامل عبارة عن سلسلة من قراءة الوسائط، وفك الترميز، والتصفية، وإعادة الترميز، وكتابة المقاطع المؤقتة، وتسليمها. وتصبح التزامنية مهمة عندما تتطلب عدة جلسات المرحلة النادرة نفسها، مثل محرك فيديو عتادي، أو معالج ترجمة يعمل على وحدة المعالجة المركزية، أو ذاكرة تخزين مؤقت للتحويل، أو وصلة شبكة صادرة.

يمكن لتسريع الأجهزة نقل أعمال فك الترميز وإعادة الترميز بعيدًا عن أنوية وحدة المعالجة المركزية العامة، لكنه لا يلغي تكاليف التصفية أو الترجمة أو التخزين أو الشبكة. وتُميّز الأوصاف العملية لـالتحويل المُسرَّع عتاديًا باستمرار بين الاستعانة بوحدة معالجة الرسومات وبين جعل خط المعالجة مجانيًا بالكامل.

عندما تعجز أبطأ مرحلة مشتركة عن إنتاج الوسائط بسرعة تساوي سرعة استهلاكها أثناء التشغيل، تكبر قوائم الانتظار وتستنفد العملاء مخازنهم المؤقتة. ولا يستطيع مكوّن أسرع في موضع آخر التعويض عن ذلك: فوجود سعة إضافية في وحدة المعالجة المركزية لا يعالج تشبع سرعة الرفع، كما أن وجود نطاق ترددي إضافي لا يعالج تضمين الترجمة برمجيًا.

يغيّر التحكم مفتوح المصدر طريقة التخطيط للسعة

يعرض Jellyfin قرار التشغيل ويستخدم التحويل القائم على FFmpeg من دون وضع تسريع الأجهزة خلف فئة اشتراك. وهذا يجعل سير العمل قابلًا للفحص والتهيئة، لكنه يحمّل المشغّل أيضًا مسؤولية مواءمة التعريفات، والوصول إلى الأجهزة، وبرامج الترميز، وسلوك العملاء.

تظهر قيمة هذا التحكم عندما يشغّل خادم منزلي عدة تطبيقات ويستطيع مالكه تحديد أعباء العمل التي تتشارك وحدة معالجة الرسومات أو أوقات تشغيل المهام في الخلفية. ويوفر خط أنابيب حدود العميل الأساس لجلسة واحدة؛ أما التخطيط لعدة مستخدمين فيضيف التنافس بين خطوط الأنابيب تلك. وينسجم حد التشغيل نفسه مع سلوك التشغيل المباشر عند النظر في مسار التسليم الكامل.

لذلك يغيّر المصدر المفتوح الجهة القادرة على ضبط النظام، لا التكلفة المادية للتحويل. فزيادة عناصر التحكم لا تنشئ سعة نقل إضافية تلقائيًا، وقد يؤدي مسار تسريع غير صحيح إلى الرجوع بصمت إلى المعالجة عبر وحدة المعالجة المركزية، بينما تظل الواجهة تبدو متاحة.

-15% OFF

متى يتوقف عدد المستخدمين عن التنبؤ بالأداء؟

يُعد عدد المستخدمين مؤشرًا ضعيفًا عندما تعمل معظم العملاء بالتشغيل المباشر؛ فقد تستهلك جلستان صعبتان بتقنية HDR والترجمة موارد أكثر من عدد كبير من جلسات 1080p المتوافقة. كما يتوقف هذا الاستنتاج عن الانطباق عندما يكون التخزين أو الرفع مشبعًا بالفعل، لأن سعة التحويل لم تعد حينها المتغير المسيطر.

يجب فحص التزامن عن بُعد مقابل سعة الرفع المتاحة فعليًا، لا مقابل سرعة التنزيل المعلنة. ويوضح مثال لتخطيط النطاق الترددي يستند إلى قسمة سرعة الرفع على معدل بت التدفق العلاقة المحدِّدة بوضوح، مع أن معدلات بت المصدر المتغيرة على شكل دفعات ما تزال تتطلب هامشًا احتياطيًا. كما يدعم تقرير ميداني منفصل استخدام مؤشرات التحويل على مستوى الجلسة بدل افتراض أن العرض الظاهر يحدد عنق الزجاجة.

أنشئ سجلًا من أربعة أسطر لكل جلسة قبل تغيير العتاد: دوّن وضع التشغيل، ومعدل بت المصدر والتسليم، وطريقة عرض الترجمة، ومحرك وحدة المعالجة المركزية/وحدة معالجة الرسومات النشط لكل عميل متزامن. ولا تُجرِ ترقية إلا عندما تحدد الاختبارات المتكررة المرحلة المشبعة نفسها؛ وإلا فغيّر العميل غير المتوافق أو إصدار الوسائط أو هدف النطاق الترددي أولًا.

مركز التكنولوجيا والذكاء الاصطناعي

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.