איך הפכנו את שיתוף המסך למהיר פי ארבעה

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

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

למה בכלל יש השהיה בשיתוף מסך

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

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

תיקון ראשון: להפסיק לקודד את אותה תמונה פעמיים

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

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

תיקון שני: להדק את הבאפר בלי לוותר על עמידות

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

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

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

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

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

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

מה זה אומר אם אתם מציגים עכשיו

שום דבר מזה לא דורש לשנות הגדרה. זה מגיע בצינור שיתוף המסך של אפליקציית שולחן העבודה, וזה חל בין אם משתפים מסך יחיד לחדר קטן ובין אם מריצים הפקת Studio מלאה עם כמה מקורות, כולל תהליכי עבודה עם vMix שנשענים על פיד מהיר וצפוי. ב-Cliqer 3, הווידאו של Studio ב-Mac הוא ללא העתקה (zero copy): פריימים של המצלמה, המקורות וה-Program נשארים בזיכרון ה-GPU, והמקודד החומרתי קורא את ה-Program ישירות ממשטח ה-GPU. Cliqer 3 גם מציג כל הזמן את קצב הפריימים של ה-Program ואת עומס ה-GPU וה-CPU בשורת הסטטוס של Studio, כך שאפשר לבדוק את קצב הפריימים בעצמכם באמצע ההופעה. אם רוצים לכוונן איכות מול רוחב פס בנוסף לשיפורי ההשהיה, הגדרות שיתוף המסך כוללות בחירת codec, רזולוציה וקצב סיביות, וגרסת שולחן העבודה 2.2.0 הוסיפה אפשרות לכלול שמע מערכת או מיקרופון ישירות בשיתוף.

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

לאן הולכת שאר ההשהיה

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

שאלות נפוצות

לנסות בעצמכם

הדרך המהירה ביותר להרגיש את ההבדל היא לשתף מסך ולהסתכל על הפנים של מישהו אחר כשהוא רואה אותו. אפשר להוריד את Cliqer בחינם ולנסות שיתוף מסך במערך שלכם, או לראות את כל היכולות בשיתוף מסך ולהשוות תוכניות בתמחור.