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