ابدأ بثلاثة عناصر تحكم، بهذا الترتيب: خفّض دقة التقاط الكاميرا، قلّل عدد مقاطع الفيديو البعيدة التي يتلقاها كل عميل، ثمّ شد قيود معدل البت الخاصة ببرنامج الترميز. هذا الترتيب مهم لأن الدقة وعدد التدفقات المستلمة عادةً ما يكون لهما التأثير الأوضح على استهلاك النطاق الترددي، بينما قد تؤدي قيود معدل البت المرتفعة إلى تشويش الحركة دون حل مشكلة فقدان الحزم أو عدم استقرار شبكة Wi-Fi.
توثق Jitsi عناصر التحكم في الفيديو من جانب العميل في مرجع التكوين الحالي . اعتبارًا من 6 أكتوبر 2026، تشير الوثائق إلى أن constraintsالكائن مضبوط افتراضيًا على ارتفاع التقاط مثالي بدقة 720 بكسل، channelLastNويكون غير محدود افتراضيًا مع -1، startLastNويمكنه بدء مؤتمر بعدد أقل من مقاطع الفيديو المستلمة قبل أن يقوم المستخدم بتغيير إعداد إدارة جودة الفيديو.
بالنسبة لفرع مكتب ذي موارد محدودة، أو نقطة اتصال لاسلكية متنقلة، أو وصلة ريفية، أو شبكة واي فاي مكتظة، غالبًا ما يكون الهدف العملي المبدئي هو دقة 360 بكسل بدلًا من 720 بكسل. توفر صفحة متطلبات البنية التحتية لـ Jitsi أرقامًا تقريبية للتخطيط تبلغ حوالي 200 كيلوبت/ثانية لدقة 180 بكسل، و500 كيلوبت/ثانية لدقة 360 بكسل، و2.5 ميجابت/ثانية لدقة 720 بكسل، مع التنبيه إلى أن المتطلبات الفعلية تختلف باختلاف العديد من العوامل. تعامل مع هذه الأرقام كمرجع لتخطيط السعة، وليست معدلات مضمونة لكل مستخدم. راجع دليل متطلبات Jitsi Meet الرسمي .
عرض توضيحي للاجتماع يُظهر خيار جودة 360 بكسل لاتصال محدود؛ يمكن أن يختلف تخطيط التحكم الدقيق حسب إصدار Jitsi Meet.
عادةً، نعم. يؤدي خفض ارتفاع الالتقاط إلى تقليل عدد البكسلات التي يجب على المُشفّر معالجتها قبل بدء تخصيص معدل البت. يفصل مرجع تكوين Jitsi الحالي بين فيديو W3C والقيمة constraintsالمفضلة القديمة resolution، ويشير إلى أن القيود تُضبط افتراضيًا على ارتفاع التقاط مثالي بدقة 720p.
بالنسبة لموقع تكون فيه استقرارية الفيديو أهم من دقة تفاصيل الوجه، اختبر سقف التقاط 360 بكسل على النحو التالي:
constraints: {
video: {
height: {
ideal: 360,
max: 360,
min: 180
}
}
},هذا مثال على ملف تعريف، وليس الإعداد الافتراضي لـ Jitsi. يطلب من المتصفح تفضيل دقة 360p وعدم تجاوزها، مع السماح لمسار الالتقاط بالانخفاض إلى 180p عند الحاجة. تجنب افتراض أن هذا min: 180يضمن بثًا ثابتًا بدقة 180p في ظل ازدحام شديد؛ إذ لا يزال بإمكان WebRTC الاستجابة لعرض النطاق الترددي المتاح، وحمل وحدة المعالجة المركزية، وفقدان الحزم، وإمكانيات الجهاز، وسلوك برنامج الترميز.
مثال على تكوين Jitsi ذاتي الاستضافة مع حد أقصى لالتقاط 360 بكسل وقيم LastN متحفظة.
إذا تلقى أحد المشاركين ثمانية مقاطع فيديو عن بُعد في وقت واحد، فإن خفض دقة الكاميرا المحلية فقط لا يحل مشكلة التنزيل بالكامل. يوفر Jitsi عناصر تحكم LastN لتحديد عدد مقاطع الفيديو عن بُعد التي يتم إرسالها إلى المشارك.
القيمة الافتراضية الموثقة channelLastNهي -1، أي غير محدودة. يسمح الخيار الموثق startLastNببدء المؤتمر بقيمة LastN أصغر، وتشير Jitsi إلى أنه channelLastNيتم استخدامه عندما يغير المستخدم مستوى الجودة باستخدام شريط تمرير إدارة جودة الفيديو.
تتمثل نقطة البداية الحذرة لبيئة ذات نطاق ترددي محدود فيما يلي:
channelLastN: 2,
startLastN: 1,في هذا المثال، يبدأ المشارك بتلقي فيديو واحد عن بُعد، ويمكنه الانتقال إلى حالة يتلقى فيها ما يصل إلى فيديوهين عن بُعد، وذلك بحسب جودة التطبيق. لا تُعتبر هذه 2توصيات 1عامة. ففي قاعة دراسية يشاهد فيها الطلاب مُقدّمًا واحدًا في الغالب، يمكن استخدام عدد أقل من المشاركين (LastN) مقارنةً بجلسة مراجعة تصميم تضم أربعة أشخاص، حيث يجب أن يظل الجميع مرئيين.
يُظهر قالب Jitsi الحالي config.jsومرجع التكوين maxBitratesVideoمستويات خاصة بكل برنامج ترميز. في التكوين الرئيسي للمشروع الذي تم عرضه في 6 أكتوبر 2026، يستخدم AV1 معدل بت 100,000 بت/ثانية للمستوى المنخفض، و300,000 بت/ثانية للمستوى القياسي، و1,000,000 بت/ثانية للمستوى العالي؛ بينما يستخدم VP9 معدلات 100,000 و300,000 و1,200,000 بت/ثانية؛ ويستخدم كل من VP8 وH.264 معدلات 200,000 و500,000 و1,500,000 بت/ثانية لنفس المستويات. يمكنك التحقق من القالب المباشر في مستودع Jitsi Meet الرسمي على GitHub .
هذه القيم هي قيم افتراضية أو نموذجية من المصدر، وليست ضمانًا بأن كل مكالمة ستنقل البيانات بهذه المعدلات بالضبط. يؤثر كل من تقدير عرض النطاق الترددي لتقنية WebRTC، والتحكم في الازدحام، وبرنامج الترميز المُختار، وسلوك الترميز المتزامن أو القابل للتوسع، وتعقيد المشهد، ومعدل الإطارات، وقيود المُستقبِل، على ما يتم إرساله فعليًا.
قلل من الحد الأقصى للدقة عندما تكون ميزانية شبكتك معروفة ويكون استقرار الفيديو أهم من التفاصيل. على سبيل المثال، يمكنك اختبار ملف تعريف VP8 مثل:
videoQuality: {
vp8: {
maxBitratesVideo: {
low: 150000,
standard: 300000,
high: 800000
}
}
},هذه الأرقام مُصنّفة عمدًا كمثال للاختبار، وليست القيم الافتراضية لـ Jitsi. وهي منطقية فقط إذا تم التفاوض على بروتوكول VP8 فعليًا على نقاط النهاية التي تهمك. إذا كانت أجهزة سطح المكتب لديك تُفضّل AV1 أو VP9، فلن يُؤدي تعديل عنصر VP8 فقط إلى النتيجة المرجوة.
مثال على حدود معدل نقل البيانات لبروتوكول VP8 لشبكة محدودة؛ اختبرها على أجهزتك الخاصة وأنماط المكالمات قبل طرحها.
ليس تلقائيًا. تُتيح إصدارات Jitsi الحديثة ترتيب تفضيلات الترميز وسلالم معدل بت افتراضية مختلفة لترميزات AV1 وVP9 وVP8 وH.264. قد يكون AV1 وVP9 فعالين، لكن اختيار الترميز يؤثر أيضًا على استهلاك وحدة المعالجة المركزية، ودعم الأجهزة، ودعم المتصفحات، وميزات قابلية التوسع. قد يُؤدي استخدام حاسوب محمول ضعيف الإمكانيات يُواجه صعوبة في ترميز برنامج ترميز أكثر تعقيدًا إلى اجتماع أقل جودة حتى لو كان برنامج الترميز فعالًا نظريًا.
من الأفضل اتباع قاعدة تشغيلية أكثر أمانًا، وهي الإبقاء على إعدادات تفضيل الترميز الحالية في Jitsi ما لم تكن لديك قياسات تُظهر وجود مشكلة. في حال تغيير ترتيب الترميز، يُرجى إجراء الاختبار على مجموعات Chrome وFirefox وSafari وAndroid وiOS الفعلية المستخدمة في مؤسستك. لا تستنتج أداء الترميز من متصفح سطح مكتب واحد.
تختلف جودة مشاركة الشاشة عن جودة فيديو الكاميرا. فالنصوص والشرائح تستفيد من دقة عرض واضحة، بينما تتطلب الحركة السلسة معدل إطارات أعلى في الثانية. تُوثّق Jitsi هذا الأمر desktopSharingFrameRateوتُدرج حاليًا معدلًا افتراضيًا قدره 5 إطارات في الثانية { min: 5, max: 5 }. في الاجتماعات التي تتضمن عروضًا تقديمية كثيرة، يُمكن ضبط معدل مشاركة الشاشة على حوالي 5 إطارات في الثانية للحفاظ على وضوح النص دون استهلاك عرض النطاق الترددي لحركة غير ضرورية.
إذا شارك المستخدمون رسومًا متحركة أو تدويرًا لملفات التصميم بمساعدة الحاسوب أو مقاطع فيديو، فقد يبدو معدل 5 إطارات في الثانية بطيئًا جدًا. في هذه الحالة، ارفع معدل الإطارات بحذر ولاحظ ما إذا كانت الدقة أو فقدان الحزم يتأثران سلبًا. يُعدّ دليل تكوين Jitsi الرسمي المرجع الصحيح لأسماء الخيارات المدعومة حاليًا.
لا تعتمد فقط على مظهر الصورة. تحقق من سلوك الشبكة. توفر واجهة برمجة تطبيقات IFrame الخاصة بـ Jitsi معلوماتٍ getConnectionStats()تُتيح لك معرفة جودة الاتصال المحلي، وعرض النطاق الترددي المتاح، ومعدل نقل البيانات للتحميل والتنزيل، ومعدل نقل بيانات الصوت والفيديو، وفقدان الحزم، ومعلومات الترميز، ومعدل الإطارات، والإطارات التي تم فك تشفيرها، والدقة، وتفاصيل النقل. راجع مرجع وظائف واجهة برمجة تطبيقات IFrame الرسمي .
بالنسبة لعمليات النشر المدمجة، يمكن أن يبدو الفحص البسيط على النحو التالي:
api.getConnectionStats().then(stats => {
console.log(stats.bitrate);
console.log(stats.packetLoss);
console.log(stats.resolution);
console.log(stats.connectionQuality);
});أجرِ نفس نمط الاجتماع قبل وبعد إجراء التغييرات. يتضمن الاختبار الفعال ثلاثة شروط على الأقل: عرض نطاق ترددي عادي للمكتب، وعرض نطاق ترددي محدود عمدًا، ومكالمة واقعية متعددة المشاركين. سجّل ما إذا كان الصوت لا يزال واضحًا، أو الفيديو يتجمد، أو يزداد فقدان الحزم، أو تنخفض دقة المشاركين، أو يصبح استخدام وحدة المعالجة المركزية مفرطًا.
عرض توضيحي لإحصائيات الاتصال يوضح نوع الدقة ومعدل الإطارات ومعدل البت وقيم الفقد التي تتم مقارنتها أثناء التحقق.
| سيناريو | بدء هدف الالتقاط | نقطة انطلاق LastN | نهج معدل البت |
|---|---|---|---|
| مقدم واحد، ومشاهدون كثر | 360 بكسل | 1 | احتفظ بالإعدادات الافتراضية أولاً؛ ولا تقم بتحديد الحد الأقصى إلا بعد القياس. |
| فريق صغير يتصل عبر شبكة واي فاي ضعيفة | 360 بكسل | 2-3 | اختبر الحد الأدنى من الحد القياسي/الحد الأقصى من الحد الأقصى لبرنامج الترميز المتفاوض عليه |
| اتصال الهاتف المحمول ضعيف للغاية | 180 بكسل - 360 بكسل | 1 | فضّل استمرارية الصوت على تفاصيل الفيديو |
| مشاركة الشريحة أو المستند | الكاميرا بدقة 360 بكسل | 1-2 | حافظ على معدل إطارات مشاركة الشاشة منخفضًا إلا إذا كانت الحركة ضرورية |
هذه ملفات تعريف أولية، وليست قيماً مثالية مضمونة. يعتمد التكوين الصحيح على عدم التماثل بين الإرسال والاستقبال، وعدد المشاركين، ومحتوى الكاميرا، وبرنامج الترميز المُختار، ووحدة المعالجة المركزية للجهاز الطرفي، والجودة التي يتوقعها المستخدمون.
في تثبيت حزمة Debian، يحتفظ Jitsi عادةً بملف إعدادات الويب للمضيف الافتراضي في /etc/jitsi/meet/<your-hostname>-config.jsالمسار المحدد. وتستخدم وثائق المصادقة الخاصة بـ Jitsi هذا المسار في أمثلتها. أما في عمليات نشر Docker، فيشير دليل Docker الرسمي إلى أن config.jsالملفات المُنشأة داخل الحاوية تُعاد إنشاؤها عند بدء التشغيل، لذا يجب وضع الإعدادات المخصصة في ملف الإعدادات على جانب المضيف CONFIG/web/custom-config.js. راجع دليل Docker الرسمي للاستضافة الذاتية .
قبل التعديل، انسخ الإعدادات الحالية، وغيّر مجموعة واحدة من المعلمات في كل مرة، وتأكد من صحة بنية جافا سكريبت. تجنب لصق نموذج كامل config.jsفوق بيئة تشغيل عاملة، لأن القوالب الأصلية تتطور وقد تتضمن قيمًا خاصة بكل بيئة.
constraints.video.heightواختبر ما إذا كان استقرار الفيديو يتحسن.startLastN، وإذا لزم الأمر، channelLastNحتى لا يقوم كل مشارك بتنزيل صور مصغرة غير ضرورية.لا تُعطّل ميزات البث المتزامن أو إعادة الإرسال لمجرد رغبتك في تقليل عرض النطاق الترددي؛ فهذه الإعدادات تؤثر على كيفية تكيف Jitsi وتعافيه من فقدان البيانات، وتغييرها قد يُؤدي إلى ظهور أعطال جديدة. لا تُجبر جميع المستخدمين على استخدام دقة 180p إلا إذا كان الاستخدام يتطلب ذلك فعلاً. لا تُعامل حدّ معدل البتات على أنه حجز لعرض النطاق الترددي. ولا تُركّز فقط على تحسين رابط الخادم مع تجاهل اتصال الميل الأخير عند كل نقطة نهاية.
لذا، فإن أفضل إعدادات Jitsi ذات النطاق الترددي المنخفض ليست تلك التي تحتوي على أقل عدد من الأرقام، بل تلك التي تحافظ على جودة الصوت، وتجعل صورة المتحدث النشط واضحة، وتحدّ من الفيديو الوارد غير الضروري، وتمنح المُشفّر مساحة كافية للتكيف. ابدأ بدقة 360p، وقيم LastN متحفظة، والإعدادات الافتراضية لبرنامج الترميز الحالي في Jitsi؛ ثم خفّض حدود معدل البت فقط عندما تُظهر قياساتك أن ذلك يُحسّن الاجتماع بدلاً من مجرد خفض جودة الصورة.
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
