כמה טוב שיתוף מסך WebRTC, באמת? שמתי 4 Codec למבחן

תמיד הייתי סקרן לדעת איך קודקים שונים מסתדרים כשמדובר בשיתוף מסך דרך WebRTC. אז, החלטתי לברר בעצמי על ידי בדיקת ארבעת הנפוצים ביותר: VP8, VP9, H.264 ו-AV1. כדי לוודא שהתוצאות היו מוצקות, ערכתי בדיקות על פני מגוון סוגי תוכן ותנאי רשת. לא הסתמכתי רק על רשמים חזותיים - השתמשתי בהשוואות מסגרת למסגרת, חישבתי יחס אות לרעש שיא (PSNR), והוצאתי נתונים סטטיסטיים מפורטים של WebRTC כדי לקבל תצוגה ברורה מונעת נתונים. כדי ללכת צעד קדימה, אפילו בניתי תוסף Chrome מותאם אישית שעוקב אחר השימוש במעבד במהלך הקידוד והפענוח. זה נתן לי מבט טוב על האופן שבו כל codec משפיע על ביצועי המערכת - כי האיכות מעולה, אבל לא אם המחשב שלך בוער ומנסה לעמוד בקצב. הסתכלתי על מדדי מפתח כמו קצב סיביות, קצב פריימים, רזולוציה, קוונטיזציה (QP), PSNR ועומס מעבד. בהתבסס על כל זה, הבאתי כמה המלצות מעשיות שיעזרו לכל מי שמנסה לייעל את שיתוף המסך של WebRTC עבור מקרי השימוש שלו. לגבי הניסוי מדוע שיתוף מסך אינו פשוט כפי שהוא נראה אם אי פעם שיתפת את המסך שלך במהלך שיחת וידאו ושמת לב שהאיכות יורדת - או שהסרטון נהייה קטוע - אתה לא לבד. שמירה על שיתוף מסך חד וחלק הוא למעשה מסובך יותר ממה שזה נראה. הבעיה? הכל עניין של מגוון. חלק מהתוכן עדיין, כמו חפיסת שקופיות או מסמך. פעמים אחרות, אתה משתף וידאו בהילוך גבוה. סוגי התוכן השונים הללו דורשים מה-codec דברים שונים מאוד. לדוגמה, וידאו בתנועה מהירה אוכלת המון רוחב פס, בעוד שתמונות סטטיות רגישות יותר לחפצי דחיסה שעלולים לגרום להן להיראות מטושטשות או חסומות. זרקו בעיות אינטרנט בעולם האמיתי כמו אובדן מנות או ירידת רוחב פס, והדברים נעשים מבולגנים עוד יותר. לכן בחירת ה-Codec המתאים - וכוונון עדין של אופן פעולתו - חשובה כל כך כדי להפוך את שיתוף המסך לאיכותי וגם להגיב. יש כבר הרבה מחקרים בחוץ על ביצועי ה-codec של וידאו בתרחישי סטרימינג כלליים. אבל לשיתוף מסך יש מוזרויות משלו. זה לא רק צפייה בסרטון - זה קשור לאינטראקציה בזמן אמת, וסוגי התוכן נמצאים בכל מקום. זה אומר שהמחקר הרגיל לא תמיד חל. מה התכוונתי לעשות רציתי לחפור עמוק יותר במקרה השימוש הספציפי הזה. המטרה שלי הייתה לראות איך מבצעים קודקים שונים בכל הקשור לשיתוף מסך, במיוחד תחת אילוצים של העולם האמיתי כמו סוגי תוכן משתנים ותנאי רשת בלתי צפויים. כדי לעשות זאת, תכננתי שיטה להערכת איכות שיתוף המסך בצורה מדויקת ככל האפשר - לא רק על סמך איך זה נראה, אלא מגובה במדדים ונתונים מוצקים. לאורך הדרך, למדתי הרבה על אילו קודקים מחזיקים הכי טוב וכיצד לכוונן דברים לביצועים טובים יותר ביישומים בזמן אמת. דבר אחד התברר במהירות: ביצועי שיתוף המסך תלויים באמת שאתה משתף. סרטון בקצב מהיר מתנהג בצורה שונה מאוד ממסמך סטטי או גלילה איטית בדף אינטרנט. במה כדי לשמור על דברים הוגנים ועקביים, הקפדתי שכל מבחן רץ עם אותם תנאים בדיוק - אותה רזולוציה, אותה נקודת התחלה, ואותו משך. כך, יכולתי להיות בטוח שהתוצאות היו כולן על ביצועי ה-codec, לא על איזה משתנה מקרי. יצרתי שני מקרי בדיקה שונים כדי לדמות מצבי שיתוף מסך בחיים האמיתיים: - זה היה קליפ אמיתי של רוכבי אופנוע דוהרים ביער. הרבה תנועה מהירה, נוף מפורט וסביבה ויזואלית משתנה ללא הרף - מושלם לדחיפת גבולות הדחיסה. סרטון בהילוך גבוה - בניתי דף HTML פשוט עם טקסט ותמונות, ולאחר מכן השתמשתי ב-JavaScript כדי לגלול אותו במהירות קבועה. זה מחקה מקרה שימוש נפוץ כמו שיתוף מסמך או קריאה מדף אינטרנט. גלילה אוטומטית של טקסט שני סוגי התוכן האלה נתנו לי שילוב טוב כדי לבדוק איך כל codec מתמודד עם אתגרים שונים - מעמידה בקצב התנועה ועד לשמירה על בהירות בסצנות סטטיות יותר. איך אני מגדיר הכל כדי לבדוק כראוי את ה-codec, הייתי צריך הגדרה מוצקה שיכולה ללכוד - גם מה שנשלח וגם מה שהתקבל. התחלתי עם כלי שנקרא (אגב אתה יכול ללמוד על הכלי הזה ורבים נוספים בפוסט אחר שלי: " "), שהוא מעולה להתעסקות עם רכיבים פנימיים של WebRTC. בסופו של דבר כיוונתי את זה לא מעט כדי להתמודד טוב יותר עם שיתוף המסך ולוודא שאוכל להקליט גם את זרמי הווידאו היוצאים וגם הנכנסים. כל ריצת בדיקה נתנה לי שני קבצי וידאו - אחד עבור מה שנשלח ואחד עבור מה שהתקבל - שבהם השתמשתי מאוחר יותר לניתוח זה לצד זה. הכל webrtc-sandbox לימוד WebRTC בתרגול: הכלים וההדגמות הטובות ביותר אבל לא עצרתי בווידאו. רציתי גם לעקוב אחר מה שקורה מתחת למכסה המנוע. לשם כך, שלפתי נתונים סטטיסטיים מפורטים של WebRTC ישירות מדפדפן כרום. הנתונים הסטטיסטיים האלה נתנו לי חלון לביצועים של כל codec וכיצד התנהגה הרשת המדומה במהלך כל בדיקה. חלק גדול אחד מהפאזל היה - וזה התברר קצת מסובך. הגרסה הרגילה של כרום לא מאפשרת לפלאגינים לעקוב אחר עומס המעבד עבור כרטיסיות בודדות, אז השתמשתי בפיתוח של הדפדפן וכתבתי פלאגין משלי כדי לעקוף את זה. השימוש במעבד התמקדתי במיוחד במדידת השימוש במעבד מהכרטיסייה ששלחה או קיבלה את שיתוף המסך. בדרך זו, לא כללתי משימות עיבוד לא קשורות מחלקים אחרים של הדפדפן. מכיוון שגם השליחה וגם הקבלה התרחשו באותה כרטיסייה, המספרים שקיבלתי היו תצוגה משולבת - אבל עדיין די קרובים למה שהיית רואה במקרה של שימוש בעולם האמיתי. (ספוילר: קידוד בדרך כלל פוגע במעבד חזק יותר מאשר פענוח.) איסוף הנתונים: 157 ריצות מבחן מאוחר יותר... לאחר שההתקנה הייתה מוכנה, הגיע הזמן להפעיל את הניסויים בפועל - והרצתי הרבה מהם. חזרתי על הבדיקות באותה מכונה, שוב ושוב, תוך שימוש בתנאי רשת שונים והגדרות codec כדי לראות איך הדברים החזיקו מעמד. בסך הכל, אספתי , ודאגתי שכל שילוב של תנאי הבדיקה היה מיוצג היטב. 157 נקודות נתונים זה נתן לי מערך נתונים מוצק לעבוד איתו ואפשר ניתוח עומק של איך שיתוף מסך מתנהג ב-WebRTC בתרחישים שונים. זה מה שבדקתי במיוחד: : השתמשתי בשני סוגים של תוכן שיתוף מסך כדי לשקף מקרי שימוש נפוצים: סוג וידאו - קטעים מהעולם האמיתי עם טונות של פיקסלים משנים כל פריים. וידאו בהילוך גבוה - רובו חזותיים סטטיים, אך עם פיקסלים משתנה במיקום עם גלילה של הטקסט. טקסט עם גלילה אוטומטית : בדקתי את ארבעת הקודקים הפופולריים ביותר לשיתוף מסך: Codec AV1 H.264 VP8 VP9 : מכיוון שלרוחב הפס יש תפקיד עצום באיכות הווידאו (במיוחד בשיחות וידאו), סימנתי מגוון תנאי רשת כדי לראות עד כמה כל codec טיפל ברוחב פס הדוק או משתנה. רוחב פס רשת על ידי ערבוב והתאמה של משתנים אלה בצורה מובנית, הצלחתי לחקות תרחישים של שיתוף מסך בעולם האמיתי - מהסוג שנתקלת בו בשיחת וידאו, במהלך הדגמה חיה או בהפעלה שיתופית מרחוק. תיקון התקלות: איך הפכתי את הבדיקות לאמינות יותר כמו ברוב הניסויים, הריצות הראשונות לא עברו בצורה חלקה כפי שקיוויתי. שתי בעיות עיקריות עלו מיד: בהתחלה, התחלתי את שיתוף המסך באופן ידני - פשוטו כמשמעו לחיצה על כפתור כדי להתניע את העניינים. הבעיה? זה היה כמעט בלתי אפשרי לסנכרן את תחילת ההקלטה עם התחלת תוכן הווידאו. זה אומר שלכל ריצת מבחן היה תזמון שונה במקצת, מה שהשליך את ההשוואות. הפעלה ידנית = תזמון מבולגן. גם כשהעיתוי היה נכון, לסרטון בזמן אמת יש מוזרויות משלו. הודות לקידוד, פענוח ועיכובים ברשת, הזרמים שנשלחו והתקבלו מעולם לא הסתדרו בצורה מושלמת. זה הפך את השוואת איכות מסגרת למסגרת כמעט בלתי אפשרית. נשלח לעומת התקבל = לא מסונכרן. כדי לפתור את הבעיות האלה, ביצעתי כמה שיפורים עיקריים: : במקום להתחיל הכל באופן ידני, כתבתי קוד כלשהו כדי לסנכרן את תחילת הסרטון או טקסט גלילה עם תהליך ההקלטה. כך, כל ריצת מבחן החלה באותו רגע בדיוק בשני הקצוות - הבעיה נפתרה. סנכרון פרוגרמטי : לעניין ביטול הסנכרון, הוספתי שכבת-על קטנה של קוד QR לסרטון המשותף. הסמן הקטן הזה פעל כמו חותמת זמן - הוא נתן לי להתאים פריימים בין הזרמים הנשלחים והמתקבלים בדיוק. לפתע, ניתוח מסגרת אחר מסגרת הפך לאפשרי (והרבה יותר מדויק). התאמת מסגרת של קוד QR היה עוד דבר אחד שהייתי צריך לתת עליו את הדעת: . אחת התכונות המגניבות של WebRTC היא שהיא מתאימה אוטומטית את איכות הווידאו על סמך רוחב הפס הזמין. אבל ההתאמה הזו לא מתרחשת באופן מיידי - לוקח כמה שניות להתייצב. אז, הוספתי עיכוב קצר לפני התחלת ההקלטה בפועל. זה נתן למערכת זמן להתייצב בקצב הסיביות של היעד, כך שהתוצאות ישקפו את האיכות האמיתית שתקבל לאחר שהדברים ישתפרו. קצב הסיביות האדפטיבי של WebRTC השינויים האלה הפכו את הניסוי להרבה יותר אמין והעניקו לי ביטחון שהנתונים שאספתי באמת משקפים איך שיתוף מסך מתנהג בעולם האמיתי. מה מדדתי (ולמה זה חשוב) אספתי הרבה נתונים במהלך הבדיקות האלה, אבל כדי שהדברים יהיו פשוטים וקלים להשוואה, התמקדתי בכמה מדדי ליבה שבאמת מספרים את הסיפור של הביצועים של כל codec בתרחיש של שיתוף מסך. הנה מה שהסתכלתי עליו: קצב פריימים זה אומר לי כמה פריימים בשנייה למעשה הקודדו, נשלחו והתקבלו. זהו אינדיקטור טוב לכמה חלק זרם הווידאו מרגיש - קצב פריימים גבוה יותר פירושו בדרך כלל חוויה זורמת יותר. הַחְלָטָה הרזולוציה היא כולה כמה פרטים חזותיים נשמרים. עקבתי אחר מספר הפיקסלים לכל מסגרת בכל שלב (נשלח והתקבל) כדי לראות אם ה-codec החזיקו באיכות התמונה או שמט אותה כדי לחסוך ברוחב פס. איכות וידאו השתמשתי כאן בכמה מדדי מפתח: - QP נמוך יותר פירושו בדרך כלל איכות טובה יותר. פרמטר קוונטיזציה (QP) - זה נותן תחושה מספרית של עד כמה הסרטון שהתקבל שונה מהמקור. גבוה יותר = טוב יותר. יחס אות לרעש שיא (PSNR) שימוש במעבד ביצועי Codec אינם קשורים רק למה שאתה רואה - אלא גם על מה שהמכונה שלך עושה מאחורי הקלעים. מדדתי כמה כוח מעבד היה בשימוש עבור קידוד ופענוח במהלך כל בדיקה, מנורמל לאורך זמן, כדי לראות אילו רכיבי Codec הם קלים ואלו הם חזירי משאבים. על ידי פירוק הדברים עם המדדים האלה, הצלחתי להשוות את ה-codec לא רק לגבי איכות, אלא גם לגבי חלקות, יעילות ועד כמה הם תובעניים. זה עזר לחשוף היכן כל codec זורח - ואיפה הוא נאבק - בתנאי שיתוף מסך בעולם האמיתי. סוף סוף מגיעים לתוצאות כמה משנה סוג התוכן? הרבה יותר ממה שאתה חושב אחד מהדברים המפתיעים ביותר מהניסויים שלי היה עד כמה התוכן שאתה משתף משפיע על ביצועי שיתוף המסך - הן מבחינת איכות הווידאו והן מבחינת השימוש במשאבים. וזה היה נכון codec שבדקתי. סוג לכל הרעיון מאחורי זה די פשוט: כאשר יותר פיקסלים משתנים ממסגרת למסגרת (כמו בסרטון שזז במהירות), המערכת צריכה לעבוד קשה יותר. זה אומר שדרוש יותר רוחב פס, והמעבד שלך צריך להתאמץ יותר כדי לעמוד בקצב. קח , למשל. כשהשתמשתי בו כדי לשתף מסך של 1.5 מגה-פיקסל, רוחב הפס הנדרש השתנה מאוד בהתאם למה ששותף. במקרה אחד, שבו התוכן היה דינמי יותר, AV1 היה צריך לדחוף יותר נתונים משמעותיים כדי לשמור על הזרם חלק. תפסתי זאת , שמראה עד כמה מורכבות התוכן משפיעה באופן דרסטי על השימוש ברוחב הפס. את AV1 בגרף הבא אבל זה לא רק רוחב פס - גם החומרה שלך מרגישה את זה. מציג כיצד השימוש במעבד משתנה בהתאם לתוכן המשותף. שוב, אם אתה משתמש ב-AV1 כדוגמה, אתה יכול לראות בבירור שתמונות ויזואליות מורכבות יותר דורשות הרבה יותר כוח מעבד כדי לשמור על הפעלה באותו קצב פריימים ורזולוציה. הגרף הבא זה גם לא רק עניין של AV1. כל הקודקים מסתמכים על אותם עקרונות בסיסיים לקידוד ופענוח וידאו, כך שהיית מצפה מהם להראות התנהגות דומה - אבל הנתונים מספרים סיפור אחר. עומס המעבד לא משתנה רק עם התוכן, הוא משתנה גם על סמך אתה משתמש. איזה codec כדי להקל על ההשוואה, הרכבתי , שמראה כמה מעבד משתמש כל codec בעת הזרמת וידאו של 1.5 מגה-פיקסל בסביבות 24 פריימים לשנייה - הגדרה די טיפוסית לשיתוף מסך חלק. התוצאות מדגישות כמה הבדלים עיקריים ביעילותו של כל codec בכל הנוגע לשימוש בחומרה שלך. את הטבלה הבאה Codec/CPU AV1 H264 VP8 VP9 תְנוּעָה 287% 213% 270% 364% טֶקסט 175% 130% 179% 198% לכן, אם אתה בונה או מבצע אופטימיזציה של משהו שמסתמך על שיתוף מסך של WebRTC, ההנחה ברורה: גם התוכן שלך וגם בחירת ה-codec שלך חשובים. הרבה. Showdown Codec: קצבי פריימים, עומס מעבד והעלויות האמיתיות של איכות כשזה מגיע לשיתוף מסך, אחד הדברים הראשונים שתבחין בהם הוא עד כמה הסרטון מרגיש חלק (או לא). זה המקום שבו נכנס לתמונה. אם אתה משתף תוכן בתנועה גבוהה, כמו הפעלת וידאו או אנימציות, קצב פריימים גבוה יותר הוא חיוני כדי להימנע מזרמים קטועים וקשים לצפייה. קצב הפריימים עבור חלק זה של הניסוי, התמקדתי בביצועי קצב פריימים על פני קודקים שונים תוך שמירה על כל השאר קבוע: אותה רזולוציה (בערך 1.5 מגה פיקסל) ואותו תוכן עבור כל בדיקה. השתמשתי בהגדרת WebRTC כדי לוודא שהרזולוציה נשארת נעולה בכל רחבי הלוח. contentHint , תוכל לראות כיצד רכיבי קודקים שונים מטפלים בתוכן בתנועה גבוהה ככל שרוחב הפס גדל. על ציר ה-x: קצב סיביות ב-Mbps. על ציר ה-y: קצב פריימים במסגרות לשנייה (fps). בתמונה הבאה הנה מה שבלט: ו- המשיכו קדימה ברגע שרוחב הפס הגיע ל-2 Mbps או יותר, שניהם מספקים 20+ פריימים לשנייה - חוויה חלקה שניתן להשיג אפילו בחיבור 3G הגון. H.264 AV1 ו- לא עמדו בקצב. הם ריחפו בערך במחצית מקצב הפריימים באותם תנאים, ובאמת היו צריכים 4 Mbps או יותר כדי להרגיש שמיש - מה שלא תמיד מציאותי ברשתות מתקדמות. VP8 VP9 אחר כך עברתי - דף טקסט שגולל באיטיות - כדי לראות כיצד מבצעים רכיבי Codec כאשר לא הרבה משתנה בין פריימים. לתוכן בתנועה נמוכה באופן לא מפתיע, גם וגם הצליחו אפילו יותר בתרחיש הזה, כאשר . זאת הודות לתכונה בשם , המאפשרת ל-AV1 לדלג על קידוד מחדש של חלקים במסך שלא השתנו. זה יעיל להפליא לשיתוף מסך סטטי או חצי סטטי. H.264 AV1 AV1 יצא בראש Intra Block Copy , תוכל לראות באיזו יעילות AV1 מטפל במצבים אלה בתנועה נמוכה, תוך שמירה על שימוש ברוחב פס נמוך בצורה מרשימה תוך שמירה על איכות חזותית גבוהה. בגרף הבא אבל... יש פשרה. AV1 עשוי לתת לך חזותיים ודחיסה טובים יותר, אבל . מראה זאת בבירור: השימוש במעבד של AV1 מטפס בהתמדה ככל שקצב הסיביות עולה, ועובר על H.264 בטווח ארוך. ל-H.264 יש יתרון גדול כאן הודות נרחבת, ששומרת על עומס המעבד שלו נמוך ויציב. הוא גם אוכל יותר מעבד התמונה הבאה להאצת חומרה , באופן מעניין, משתמש במעבד מאשר AV1 - בעקבות מגמה דומה אך עם פסגות גבוהות יותר. גם VP9 וגם AV1 מסתמכים על אלגוריתמים מורכבים כדי לספק איכות טובה, אבל יש לזה מחיר: הם פוגעים במעבד שלך. VP9 אפילו יותר היה טוויסט כשביקרתי מחדש . הפעם, למעשה נראו די יעילים - משתמשים בפחות מעבד מ-AV1, כפי שמוצג . בתוכן בתנועה נמוכה VP8 ו-VP9 בגרף הבא AV1, למרות שתוכנן מתוך מחשבה על שיתוף מסך, עדיין השתמש במעבד הכי הרבה. מַדוּעַ? כל אותן אופטימיזציות שעוזרות לו לדחוס וידאו בהילוך גבוה גם מוסיפות תקורה - אפילו כשלא קורה הרבה על המסך. סיבה גדולה לכך? . בעוד שהפענוח קל יחסית, הקידוד עדיין נעשה בעיקר בתוכנה - וזו משימה עתירת מעבד, במיוחד בתרחישים בזמן אמת כמו שיתוף מסך שבהם גם הקידוד וגם הפענוח מתרחשים ללא הרף. AV1 עדיין חסרה תמיכה נרחבת בקידוד חומרה זה המקום שבו הדברים מסתבכים עבור כמו מחשבים ניידים וטאבלטים. ללא האצת חומרה, רכיבי codec כמו AV1 יכולים לרוקן במהירות כוח ומשאבי חזיר - לא אידיאלי כשאתה בדרכים. עד שתמיכה טובה יותר בחומרה תהפוך לנפוצה יותר, התכונות המתקדמות של AV1 מגיעות עם עלות ביצועים די בולטת. מכשירים ניידים קודקים ורזולוציה: מה קורה כאשר אתה נותן עדיפות לקצב פריימים? עד כה, התוצאות ששיתפתי הגיעו מבדיקות ששמרו על רזולוציה קבועה. כאשר רוחב הפס הצטמצם, המערכת הייתה מגיבה על ידי הורדת - מה שהגיוני עבור דברים כמו תוכן סטטי או טקסט. אבל מה אם המטרה היא , גם אם זה אומר להקריב את הרזולוציה? קצב הפריימים לשמור על תנועה חלקה כדי לחקור את זה, הרצתי סט חדש של ניסויים שבהם WebRTC הוגדר לתעדוף במקום זאת. זה נעשה באמצעות הגדרת ב-WebRTC, המאפשרת לך לומר לדפדפן מה יותר חשוב - רזולוציה גבוהה או תנועה חלקה. קצב פריימים contentHint כיוונתי לשמור על קצב פריימים בקצב עקבי של לשנייה, שזוכה להכרה נרחבת כנקודה המתוקה לצפייה חלקה ונוחה. קשה להגיע לזה באופן עקבי - סטרימינג אדפטיבי אומר שתמיד יש קצת תנודות - אבל התוצאות הציעו תובנה חשובה לגבי האופן שבו כל codec מתמודד עם הפשרה הזו. 30 פריימים כדי לעזור לנתח התנהגות זו, הצגתי מדד חדש: פיקסלים שנשלחו לשנייה = קצב פריימים × רזולוציה זה נותן תמונה שלמה יותר מסתם הסתכלות על FPS או רזולוציה בלבד. זה מראה כמה נתונים חזותיים ה-Codec מספק למעשה בשנייה בתנאים שונים. עבור וידאו בהילוך גבוה, - ובפער ניכר. אפילו בקצבי סיביות נמוכים יותר, הוא הצליח להעביר משמעותית יותר פיקסלים לשנייה מכל codec אחר. זה מראה בבירור עד כמה AV1 מתמודד עם תוכן דינמי כאשר המערכת נמצאת בלחץ לשמור על קצב פריימים גבוה. אנא ראה : AV1 שוב יצא בראש את הגרף הבא כשעברתי לתוכן בתנועה נמוכה - כמו דף אינטרנט עם טקסט גולש - מגרש המשחקים נעשה קצת יותר רמה. הביצועים של כל ה-codec הפכו אחידים יותר כפי שתוכל למצוא . עם זאת, , במיוחד בקצבי סיביות גבוהים יותר. אופטימיזציות הדחיסה שלו עזרו לו לשמור על תפוקה חזקה מבלי להגדיל משמעותית את השימוש במשאבים. בתמונה הבאה AV1 עדיין שמר על יתרון מה המשמעות של כל זה בפועל? ובכן, אם מקרה השימוש שלך כולל ויזואליות דינמית בתנועה גבוהה - כמו הליכי וידאו, אנימציות חיות או הזרמת משחקים - , ו-AV1 מתגלה כבעל יכולת במיוחד בסביבה זו. תעדוף קצב פריימים יכול לעשות הבדל גדול אפילו עבור תוכן שזז לאט יותר, AV1 ממשיך להראות חוזק. בעוד שההבדל עשוי להיות קטן יותר, הוא מצליח בעקביות לשלוח יותר נתונים חזותיים - כלומר איכות טובה יותר באותו רוחב פס או נמוך יותר - הודות לאסטרטגיות הדחיסה המתקדמות שלו. בשני המקרים, המדד הוכיח את עצמו כשימושי להבנה כיצד רכיבי Codec מאזנים בין רזולוציה וקצב פריימים כאשר רוחב הפס מוגבל. והביצועים של AV1 בתנאים אלה מחזקים אותו עוד יותר כאפשרות המסוגלת ביותר - בתנאי שהמערכת שלך יכולה להתמודד עם דרישות המעבד הנוספות. "פיקסלים שנשלחו לשנייה" כמה נקייה התמונה? בוא נדבר PSNR מעבר לקצבי פריימים, רזולוציה ושימוש במעבד, יש עוד חלק חשוב אחד בפאזל שיתוף המסך: כאן נכנס לתמונה . כמה קרובה התמונה שהתקבלה למקור? Peak Signal-to-Noise Ratio (PSNR) PSNR הוא מדד בשימוש נרחב למדידת האיכות של וידאו דחוס. זה אומר לך כמה עיוות - או "רעש" - הוכנס במהלך הקידוד. זה נמדד , וכלל האצבע הוא פשוט: . PSNR גבוה אומר שהתמונה נראית כמעט בדיוק כמו המקור; ציון נמוך יותר אומר שיש השפלה גלויה יותר. בדציבלים (dB) כמה שיותר גבוה, יותר טוב כדי להכניס את זה להקשר, בדקתי ערכי PSNR על פני קודקים בשני תרחישים שונים: אחד שבו היא בראש סדר העדיפויות, ואחר שבו לוקח את ההובלה. שני הבדיקות השתמשו באותו כדי לשמור על עקביות. הרזולוציה קצב הפריימים תוכן וידאו בתנועה גבוהה בהגדרה זו, שבה הבהירות היא המוקד (גם אם הסרטון בסופו של דבר קצת קטוע), , והעניק חזותיים חדים עם עיוות מינימלי. זוהי בחירה חזקה כאשר החלקות אינה כה קריטית. H.264 ביצע ביצועים טובים במיוחד כאשר המטרה עוברת לשמירה על תנועה נוזלית, , במיוחד בקצבי סיביות גבוהים יותר. הוא מצליח לשמר את איכות התמונה גם תוך כדי דחיסה אגרסיבית כדי לפגוע ביעדי קצב פריימים. AV1 יוצא קדימה בעוד שההבדלים ב-PSNR בין רכיבי codec אינם תמיד דרמטיים, הם מדגישים את שאתה עושה בעת בחירת ה-codec. חלקם מתעדפים חדות; אחרים שואפים לתנועה חלקה - ובהתאם למקרה השימוש שלך, אחד עשוי להיות מתאים יותר מהשני. הפשרות אחר כך הרצתי שוב את אותם מבחנים, הפעם באמצעות - משהו שבאמת מדגיש את החשיבות של רזולוציה ובהירות. תוכן טקסט מגולגל כשמתעדף תנועה, ערכי PSNR בכל ה-codec נראים די דומים. התוכן לא משתנה הרבה, כך שלהבדלים באסטרטגיית הדחיסה אין השפעה רבה על איכות התמונה הכוללת. כאן הדברים נעשים מעניינים. עם רזולוציה בראש סדר העדיפויות, שאר ה-codec - במיוחד בקצבי סיביות גבוהים יותר. הביצועים שלו כאן יוצאי דופן. AV1 מושך הרבה לפני מַדוּעַ? AV1 כולל אופטימיזציות ספציפיות לטיפול בתוכן סטטי וחוזר על עצמו כמו טקסט. אלה מאפשרים לו לשמור על , להימנע מחפצים, ולדחוס בצורה יעילה יותר. זה הופך את AV1 לבחירה פנטסטית עבור מקרי שימוש כמו שיתוף מסמכים או הדרכה על קוד - בכל מקום שהפרטים . נאמנות תמונה גבוהה יותר החדים והקריאים באמת חשובים בקיצור, PSNR עוזר להדגיש מימד עדין אך חשוב של איכות שיתוף המסך. בין אם אתה נותן עדיפות לתנועה או חדות, ההבנה כיצד מתנהגים רכיבי Codec תחת אילוצים שונים מאפשרת לך לבחור את המתאים לתפקיד. מה הקטע עם QP? הבנת דחיסה לעומת איכות גורם חשוב נוסף באיכות שיתוף המסך הוא משהו שנקרא , או . אם אי פעם תהיתם מה שולט בכמה פרטים הולכים לאיבוד במהלך הדחיסה, זהו זה. פרמטר Quantization QP במילים פשוטות, . QP אומר למקודד באיזו אגרסיביות לדחוס את הסרטון אומר פחות דחיסה ואיכות תמונה טובה יותר. QP נמוך פירושו יותר דחיסה - מה שחוסך רוחב פס, אבל יכול לגרום לסרטון להיראות גרוע יותר. QP גבוה בעוד PSNR נותן לנו תוצאה - כמה איכות התמונה נשמרה - . אז הסתכלתי על שניהם. QP אומר לנו למה המקודד כיוון במחקר זה: נמשכו מדדי WebRTC סטנדרטיים. ערכי QP נמדד לאחר מעשה על ידי השוואת כל פריים מקורי לגרסה שהתקבלה. PSNR כאן הדברים נעשו מעניינים. , כלומר הוא שמר על איכות התמונה בצורה הטובה ביותר - אבל היו לו גם מהקודקים האחרים. זה נראה סותר במבט ראשון. ל-AV1 היו את ציוני ה-PSNR הטובים ביותר ערכי QP גבוהים עד פי ארבעה אבל הנה המלכוד: , כך שהערכים אינם ניתנים להשוואה ישירה. QP של 50 ב-codec אחד לא אומר בהכרח אותה רמת דחיסה כמו QP של 50 באחר. כל codec מגדיר ומטפל ב-QP בצורה שונה ובכל זאת, מגמות QP אומרות לנו משהו שימושי. בכל ה-codec, ראיתי שככל . זה הגיוני - עם יותר רוחב פס זמין, ה-codec יכולים להרשות לעצמם להפחית את הדחיסה ולשפר את איכות התמונה. שרוחב הפס גדל, ה-QP פוחת אז למרות שאנחנו לא יכולים לסדר את מספרי QP זה לצד זה על פני קודקים, הם עדיין מראים כיצד כל codec מתאים באופן דינמי את הדחיסה על סמך תנאי הרשת הזמינים. בשורה התחתונה: . אבל מעקב אחר איך זה משתנה עם רוחב הפס נותן תובנות מועילות לגבי מה שהמקודד עושה מאחורי הקלעים. ובשילוב עם PSNR, זה נותן תמונה מלאה יותר של התנהגות ה-codec. QP הוא לא ציון איכות - זה הגדרה מחשבות אחרונות: מה כל זה אומר עבור שיתוף מסך WebRTC לאחר צלילה לעומק כיצד WebRTC מתפקד מתחת למכסה המנוע, דבר אחד ברור: - והבחירה הטובה ביותר תלויה בסדר העדיפויות ובסביבה שלך. לא כל ה-codec נוצרו שווים להלן הנקודות העיקריות מהניסויים שלי: AV1: האיכות הטובה ביותר, העלות הגבוהה ביותר AV1 סיפק באופן עקבי את , בין אם שיתפתי וידאו בתנועה מהירה או טקסט גלילה לאט. הדחיסה והאופטימיזציות המתקדמות שלו הופכות אותו ליעיל להפליא - אבל זה כרוך במחיר. AV1 , ומכיוון שתמיכת החומרה עדיין מדביקה את הקצב, הוא לא אידיאלי למכשירים בעלי הספק נמוך או ניידים. האיכות הוויזואלית הטובה ביותר רעב למעבד עדיין H.264: The Solid All-Rounder אם אתה מחפש , H.264 הוא עדיין בחירה מצוינת. הוא זוכה לתמיכה רחבה, מואצת בחומרה ברוב הפלטפורמות ועושה עבודה טובה כמעט בכל תרחיש - במיוחד כאשר משאבי מערכת או חיי סוללה מהווים דאגה. איזון בין ביצועים ויעילות התוכן חשוב יותר ממה שאתה חושב לסוג התוכן שאתה משתף יש על הביצועים. וידאו בתנועה גבוהה דורש הרבה יותר מהמעבד ורוחב הפס שלך מאשר תוכן סטטי כמו מסמכים או טקסט. בחירת ה-codec הנכון - וההגדרות הנכונות - עבור התוכן שלך יכולה לעשות הבדל עצום באיכות ובשימוש במשאבים. השפעה עצומה השימוש במעבד הוא לא רק הערת שוליים הודות לפלאגין כרום מותאם אישית שבניתי, הצלחתי למדוד את השימוש במעבד במדויק במהלך שיתוף המסך. התוצאות הראו , מה שהופך חשוב במיוחד במכשירים ניידים או בסביבות רגישות לאנרגיה. הבדלים גדולים במידת הדרישות של כל codec מה הלאה? לאן המחקר הזה יכול להגיע הניסוי הזה פתח את הדלת לכמה צעדים מרגשים הבאים. כאן אני חושב שעבודה עתידית יכולה להשפיע עוד יותר: בדיקה במכשירים ניידים עד כה, כל הבדיקות בוצעו במחשב שולחני - אבל שיתוף מסך נפוץ באותה מידה (אם לא יותר) . בדיקה של ביצועי ה-codec הללו בנייד תיתן תמונה מלאה יותר, במיוחד במונחים של היענות וצריכת חשמל. בטלפונים ובטאבלטים יעילות אנרגטית אם כבר מדברים על כוח - קודקים לא רק שורפים מעבד, הם גם שורפים . מחקר עתידי צריך לבחון אילו רכיבי Codec הם , במיוחד עבור הפעלות שיתוף מסך ארוכות במכשירים ניידים. את חיי הסוללה הכי יעילים באנרגיה כוונון Codec המופעל על ידי AI תאר לעצמך אם WebRTC יכול להתאים אוטומטית את הגדרות ה-Codec על סמך התוכן הנוכחי ומהירות הרשת שלך. , למצוא באופן דינמי את האיזון המושלם בין איכות וביצועים בזמן אמת. AI יכול לאפשר את זה עוטף את זה בחירת Codec היא יותר מסתם החלטה טכנית - היא משפיעה ישירות על של חווית שיתוף המסך שלך. בין אם אתה בונה כלי לשיחות ועידה בווידאו, פלטפורמת שיתוף פעולה, או סתם מייעל את זרימות העבודה שלך, הבנה כיצד מתנהגים ה-codec הללו בתנאים שונים יכולה לעזור לך לקבל החלטות חכמות ויעילות יותר. האיכות, החלקות והשימוש במשאבים ככל ש-WebRTC ממשיך להתפתח, כך גם הכלים והטכניקות שסביבו ימשיכו להתפתח. אני מקווה שהצלילה העמוקה הזו תעזור לאחרים להבין טוב יותר מה קורה מאחורי הקלעים - וכיצד להפיק את המרב מחסנית שיתוף המסך שלהם. רוצה לחקור את הנתונים בעצמך? אם אתה סקרן לחפור עמוק יותר לתוך התוצאות או להפעיל ניתוח משלך, הפכתי את מערך הנתונים המלא ממחקר זה לזמין כאן: הורד את מערך הנתונים ב- Kaggle הוא כולל מדדים גולמיים עבור קצב פריימים, רזולוציה, PSNR, QP, שימוש במעבד ועוד - הכל מאורגן לפי codec, סוג תוכן ומצב רוחב פס. אל תהסס להשתמש בו עבור ניסויים משלך, השוואת ביצועים, או סתם כדי לחקור כיצד WebRTC מתנהג בתרחישים שונים.