שידור משותף באפליקציית מובייל: WebRTC + RTMP

Co-streaming באפליקציה לנייד: היכן השידור נשבר

Co-streaming באפליקציה לנייד — זה כאשר מספר מכשירים מעבירים וידאו וקול בו-זמנית לשידור אחד: מנחה ואורח, שני כתבים מנקודות שונות, מצלמה מהטלפון ועוד זווית שנייה. המשימה נראית פשוטה, עד שמתחילה הרשת האמיתית: לכל משתתף יש ערוץ משלו, השהיה משלו ונפילות משלו. בדיוק במפגש בין הזרמים האלה נשברת השידור בו-זמני.

הכשל הנפוץ הראשון — חוסר סנכרון בין אודיו לווידאו. הווידאו עובר בערוץ אחד, הקול בערוץ אחר, לחוצצים שלהם עומק שונה, וכאשר הרשת נופלת התמונה מפגרת אחרי הקול בשניות. הצופה רואה את תנועת השפתיים לפני הקול או להפך — השידור הופך לבלתי קריא, ובהקלטה הפגם נשאר לנצח.

השני — ניתוק החיבור בעת החלפת רשת. הטלפון עובר מ-Wi-Fi לאינטרנט סלולרי, הכתובת משתנה, והסשן נקרע בדיוק ברגע שבו יש הכי הרבה צופים. בלי חיבור מחדש וסנכרון מדביק את הזרם יש להעלות ידנית.

השלישי — עומס על השרת. כאשר כל משתתף מעביר את הזרם שלו בנפרד, חלק השרת מקודד ומפיץ אותם לפי מספר הצופים, וגידול הקהל מכפיל את העומס. כאן מופיעות נפילות האיכות אצל כולם בבת אחת.

אנחנו מפרקים כיצד זה נסגר ברמת הארכיטקטורה: ציר זמן אחיד לקול ולתמונה, חיבור מחדש עמיד בעת החלפת רשת וסכמת הפצה שאינה גדלה באופן ליניארי ממספר הצופים.

מה נותן co-streaming מכויל: האפקט במדדים

co-streaming מכויל נמדד לא ב"עובד/לא עובד", אלא במדדים קונקרטיים שרואה צוות המוצר.

זמן ההתחברות לשידור — מהלחיצה על "התחל" ועד הפריים הראשון אצל הצופה — נשמר בטווח של 2-3 שניות ברשת תקינה ועד 5 שניות בערוץ חלש: זהו הסף שמעבר לו הצופה לא עוזב מבלי שהמתין לתמונה.

שיעור הסשנים המוצלחים (הצופה התחבר וצפה עד הסוף ללא ניתוק) — מדד מפתח: בסכימה מכוילת הוא מגיע ל-97-99%, בעוד שאינטגרציה "גולמית" על תעבורה אמיתית יורדת ל-80-85% בגלל רשת סלולרית.

יציבות השידור מובטחת באמצעות התאמה לערוץ: הביטרייט והרזולוציה נבנים מחדש תוך כדי תנועה, בעת ירידת רשת התמונה מדרדרת באופן חלק (הורדת איכות), ולא נקרעת במסך שחור. בערוץ חלש — רכבת תחתית, מעלית, Wi-Fi עמוס — זה ההבדל בין "הצופה צפה עד הסוף" ל"הצופה עזב".

אנחנו מכניסים באפרינג ושחזור חיבור כך שכישלון רשת קצר-טווח לא הורג את הסשן: ההתחברות מחדש מתרחשת מבלי שהמשתמש מבחין, ללא הפעלה מחדש של השידור.

איכות התמונה בפלט — מדד נפרד: הרזולוציה והחדות נשמרות ככל שהערוץ מאפשר, ללא "סבון" וארטיפקטים של דחיסה. אנחנו מודדים זאת בשיעור הפריימים ללא אובדן ובזמן השחזור לאחר ירידה — שני המדדים נכנסים לניטור, ולא נשארים במילים.

