הפעלת סרטונים ללא הפרעות בכל המכשירים.
בניסוי עם Media Capabilities API, ב-YouTube ראינו עלייה של 7.1% ב-MTBR, עם ירידה של 0.4% בלבד ברזולוציה הממוצעת של הסרטונים המוצגים.
הבעיה
בדרך כלל לאתרי מדיה יש כמה וריאנטים של כל סרטון שהם יכולים להציג למשתמשים, כשהם מקודדים בקצבי פריימים, רזולוציות ורכיבי Codec שונים. עד לאחרונה, מפתחי אתרים היו צריכים להסתמך רק על isTypeSupported() או על canPlayType() כדי לקבוע אם אפשר היה להפעיל כל וריאנט בדפדפן של משתמש ספציפי.
אנשי המפתח אמנם הודיעו למפתח אם אפשר להפעיל את המדיה, אבל לא סיפקנו אינדיקציה לגבי איכות ההפעלה, למשל אם יהיו הפרעות בפריים או שהסוללה של המכשיר תתרוקן. בלי המידע הזה, המפתחים היו צריכים ליצור היוריסטיקה משלהם או פשוט להניח שאם המכשיר יוכל להפעיל שילוב של קודק/רזולוציה, הוא יוכל לעשות זאת בצורה חלקה וביעילות בצריכת החשמל.
לרוב, הבעיה גרמה לחוויה לא טובה אצל משתמשים עם מכשירים פחות מתקדמים.
הפתרון
ה-API של Media Capabilities מאפשר לאתרים לקבל מידע נוסף על ביצועי פענוח הווידאו של הלקוח, ולקבל החלטה מושכלת לגבי הקודק והרזולוציה שהם רוצים לשלוח למשתמש. באופן ספציפי, ה-API מספק למפתח הערכה של החלקות והיעילות האנרגטית של קודק מסוים ושילוב רזולוציה מסוים. כך המפתח יכול להימנע מתרחישים שבהם הלקוח צפוי ליהנות מחוויית הפעלה לא טובה.
ב-Chrome, Media Capabilities API משתמש במדדים מהפעלות קודמות כדי לחזות אם הפעלות עתידיות באותו קודק ובאותה רזולוציה יפוענחו בצורה חלקה.
מקרה לדוגמה: YouTube
הצוות של YouTube השתמש ב-API Media Capabilities כדי למנוע מהאלגוריתם של קצב העברת הנתונים המותאם לבחור באופן אוטומטי רזולוציות שהמכשיר לא הצליח להפעיל בצורה חלקה.
משתמשים שהיו חלק מקבוצת הניסוי הבחינו באופן קולקטיבי בבאג-נתונים בתדירות נמוכה יותר (הזמן הממוצע בין rebuffers או MTBR, עלה ב-7.1%), בעוד שהרזולוציה הממוצעת, שנמדדת לפי גובה הסרטון, הוצגה לקבוצה המסכמת הצטמצמה ב-0.4% בלבד. העלייה המשמעותית ב-MTBR עם ההפחתה המקבילה הקטנה ברזולוציה הממוצעת מצביעה על כך שהשינוי הזה שיפר באופן משמעותי את האיכות אצל קבוצה קטנה של משתמשים שחוויית המשתמש שלהם בעבר הייתה גרועה.
הטמעת ממשק API של יכולות מדיה באתר שלך
אתם מוזמנים לעיין בדוגמה הרשמית כדי לראות איך עובד ה-Decoding Info API.