שיחות וידאו קבוצתיות: SFU, Simulcast והתאמה תרמית
תארו לעצמכם: לאפליקציה שלכם יש 8 משתתפים, אחרי 10 דקות האייפון מתחמם ל-42°C, והשיחה נופלת. הבעיה היא בארכיטקטורה: ללא SFU (יחידת העברה סלקטיבית), כל לקוח נייד שולח וידאו לכל האחרים — בקבוצה של 8, כל אחד מטפל ב-7 זרמים נכנסים וזרם אחד יוצא. עומס המעבד והרשת גדל בריבוע. הפתרון הנכון הוא SFU עם simulcast. אנו מתכננים את הארכיטקטורה לתרחיש שלכם: 2 עד 20 משתתפים, עם התאמה למצב התרמי של המכשיר.
למה SFU עדיף על MCU?
MCU (יחידת בקרה מרובת נקודות) מערבב את כל הזרמים לאחד על השרת ושולח לכל משתתף וידאו יחיד. עומס הלקוח מינימלי, אך הערבוב דורש מעבד חזק ומוסיף השהיה של 100–300 אלפיות שנייה. מתאים לוובינרים שבהם רוב הצופים צופים בדובר אחד. SFU (יחידת העברה סלקטיבית) רק מנתב זרמים ללא פענוח. כל לקוח מקבל N זרמים (אחד לכל משתתף) ובוחר אילו לפענח ולהציג. עומס לקוח גבוה יותר אך השהיה נמוכה יותר וגמישות רבה יותר.
לאפליקציות ניידות עם ועידות עד 20 משתתפים, SFU הוא אופטימלי. פתרונות מוכנים: Livekit (קוד פתוח, אירוח עצמי), Mediasoup, Jitsi Videobridge, או שירותים מנוהלים — Daily.co, 100ms, Twilio Video Rooms. Livekit הוא בחירה מוצקה לאירוח עצמי: שרת Go, SFU WebRTC, תמיכה ב-simulcast ו-dynacast, SDKs מקוריים ל-iOS (LiveKit-iOS), אנדרואיד (LiveKit-Android), Flutter ו-React Native. רישיון MIT.
איך Simulcast מפחית עומס מעבד
ללא simulcast, בוועידה עם 10+ משתתפים מכשיר נייד שולח זרם 720p אחד לכל המשתתפים, גם לאלה עם אריחים קטנים. עם simulcast, הלקוח שולח שלוש איכויות בו זמנית (למשל, 180p/360p/720p), וה-SFU שולח לכל מקבל את האיכות התואמת לגודל האריח שלו. חיסכון במשאבים משמעותי: עומס המעבד יכול לרדת עד 40% עם משתתפים רבים.
בפרויקט טלרפואה עדכני, הפחתנו את עומס המעבד ב-35% במכשירי iOS על ידי יישום simulcast והתאמת מצב תרמי, מה שאיפשר ועידות יציבות עם 12 משתתפים ללא התחממות יתר.
ב-iOS, simulcast מוגדר דרך RTCRtpEncodingParameters עם שלוש שכבות:
let encodings = [
RTCRtpEncodingParameters(rid: "q", scaleResolutionDownBy: 4, maxBitrateBps: 150_000),
RTCRtpEncodingParameters(rid: "h", scaleResolutionDownBy: 2, maxBitrateBps: 500_000),
RTCRtpEncodingParameters(rid: "f", scaleResolutionDownBy: 1, maxBitrateBps: 1_200_000),
]באנדרואיד — באופן דומה דרך let encodings = [ RTCRtpEncodingParameters(rid: "q", scaleResolutionDownBy: 4, maxBitrateBps: 150_000), RTCRtpEncodingParameters(rid: "h", scaleResolutionDownBy: 2, maxBitrateBps: 500_000), RTCRtpEncodingParameters(rid: "f", scaleResolutionDownBy: 1, maxBitrateBps: 1_200_000), ] . זה מפחית עומס רשת ומעבד על מקבלים עם משתתפים רבים.
| שכבה | רזולוציה | קצב סיביות (bps) | מקרה שימוש |
|---|---|---|---|
| q (רבע) | 180p | 150,000 | תמונות ממוזערות, 9+ משתתפים |
| h (חצי) | 360p | 500,000 | אריח בינוני, 4–8 משתתפים |
| f (מלא) | 720p | 1,200,000 | דובר ראשי, 1–2 משתתפים |
איך להציג משתתפים: רשת ודובר דומיננטי
רשת ל-2–4 משתתפים היא פריסה סטטית. ל-5–16 משתתפים, השתמשו ברשת דינמית שמשתנה בעת כניסה/יציאה. כלל: אל תיצרו מחדש RtpParameters.Encoding בכל עדכון רשת — רק הקצו מחדש את המסלול ל-renderer הקיים. יצירה מחדש גורמת להבהוב ו-render מחדש.
זיהוי דובר דומיננטי — זיהוי מי מדבר והצגתו גדול יותר. Livekit ו-100ms מספקים זאת מובנה דרך אירועי RTCVideoRenderer. ב-WebRTC גולמי, נתחו onActiveSpeakersChanged מ-audioLevel.
ב-iOS, הציגו וידאו דרך RTCPeerConnection.getStats() (Metal) — חובה לוועידות. RTCMTLVideoView הישן (OpenGL ES) אינו תומך במספר מופעים עם ביצועים טובים ב-A15+. עם 6 משתתפים, RTCEAGLVideoView נותן 40 FPS, RTCEAGLVideoView 60 FPS יציב.
סוללה ומצב תרמי
ועידות קבוצתיות הן המצב הצרכני ביותר של סוללה. קידוד 720p ב-30 FPS צורך כ-15–20% סוללה לשעה באייפון 14. עם 4+ משתתפים, פענוח מספר זרמים מוסיף עוד.
אנו מגיבים ל-RTCMTLVideoView (iOS) — ב-ProcessInfo.thermalState או .serious, אנו מורידים רזולוציה ל-360p ומפחיתים FPS ל-15. באנדרואיד, .critical (אנדרואיד 11+). זו לא ירידה באיכות, אלא התאמה: ועידת 360p יציבה עדיפה על התחממות יתר והגבלת מעבד כפויה.
כשהאפליקציה ברקע ב-iOS, אנו עוצרים לכידת מצלמה (PowerManager.getThermalHeadroom()) בעוד האודיו ממשיך דרך AVCaptureSession.stopRunning(). באנדרואיד, AVAudioSession עם ForegroundService מחזיק הרשאות. זה חוסך סוללה ומפחית חום.
טעויות נפוצות
android:foregroundServiceType="camera|microphone"יחיד לכל האפליקציה — אל תיצרו מחדש לכל שיחה. אתחול לוקח 200–500 אלפיות שנייה; יצירה מחדש בכל שיחה מורגשת.- אי טיפול ב-
AVCaptureSession— חיבור AirPods במהלך ועידה ללא טיפול בהודעה זו מנתב אודיו לאפרכסת. - אי שחרור
AVAudioSession.routeChangeNotificationכשמשתתף עוזב — דליפת זיכרון מצטברת לאורך סשנים ארוכים וחדרים גדולים.
תהליך ולוחות זמנים
ביקורת דרישות → בחירת SFU (אירוח עצמי או מנוהל) → אינטגרציית SDK → ממשק משתמש (רשת, דובר דומיננטי, בקרות) → simulcast → התאמת מצב תרמי → בדיקות עומס. לאחר המסירה, אנו מספקים תיעוד SDK, גישה לקונסולת ניהול והדרכה קצרה לצוות. לצוות שלנו ניסיון של 7+ שנים בפיתוח מובייל ויותר מ-15 פרויקטים מסחריים של WebRTC.
| שלב | לוח זמנים (שבועות) | כולל |
|---|---|---|
| ביקורת ובחירת ארכיטקטורה | 1–2 | ניתוח טכני, המלצת SFU |
| אינטגרציית SDK וממשק משתמש בסיסי | 2–3 | אינטגרציית Livekit/100ms, רשת, בקרות |
| Simulcast ואיכות אדפטיבית | 1–2 | הגדרת קידוד, מצב תרמי |
| בדיקות עומס ופרופיל סוללה | 1 | פרופיל, אופטימיזציה |
ועידה עד 8 משתתפים דרך SFU מנוהל (100ms, Daily) עם SDK מוכן — 2–4 שבועות. Livekit באירוח עצמי עם ממשק משתמש מותאם ו-simulcast — 4–8 שבועות. העלות נקבעת לאחר ניתוח דרישות. צרו קשר — נבחן את הפרויקט שלכם ונציע ארכיטקטורת מפתח ביד.
מה כלול
- ביקורת טכנית והמלצות ארכיטקטורה
- בחירה ואינטגרציה של SFU (אירוח עצמי או מנוהל)
- פיתוח ממשק משתמש: רשת, דובר דומיננטי, בקרות
- הגדרת Simulcast ואיכות אדפטיבית
- אופטימיזציית סוללה ומצב תרמי
- בדיקות עומס עד 20 משתתפים
- תיעוד אינטגרציית SDK
- גישה לקונסולת ניהול
- הדרכה קצרה לצוות
הגדרת Simulcast שלב אחר שלב ב-iOS
- צרו אובייקטים של
RTCVideoTrackלכל שכבה עםRTCRtpEncodingParameters,rid,scaleResolutionDownBy. - החילו קידודים אלה על מסלול הווידאו דרך
maxBitrateBps. - הפעילו simulcast בצד ה-SFU (ב-Livekit, דגל
RTCRtpSender.setParameters()). - ודאו שמקבלים מחליפים שכבות כראוי כשגודל האריח משתנה.
- בצעו פרופיל של עומס מעבד ורשת עם 10+ משתתפים.
לפי תיעוד WebRTC, יישום נכון של simulcast יכול להפחית שימוש ברוחב פס עד 40%.
קבלו ייעוץ על אינטגרציה — נעזור ליישם simulcast בפרויקט שלכם.