סיכום במספרים: זמן ההתחברות מתקצר פי כמה לעומת סכימה לא מותאמת, שיעור הסשנים המוצלחים עולה ב-10-15 נקודות אחוז, הנטישות ברשת חלשה יורדות פי כמה. את המדדים האלה אנחנו לוקחים במכשירים אמיתיים ובערוצים אמיתיים, ולא בתנאי מעבדה אידיאליים — בדיוק משום כך הם תואמים את מה שרואה המשתמש.

דרכים לארגון co-streaming: השוואת גישות

ניתן להרכיב co-streaming בשלוש דרכים, והבחירה ביניהן קובעת לא את "יופי" התמונה, אלא את התנהגות האפליקציה תחת עומס: כמה צופים השידור יחזיק, כמה מהר המנחה יראה את תגובת הקהל ומה יקרה כאשר אחד המשתתפים ייכנס למטרו. להלן השוואה לפי השהיה, יכולת scaling ועלות תמיכה, ללא תלות בסטאק מסוים.

חיבור ישיר מעניק השהיה מינימלית — המשתתפים רואים זה את זה כמעט ללא הפסקה, אך כל בן שיח חדש מוסיף ערוץ, ובאינטרנט סלולרי חלש התמונה מתחילה "להתפרק". שרת-מתווך פותר בעיה זו: המנחה מוסר זרם אחד, והשרת מפיץ אותו לצופים, ולכן יכולת ה-scaling נתקלת בתשתית ולא בטלפון. הסכימה ההיברידית לוקחת את הטוב משניהם: ההשהיה בין המנחים נשארת נמוכה, והקהל מתחבר דרך השרת.

בפועל הבחירה נקבעת על ידי התרחיש. אם זהו שידור משותף של שניים-שלושה בלוגרים עם צ'אט פעיל — חיבור ישיר יספיק. אם השידור נצפה על ידי קהל המוני ונדרשת הקלטה — לא ניתן להסתדר בלי שרת-מתווך.

אנו מתאימים את הסכימה למשימה ומוסיפים מרווח ביטחון: האפליקציה צריכה לשרוד מעבר בין רשתות ולא לקטוע את השידור בעת החלפת מנחה.

כיצד אנו בונים co-streaming: שלבי העבודה

Co-streaming כמעט לעולם אינו נבנה "מאפס": ללקוח כבר יש אפליקציה, אימות, פרופילים ואנליטיקה, והסכמה החדשה צריכה להשתלב בתשתית הזו מבלי לשבור את המהדורות הנוכחיות.

לכן אנו מנהלים את העבודה כפרויקט הנדסי עם שלבים קבועים — מסקר ועד העברת נהלים, כדי שצוות הלקוח יבין מה ומתי יופיע במוצר.

1. סקר. בוחנים את האפליקציה הנוכחית: פלטפורמות, ארכיטקטורה, שירותי האימות וההתראות בשימוש, מגבלות עומס. מתעדים כמה שידורים חיים וצופים בו-זמניים הפתרון צריך להחזיק בהתחלה ועם מרווח לצמיחה.
2. תכנון הסכמה. קובעים היכן נמצא שרת המדיה, כיצד מתחלקים תפקידי המנחה והצופים, כיצד בנויים חדרי השידור, ההקלטה והמודרציה. בשלב זה מתאמים את סכמת הזרימות ותרחישי כשל — מה קורה בעת ניתוק התקשורת אצל המנחה או הצופה.
3. הגדרת זרימות. פורסים קליטה והפצה של וידאו, מגדירים פרופילי איכות אדפטיביים לרשתות סלולריות, השהיה ומעבר בין ערוצי תקשורת. בנפרד מפתחים את התנהגות האפליקציה בעת אות חלש ומעבר בין רשתות.
4. אינטגרציה עם האפליקציה. מטמיעים את מודול השידור במסכים הקיימים, מקשרים עם אימות, פרופילים, התראות push ואנליטיקה. המשתמש לא צריך להבחין בתפר בין הפונקציונליות הישנה לחדשה.
5. בדיקות. מריצים תרחישים על מכשירים ורשתות אמיתיים: כניסה המונית של צופים, שידורים בו-זמניים, ניתוקים, ערוץ חלש, הפעלות ממושכות. בודקים עומס והתנהגות בעת חיבורים בשיא.
6. העברת תיעוד. מוסרים את הסכמה המוגדרת, תיאור התצורה, נהלי התמיכה והוראות לצוות הלקוח — כדי ששינויים עתידיים לא ידרשו אותנו כנושאי הידע היחידים.

