תמיד הייתי סקרן לדעת איך קודקים שונים מסתדרים כשמדובר בשיתוף מסך דרך WebRTC. אז, החלטתי לברר בעצמי על ידי בדיקת ארבעת הנפוצים ביותר: VP8, VP9, H.264 ו-AV1.
כדי לוודא שהתוצאות היו מוצקות, ערכתי בדיקות על פני מגוון סוגי תוכן ותנאי רשת. לא הסתמכתי רק על רשמים חזותיים - השתמשתי בהשוואות מסגרת למסגרת, חישבתי יחס אות לרעש שיא (PSNR), והוצאתי נתונים סטטיסטיים מפורטים של WebRTC כדי לקבל תצוגה ברורה מונעת נתונים.
כדי ללכת צעד קדימה, אפילו בניתי תוסף Chrome מותאם אישית שעוקב אחר השימוש במעבד במהלך הקידוד והפענוח. זה נתן לי מבט טוב על האופן שבו כל codec משפיע על ביצועי המערכת - כי האיכות מעולה, אבל לא אם המחשב שלך בוער ומנסה לעמוד בקצב.
הסתכלתי על מדדי מפתח כמו קצב סיביות, קצב פריימים, רזולוציה, קוונטיזציה (QP), PSNR ועומס מעבד. בהתבסס על כל זה, הבאתי כמה המלצות מעשיות שיעזרו לכל מי שמנסה לייעל את שיתוף המסך של WebRTC עבור מקרי השימוש שלו.
לגבי הניסוי
מדוע שיתוף מסך אינו פשוט כפי שהוא נראה
אם אי פעם שיתפת את המסך שלך במהלך שיחת וידאו ושמת לב שהאיכות יורדת - או שהסרטון נהייה קטוע - אתה לא לבד. שמירה על שיתוף מסך חד וחלק הוא למעשה מסובך יותר ממה שזה נראה.
הבעיה? הכל עניין של מגוון. חלק מהתוכן עדיין, כמו חפיסת שקופיות או מסמך. פעמים אחרות, אתה משתף וידאו בהילוך גבוה. סוגי התוכן השונים הללו דורשים מה-codec דברים שונים מאוד. לדוגמה, וידאו בתנועה מהירה אוכלת המון רוחב פס, בעוד שתמונות סטטיות רגישות יותר לחפצי דחיסה שעלולים לגרום להן להיראות מטושטשות או חסומות.
זרקו בעיות אינטרנט בעולם האמיתי כמו אובדן מנות או ירידת רוחב פס, והדברים נעשים מבולגנים עוד יותר. לכן בחירת ה-Codec המתאים - וכוונון עדין של אופן פעולתו - חשובה כל כך כדי להפוך את שיתוף המסך לאיכותי וגם להגיב.
יש כבר הרבה מחקרים בחוץ על ביצועי ה-codec של וידאו בתרחישי סטרימינג כלליים. אבל לשיתוף מסך יש מוזרויות משלו. זה לא רק צפייה בסרטון - זה קשור לאינטראקציה בזמן אמת, וסוגי התוכן נמצאים בכל מקום. זה אומר שהמחקר הרגיל לא תמיד חל.
מה התכוונתי לעשות
רציתי לחפור עמוק יותר במקרה השימוש הספציפי הזה. המטרה שלי הייתה לראות איך מבצעים קודקים שונים בכל הקשור לשיתוף מסך, במיוחד תחת אילוצים של העולם האמיתי כמו סוגי תוכן משתנים ותנאי רשת בלתי צפויים.
כדי לעשות זאת, תכננתי שיטה להערכת איכות שיתוף המסך בצורה מדויקת ככל האפשר - לא רק על סמך איך זה נראה, אלא מגובה במדדים ונתונים מוצקים. לאורך הדרך, למדתי הרבה על אילו קודקים מחזיקים הכי טוב וכיצד לכוונן דברים לביצועים טובים יותר ביישומים בזמן אמת.
דבר אחד התברר במהירות: ביצועי שיתוף המסך תלויים באמת במה שאתה משתף. סרטון בקצב מהיר מתנהג בצורה שונה מאוד ממסמך סטטי או גלילה איטית בדף אינטרנט.
כדי לשמור על דברים הוגנים ועקביים, הקפדתי שכל מבחן רץ עם אותם תנאים בדיוק - אותה רזולוציה, אותה נקודת התחלה, ואותו משך. כך, יכולתי להיות בטוח שהתוצאות היו כולן על ביצועי ה-codec, לא על איזה משתנה מקרי.
יצרתי שני מקרי בדיקה שונים כדי לדמות מצבי שיתוף מסך בחיים האמיתיים:
- סרטון בהילוך גבוה - זה היה קליפ אמיתי של רוכבי אופנוע דוהרים ביער. הרבה תנועה מהירה, נוף מפורט וסביבה ויזואלית משתנה ללא הרף - מושלם לדחיפת גבולות הדחיסה.
- גלילה אוטומטית של טקסט - בניתי דף HTML פשוט עם טקסט ותמונות, ולאחר מכן השתמשתי ב-JavaScript כדי לגלול אותו במהירות קבועה. זה מחקה מקרה שימוש נפוץ כמו שיתוף מסמך או קריאה מדף אינטרנט.
שני סוגי התוכן האלה נתנו לי שילוב טוב כדי לבדוק איך כל codec מתמודד עם אתגרים שונים - מעמידה בקצב התנועה ועד לשמירה על בהירות בסצנות סטטיות יותר.
איך אני מגדיר הכל
כדי לבדוק כראוי את ה-codec, הייתי צריך הגדרה מוצקה שיכולה ללכוד הכל - גם מה שנשלח וגם מה שהתקבל. התחלתי עם כלי שנקרא webrtc-sandbox (אגב אתה יכול ללמוד על הכלי הזה ורבים נוספים בפוסט אחר שלי: " לימוד WebRTC בתרגול: הכלים וההדגמות הטובות ביותר "), שהוא מעולה להתעסקות עם רכיבים פנימיים של 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 שבדקתי.
הרעיון מאחורי זה די פשוט: כאשר יותר פיקסלים משתנים ממסגרת למסגרת (כמו בסרטון שזז במהירות), המערכת צריכה לעבוד קשה יותר. זה אומר שדרוש יותר רוחב פס, והמעבד שלך צריך להתאמץ יותר כדי לעמוד בקצב.
קח את AV1 , למשל. כשהשתמשתי בו כדי לשתף מסך של 1.5 מגה-פיקסל, רוחב הפס הנדרש השתנה מאוד בהתאם למה ששותף. במקרה אחד, שבו התוכן היה דינמי יותר, 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 מגה פיקסל) ואותו תוכן עבור כל בדיקה. השתמשתי בהגדרת contentHint WebRTC כדי לוודא שהרזולוציה נשארת נעולה בכל רחבי הלוח.
בתמונה הבאה , תוכל לראות כיצד רכיבי קודקים שונים מטפלים בתוכן בתנועה גבוהה ככל שרוחב הפס גדל. על ציר ה-x: קצב סיביות ב-Mbps. על ציר ה-y: קצב פריימים במסגרות לשנייה (fps).
הנה מה שבלט:
- H.264 ו- AV1 המשיכו קדימה ברגע שרוחב הפס הגיע ל-2 Mbps או יותר, שניהם מספקים 20+ פריימים לשנייה - חוויה חלקה שניתן להשיג אפילו בחיבור 3G הגון.
- VP8 ו- VP9 לא עמדו בקצב. הם ריחפו בערך במחצית מקצב הפריימים באותם תנאים, ובאמת היו צריכים 4 Mbps או יותר כדי להרגיש שמיש - מה שלא תמיד מציאותי ברשתות מתקדמות.
אחר כך עברתי לתוכן בתנועה נמוכה - דף טקסט שגולל באיטיות - כדי לראות כיצד מבצעים רכיבי Codec כאשר לא הרבה משתנה בין פריימים.
באופן לא מפתיע, גם H.264 וגם AV1 הצליחו אפילו יותר בתרחיש הזה, כאשר AV1 יצא בראש . זאת הודות לתכונה בשם Intra Block Copy , המאפשרת ל-AV1 לדלג על קידוד מחדש של חלקים במסך שלא השתנו. זה יעיל להפליא לשיתוף מסך סטטי או חצי סטטי.
בגרף הבא , תוכל לראות באיזו יעילות AV1 מטפל במצבים אלה בתנועה נמוכה, תוך שמירה על שימוש ברוחב פס נמוך בצורה מרשימה תוך שמירה על איכות חזותית גבוהה.
אבל... יש פשרה.
AV1 עשוי לתת לך חזותיים ודחיסה טובים יותר, אבל הוא גם אוכל יותר מעבד . התמונה הבאה מראה זאת בבירור: השימוש במעבד של AV1 מטפס בהתמדה ככל שקצב הסיביות עולה, ועובר על H.264 בטווח ארוך. ל-H.264 יש יתרון גדול כאן הודות להאצת חומרה נרחבת, ששומרת על עומס המעבד שלו נמוך ויציב.
VP9 , באופן מעניין, משתמש אפילו יותר במעבד מאשר AV1 - בעקבות מגמה דומה אך עם פסגות גבוהות יותר. גם VP9 וגם AV1 מסתמכים על אלגוריתמים מורכבים כדי לספק איכות טובה, אבל יש לזה מחיר: הם פוגעים במעבד שלך.
היה טוויסט כשביקרתי מחדש בתוכן בתנועה נמוכה . הפעם, VP8 ו-VP9 למעשה נראו די יעילים - משתמשים בפחות מעבד מ-AV1, כפי שמוצג בגרף הבא .
AV1, למרות שתוכנן מתוך מחשבה על שיתוף מסך, עדיין השתמש במעבד הכי הרבה. מַדוּעַ? כל אותן אופטימיזציות שעוזרות לו לדחוס וידאו בהילוך גבוה גם מוסיפות תקורה - אפילו כשלא קורה הרבה על המסך.
סיבה גדולה לכך? AV1 עדיין חסרה תמיכה נרחבת בקידוד חומרה . בעוד שהפענוח קל יחסית, הקידוד עדיין נעשה בעיקר בתוכנה - וזו משימה עתירת מעבד, במיוחד בתרחישים בזמן אמת כמו שיתוף מסך שבהם גם הקידוד וגם הפענוח מתרחשים ללא הרף.
זה המקום שבו הדברים מסתבכים עבור מכשירים ניידים כמו מחשבים ניידים וטאבלטים. ללא האצת חומרה, רכיבי codec כמו AV1 יכולים לרוקן במהירות כוח ומשאבי חזיר - לא אידיאלי כשאתה בדרכים. עד שתמיכה טובה יותר בחומרה תהפוך לנפוצה יותר, התכונות המתקדמות של AV1 מגיעות עם עלות ביצועים די בולטת.
קודקים ורזולוציה: מה קורה כאשר אתה נותן עדיפות לקצב פריימים?
עד כה, התוצאות ששיתפתי הגיעו מבדיקות ששמרו על רזולוציה קבועה. כאשר רוחב הפס הצטמצם, המערכת הייתה מגיבה על ידי הורדת קצב הפריימים - מה שהגיוני עבור דברים כמו תוכן סטטי או טקסט. אבל מה אם המטרה היא לשמור על תנועה חלקה , גם אם זה אומר להקריב את הרזולוציה?
כדי לחקור את זה, הרצתי סט חדש של ניסויים שבהם WebRTC הוגדר לתעדוף קצב פריימים במקום זאת. זה נעשה באמצעות הגדרת contentHint ב-WebRTC, המאפשרת לך לומר לדפדפן מה יותר חשוב - רזולוציה גבוהה או תנועה חלקה.
כיוונתי לשמור על קצב פריימים בקצב עקבי של 30 פריימים לשנייה, שזוכה להכרה נרחבת כנקודה המתוקה לצפייה חלקה ונוחה. קשה להגיע לזה באופן עקבי - סטרימינג אדפטיבי אומר שתמיד יש קצת תנודות - אבל התוצאות הציעו תובנה חשובה לגבי האופן שבו כל codec מתמודד עם הפשרה הזו.
כדי לעזור לנתח התנהגות זו, הצגתי מדד חדש:
פיקסלים שנשלחו לשנייה = קצב פריימים × רזולוציה
זה נותן תמונה שלמה יותר מסתם הסתכלות על FPS או רזולוציה בלבד. זה מראה כמה נתונים חזותיים ה-Codec מספק למעשה בשנייה בתנאים שונים.
עבור וידאו בהילוך גבוה, AV1 שוב יצא בראש - ובפער ניכר. אפילו בקצבי סיביות נמוכים יותר, הוא הצליח להעביר משמעותית יותר פיקסלים לשנייה מכל codec אחר. זה מראה בבירור עד כמה AV1 מתמודד עם תוכן דינמי כאשר המערכת נמצאת בלחץ לשמור על קצב פריימים גבוה. אנא ראה את הגרף הבא :
כשעברתי לתוכן בתנועה נמוכה - כמו דף אינטרנט עם טקסט גולש - מגרש המשחקים נעשה קצת יותר רמה. הביצועים של כל ה-codec הפכו אחידים יותר כפי שתוכל למצוא בתמונה הבאה . עם זאת, AV1 עדיין שמר על יתרון , במיוחד בקצבי סיביות גבוהים יותר. אופטימיזציות הדחיסה שלו עזרו לו לשמור על תפוקה חזקה מבלי להגדיל משמעותית את השימוש במשאבים.
מה המשמעות של כל זה בפועל?
ובכן, אם מקרה השימוש שלך כולל ויזואליות דינמית בתנועה גבוהה - כמו הליכי וידאו, אנימציות חיות או הזרמת משחקים - תעדוף קצב פריימים יכול לעשות הבדל גדול , ו-AV1 מתגלה כבעל יכולת במיוחד בסביבה זו.
אפילו עבור תוכן שזז לאט יותר, AV1 ממשיך להראות חוזק. בעוד שההבדל עשוי להיות קטן יותר, הוא מצליח בעקביות לשלוח יותר נתונים חזותיים - כלומר איכות טובה יותר באותו רוחב פס או נמוך יותר - הודות לאסטרטגיות הדחיסה המתקדמות שלו.
בשני המקרים, המדד "פיקסלים שנשלחו לשנייה" הוכיח את עצמו כשימושי להבנה כיצד רכיבי Codec מאזנים בין רזולוציה וקצב פריימים כאשר רוחב הפס מוגבל. והביצועים של AV1 בתנאים אלה מחזקים אותו עוד יותר כאפשרות המסוגלת ביותר - בתנאי שהמערכת שלך יכולה להתמודד עם דרישות המעבד הנוספות.
כמה נקייה התמונה? בוא נדבר PSNR
מעבר לקצבי פריימים, רזולוציה ושימוש במעבד, יש עוד חלק חשוב אחד בפאזל שיתוף המסך: כמה קרובה התמונה שהתקבלה למקור? כאן נכנס לתמונה Peak Signal-to-Noise Ratio (PSNR) .
PSNR הוא מדד בשימוש נרחב למדידת האיכות של וידאו דחוס. זה אומר לך כמה עיוות - או "רעש" - הוכנס במהלך הקידוד. זה נמדד בדציבלים (dB) , וכלל האצבע הוא פשוט: כמה שיותר גבוה, יותר טוב . PSNR גבוה אומר שהתמונה נראית כמעט בדיוק כמו המקור; ציון נמוך יותר אומר שיש השפלה גלויה יותר.
כדי להכניס את זה להקשר, בדקתי ערכי PSNR על פני קודקים בשני תרחישים שונים: אחד שבו הרזולוציה היא בראש סדר העדיפויות, ואחר שבו קצב הפריימים לוקח את ההובלה. שני הבדיקות השתמשו באותו תוכן וידאו בתנועה גבוהה כדי לשמור על עקביות.
בהגדרה זו, שבה הבהירות היא המוקד (גם אם הסרטון בסופו של דבר קצת קטוע), H.264 ביצע ביצועים טובים במיוחד , והעניק חזותיים חדים עם עיוות מינימלי. זוהי בחירה חזקה כאשר החלקות אינה כה קריטית.
כאשר המטרה עוברת לשמירה על תנועה נוזלית, AV1 יוצא קדימה , במיוחד בקצבי סיביות גבוהים יותר. הוא מצליח לשמר את איכות התמונה גם תוך כדי דחיסה אגרסיבית כדי לפגוע ביעדי קצב פריימים.
בעוד שההבדלים ב-PSNR בין רכיבי codec אינם תמיד דרמטיים, הם מדגישים את הפשרות שאתה עושה בעת בחירת ה-codec. חלקם מתעדפים חדות; אחרים שואפים לתנועה חלקה - ובהתאם למקרה השימוש שלך, אחד עשוי להיות מתאים יותר מהשני.
אחר כך הרצתי שוב את אותם מבחנים, הפעם באמצעות תוכן טקסט מגולגל - משהו שבאמת מדגיש את החשיבות של רזולוציה ובהירות.
כשמתעדף תנועה, ערכי PSNR בכל ה-codec נראים די דומים. התוכן לא משתנה הרבה, כך שלהבדלים באסטרטגיית הדחיסה אין השפעה רבה על איכות התמונה הכוללת.
כאן הדברים נעשים מעניינים. עם רזולוציה בראש סדר העדיפויות, AV1 מושך הרבה לפני שאר ה-codec - במיוחד בקצבי סיביות גבוהים יותר. הביצועים שלו כאן יוצאי דופן.
מַדוּעַ? AV1 כולל אופטימיזציות ספציפיות לטיפול בתוכן סטטי וחוזר על עצמו כמו טקסט. אלה מאפשרים לו לשמור על נאמנות תמונה גבוהה יותר , להימנע מחפצים, ולדחוס בצורה יעילה יותר. זה הופך את AV1 לבחירה פנטסטית עבור מקרי שימוש כמו שיתוף מסמכים או הדרכה על קוד - בכל מקום שהפרטים החדים והקריאים באמת חשובים .
בקיצור, PSNR עוזר להדגיש מימד עדין אך חשוב של איכות שיתוף המסך. בין אם אתה נותן עדיפות לתנועה או חדות, ההבנה כיצד מתנהגים רכיבי Codec תחת אילוצים שונים מאפשרת לך לבחור את המתאים לתפקיד.
מה הקטע עם QP? הבנת דחיסה לעומת איכות
גורם חשוב נוסף באיכות שיתוף המסך הוא משהו שנקרא פרמטר Quantization , או QP . אם אי פעם תהיתם מה שולט בכמה פרטים הולכים לאיבוד במהלך הדחיסה, זהו זה.
במילים פשוטות, QP אומר למקודד באיזו אגרסיביות לדחוס את הסרטון .
- QP נמוך אומר פחות דחיסה ואיכות תמונה טובה יותר.
- QP גבוה פירושו יותר דחיסה - מה שחוסך רוחב פס, אבל יכול לגרום לסרטון להיראות גרוע יותר.
בעוד PSNR נותן לנו תוצאה - כמה איכות התמונה נשמרה - QP אומר לנו למה המקודד כיוון . אז הסתכלתי על שניהם.
במחקר זה:
- ערכי QP נמשכו מדדי WebRTC סטנדרטיים.
- PSNR נמדד לאחר מעשה על ידי השוואת כל פריים מקורי לגרסה שהתקבלה.
כאן הדברים נעשו מעניינים. ל-AV1 היו את ציוני ה-PSNR הטובים ביותר , כלומר הוא שמר על איכות התמונה בצורה הטובה ביותר - אבל היו לו גם ערכי QP גבוהים עד פי ארבעה מהקודקים האחרים. זה נראה סותר במבט ראשון.
אבל הנה המלכוד: כל codec מגדיר ומטפל ב-QP בצורה שונה , כך שהערכים אינם ניתנים להשוואה ישירה. QP של 50 ב-codec אחד לא אומר בהכרח אותה רמת דחיסה כמו QP של 50 באחר.
ובכל זאת, מגמות QP אומרות לנו משהו שימושי. בכל ה-codec, ראיתי שככל שרוחב הפס גדל, ה-QP פוחת . זה הגיוני - עם יותר רוחב פס זמין, ה-codec יכולים להרשות לעצמם להפחית את הדחיסה ולשפר את איכות התמונה.
אז למרות שאנחנו לא יכולים לסדר את מספרי QP זה לצד זה על פני קודקים, הם עדיין מראים כיצד כל codec מתאים באופן דינמי את הדחיסה על סמך תנאי הרשת הזמינים.
בשורה התחתונה: QP הוא לא ציון איכות - זה הגדרה . אבל מעקב אחר איך זה משתנה עם רוחב הפס נותן תובנות מועילות לגבי מה שהמקודד עושה מאחורי הקלעים. ובשילוב עם PSNR, זה נותן תמונה מלאה יותר של התנהגות ה-codec.
מחשבות אחרונות: מה כל זה אומר עבור שיתוף מסך 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 מתנהג בתרחישים שונים.