היקף ולוחות הזמנים של כל שלב תלויים במצב הנוכחי של האפליקציה ובדרישות לעומס. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה למוצר שלכם.

מדיניות גישה ותפקידים ב-co-streaming

Co-streaming נשבר לא על הקודק, אלא על ההרשאות: אם כל משתתף בחדר יכול להתחזות למנחה או להתחבר לשידור של מישהו אחר, שום יציבות של התמונה כבר לא מצילה.

לכן את מודל הגישה מתכננים לפני שורת הקוד הראשונה של השידור — תפקידים, חדרים וטוקנים מתוארים כסכמה אחודה, ולא נאספים בטלאים בעקבות תקלות.

את התפקידים מקבעים ברמת שירות ההרשאה, ולא בצד הלקוח: מנחה, מנחה-שותף, אורח וצופה מקבלים סטים שונים של הרשאות לפרסום אודיו ווידאו, לניהול הבמה ולמודרציית הצ'אט. הלקוח רק מציג את מה שמותר — החלפת תפקיד באפליקציה לא נותנת גישה, כי השרת בודק אותה בכל התחברות לחדר.

• מנחה — מפרסם את השידור, פותח וסוגר את החדר, ממנה מנחים-שותפים, מסיר משתתפים.
• מנחה-שותף — מפרסם את השידור ומנהל מודרציה, אך לא משנה את הרכב החדר ולא סוגר את השידור.
• אורח — מפרסם אודיו ווידאו רק לאחר אישור המנחה, ללא הרשאות מודרציה.
• צופה — מקבל את השידור, יכול לכתוב בצ'אט ולהגיב, פרסום אסור.
• צופה-משקיף — גישה לסטטיסטיקה ולהקלטה ללא הרשאה להיכנס לשידור, לצורכי אנליטיקה ותמיכה.

את ניהול החדרים בונים סביב מחזור החיים: החדר נוצר עבור שידור מסוים, חי זמן מוגבל ונסגר אוטומטית בזמן חוסר פעילות. זה מסיר חדרים "תלויים" שאפשר להתחבר אליהם בקישור ישן, ומפשט את חקירת התקלות — לפי מזהה החדר רואים מי ומתי נכנס אליו.

הגנת השידורים נשענת על טוקני גישה קצרי-מועד: כל אחד מונפק עבור חדר מסוים, תפקיד ותוקף, ונבדק בכניסה ובחידוש הפרסום. אין אפשרות לעשות שימוש חוזר בטוקן בחדר אחר או לאחר פקיעת התוקף, וביטול הגישה פועל ללא הפעלה מחדש של השידור — המשתתף מנותק מהפרסום, בלי לנתק את השידור עבור האחרים.

מקרה בוחן: איך תיקנו חוסר סנכרון באפליקציה לשידורים משותפים

הלקוח הגיע עם מוצר לשידורים משותפים: שני מנחים או יותר משדרים מהאפליקציה בו-זמנית, והצופים רואים סצנה משותפת. תלונות לתמיכה הגיעו לפי תרחיש אחד — השמע של מנחה אחד פיגר אחרי הווידאו של האחר, וברשת חלשה הסשן נקרע כולו, למרות שמספיק היה לאבד משתתף אחד. שיעור הצפייה המלאה בשידורים כאלה ירד: הצופה עזב בדקות הראשונות, ברגע שהתמונה "זזה".

WebRTC בחרנו לחלק האינטראקטיבי — שם חשובה השהיה בין המנחים — ואת ההפצה לקהל רחב הובלנו דרך RTMP לשרת מדיה. חוסר הסנכרון נוצר בנקודת החיבור: הזרמים הגיעו עם חותמות זמן שונות, והמיקסר הרכיב את הסצנה בלי ציר זמן אחיד.

הכנסנו מקור זמן משותף לכל הזרמים הנכנסים וחוצץ יישור שמרסן את תנודות הרשת בלי לצבור השהיה. הניתוקים טופלו בנפרד: חיבור מחדש של משתתף הפך לפעולה מקומית — המסלול שלו מורכב מחדש, והשידור לצופים ממשיך.

מה שינינו בארכיטקטורה

הפרדנו תפקידים: קליטת זרמים מהמנחים, מיקסינג הסצנה והפצה לצופים — צמתים בלתי תלויים. נפילה או הפעלה מחדש של אחד לא מפילה את האחרים. לכל משתתף אנחנו מחזיקים ערוץ גיבוי: בעת הידרדרות הרשת הזרם עובר במסלול חלופי, הצופה רואה החלפת איכות ולא ניתוק. מצב הסשן נשמר בנפרד מזרם המדיה — אחרי תקלה המנחה חוזר לאותו שידור, ולא יוצר חדש.

מדדים לפני ואחרי

בנפרד נאמר על הדיאגנוסטיקה: הוספנו תגים מקצה לקצה בכל שלב — מצילום המצלמה ועד הפריים אצל הצופה. עכשיו, כשיש תלונה, רואים באיזה קטע אבד הזמן, במקום לנחש השערות. זה מה שהופך תיקון חד-פעמי לתהליך מנוהל: התקלה הבאה מנותחת לפי נתונים, ולא לפי תחושות.

במה שונה co-streaming משידור רגיל?

שידור רגיל הוא מקור אחד שמפרסם זרם לשרת, וכמה צופים שלא יתחברו, התמונה אצל כולם זהה. Co-streaming הופך את הסכמה: יש כמה משדרים, כל אחד שולח את הזרם שלו מהמכשיר שלו, והשרת מאחד אותם לשידור משותף.

הצופה רואה לא חלון אחד, אלא קומפוזיציה — מנחה, מנחה שותף, אורח, מסך הטלפון — ומחליף בין זוויות בלי להפעיל מחדש את הנגן.

ההבדל המרכזי הוא במודל הפרסום. בשידור בודד מספיק מפגש העלאה אחד: האפליקציה לוכדת את המצלמה והמיקרופון, מקודדת ומוסרת את הזרם. בשידור משותף יש כמה מפגשים כאלה כמו מספר המשתתפים, וכל אחד חי בערוץ משלו עם איכות רשת בלתי צפויה.

המשימה של האפליקציה היא לא רק לשלוח את הזרם שלה, אלא לקבל זרים, לאחד אותם לסצנה אחת ולהפיץ לצופים במכלול אחד. מכאן הדרישות למספר מכשירים: לכל אחד יש קצב סיביות משלו, השהיה משלו, רגע כניסה ויציאה משלו מהשידור.

סנכרון הוא מה שמבדיל co-streaming עובד מסט של סרטונים נפרדים. הקול של המנחה והתגובה של האורח חייבים להתאים בזמן, אחרת הדיאלוג מתפרק להד ולדחיפה. לשם כך מאזנים את הזרמים לפי חותמות זמן משותפות, ואת הפער בין סאונד לתמונה שומרים בגבולות שהאוזן לא מבחינה בהם. אם האורח נכנס עם חיבור גרוע, עוצרים את המסלול שלו במאגר, ולא מפילים אותו לשידור באיחור של שניות.

הדרישות מהאפליקציה גדלות בהתאם. יש צורך בעמידות לשינוי רשת — מעבר מ-Wi-Fi לרשת סלולרית בלי ניתוק, — התאמת קצב סיביות לכל משתתף בנפרד, ולא לזרם משותף, והבחנה בין תפקידים: מי משדר, מי רק צופה, את מי אפשר להעלות לשידור בהזמנה. שידור בודד לא דורש את כל זה — אין שם מה לסנכרן ואין עם מי לחלוק את השידור.

ספקות טכניים נפוצים לגבי co-streaming

Co-streaming כמעט תמיד נתקל לא בעצם השידור, אלא בארבע שאלות טכניות: כיצד זה עובד במכשירים שונים, מה יקרה לעומס עם גידול במספר המשתתפים, כיצד לסגור הרשאות גישה ומה לעשות באינטרנט חלש. להלן — תשובות לאלה שצפות לעתים קרובות ביותר בשלב ההערכה.

כיצד האפליקציה תעמוד בעומס אם מספר הצופים יגדל פי כמה?

הארכיטקטורה בנויה כך שמספר הצופים לא ישפיע על העומס על הטלפון של המנחה: ה-signaling והפצת הזרם מועברים לחלק השרת, והלקוח רק שולח זרם יוצא אחד. עם גידול הקהל מתווספים צמתי הפצה, ולא כוח המכשיר של הסטרימר. זה מסיר את הבעיה הקלאסית שבה עם 50+ צופים הטלפון מתחיל להתחמם ולהפיל פריימים.

כיצד נסגרות הרשאות הגישה וההגנה על השידור?

גישה ניתנת דרך טוקנים קצרי מועד, הקשורים לסשן ולמכשיר: לא ניתן להעביר את הקישור ולצפות מחשבון זר. הזרמים מוצפנים לכל אורך הדרך, וההקלטה והמודרציה של הצ'אט מוגדרות במדיניות נפרדת. לשידורים בתשלום מתווספת בדיקת זכות צפייה בצד השרת, ולא באפליקציה.

מה קורה באינטרנט חלש אצל הסטרימר או הצופה?

הערוץ מתאים את עצמו לפי משוב: הביטרייט והרזולוציה יורדים בשלבים, עם אובדן מנות מופעלת שליחה חוזרת, ובניתוק מלא הסשן משוחזר ללא הפעלה מחדש של השידור. הצופה ברשת חלשה מקבל זרם עם חציצה גדולה יותר — התמונה מפגרת מעט, אך לא מתפרקת. הסטרימר רואה מחוון איכות ומבין מתי כדאי לעבור לערוץ גיבוי.

אם השאלה שלכם אינה כאן — תארו את התרחיש, ונחזור עם הערכה ותוכנית לעומס ספציפי ולפארק מכשירים.

בואו נדון במשימה שלכם בתחום ה-co-streaming

כדי לחזור עם הערכה ותוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים שיחה עניינית. Co-streaming לעיתים רחוקות הוא "רק להוסיף כפתור": יש לו דרישות לגבי השהיה (latency), לגבי מספר המשתתפים בו-זמנית, ולגבי היכן הווידאו מתארח — על חומרה משלכם או אצל ספק חיצוני. ככל שתתארו בצורה מדויקת יותר את האפליקציה הנוכחית ואת המגבלות, כך הצעד הבא יהיה קונקרטי יותר.

מה שחשוב לנו להבין כבר בשלב הראשוני, כדי שההערכה תתבסס על עובדות ולא על הנחות:

• האפליקציה הנוכחית: פלטפורמות, על מה היא בנויה, כיצד בנויים האימות והעבודה עם מדיה — זה קובע אם אנחנו משתילים את ה-co-streaming בארכיטקטורה הקיימת או כותבים מחדש חלק ממנה.
• תרחיש השידור: כמה מנחים בו-זמנית, כמה צופים, האם נדרשים צ'אט, תגובות, מודרציה והקלטת השידור.
• דרישות להשהיה (latency): שיחה אינטראקטיבית בין המנחים לעומת צפייה פסיבית — אלו סכמות שונות של אספקת וידאו, והבחירה משפיעה על כל המבנה.
• איכות ורשת: הפלטפורמות המיועדות, ערוצים ניידים ואיטיים, התנהגות בעת ירידת איכות החיבור — מכך נגזרת הלוגיקה של החלפת האיכות.
• תשתית והרשאות גישה: האם יש שרתי מדיה משלכם, CDN, מגבלות על אחסון ופרטיות של הקלטות.
• לוחות זמנים ושלביות: מה נדרש להשקה הראשונה, ומה ניתן להעביר לשלב השני בלי לשנות את הבסיס.

בסיום השיחה אנחנו חוזרים עם הערכה ותוכנית עבודה: שלבים, מה אנחנו עושים בכל שלב, אילו דרישות אנחנו סוגרים והיכן נקודות הבדיקה של התוצאה. תארו את המשימה — האפליקציה הנוכחית, תרחיש השידור והמגבלות — ואנחנו נחזור עם הצעה קונקרטית והצעד הבא.