עדכוני מדיה ב-Chrome בגרסה 63/64

François Beaufort
François Beaufort

יכולות מדיה – Decoding Info API

כיום, מפתחי אתרים מסתמכים על isTypeSupported() או על canPlayType() כדי לדעת באופן כללי אם אפשר לפענח מדיה מסוימת או לא. אבל השאלה האמיתית היא: "איך הביצועים שלו יהיו במכשיר הזה?"

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

בקצרה, כך פועל Decoding Info API כרגע. כדאי לעיין בדוגמה הרשמית.

const mediaConfig = {
  type: 'media-source', // or 'file'
  audio: {
    contentType: 'audio/webm; codecs=opus',
    channels: '2', // audio channels used by the track
    bitrate: 132266, // number of bits used to encode a second of audio
    samplerate: 48000 // number of samples of audio carried per second
  },
  video: {
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    width: 1920,
    height: 1080,
    bitrate: 2646242, // number of bits used to encode a second of video
    framerate: '25' // number of frames used in one second
  }
};

navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
  console.log('This configuration is' +
      (result.supported ? '' : ' NOT') + ' supported,' +
      (result.smooth ? '' : ' NOT') + ' smooth and' +
      (result.powerEfficient ? '' : ' NOT') + ' power efficient.');
});

אפשר לנסות הגדרות מדיה שונות עד שמוצאים את ההגדרה הטובה ביותר (smooth ו-powerEfficient) ולהשתמש בה כדי להפעיל את סטרימינג המדיה המתאים. דרך אגב, ההטמעה הנוכחית של Chrome מבוססת על נתוני ההפעלה שתועדו בעבר. הערך של smooth מוגדר כ-true כשאחוז הפריימים שהוחמצו קטן מ-10%, והערך של powerEfficient מוגדר כ-true כשיותר מ-50% מהפריימים מקודדים על ידי החומרה. תמיד נחשבים ליעילים מבחינת צריכת החשמל.

מומלץ להשתמש בקטע קוד דומה לזה שבהמשך כדי לזהות את הזמינות ולחזור לגרסה הנוכחית של ההטמעה בדפדפנים שלא תומכים ב-API הזה.

function isMediaConfigSupported(mediaConfig) {

  const promise = new Promise((resolve, reject) => {
    if (!('mediaCapabilities' in navigator)) {
      return reject('MediaCapabilities API not available');
    }
    if (!('decodingInfo' in navigator.mediaCapabilities)) {
      return reject('Decoding Info not available');
    }
    return resolve(navigator.mediaCapabilities.decodingInfo(mediaConfig));
  });

  return promise.catch(_ => {
    let fallbackResult = {
      supported: false,
      smooth: false, // always false
      powerEfficient: false // always false
    };
    if ('video' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.video.contentType);
      if (!fallbackResult.supported) {
        return fallbackResult;
      }
    }
    if ('audio' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.audio.contentType);
    }
    return fallbackResult;
  });
}

זמינה לגרסאות מקור לניסיון

כדי לקבל משוב רב ככל האפשר ממפתחים שמשתמשים ב-Decoding Info API (חלק מ-Media Capabilities) בשטח, הוספנו את התכונה הזו בעבר ל-Chrome 64 כגרסת מקור לניסיון.

תקופת הניסיון הסתיימה בהצלחה באפריל 2018.

Intent to Experiment | Intent to Ship | Chromestatus Tracker | באג ב-Chromium

הפעלת סרטוני HDR ב-Windows 10

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

השוואה בין SDR מדומה ל-HDR (כדי לראות HDR אמיתי נדרש מסך HDR)
הדמיה של SDR לעומת HDR (כדי לראות איכות HDR אמיתית, נדרש מסך HDR)

כיוון שהפעלה של 10 ביט ב-VP9 Profile 2 נתמכת עכשיו ב-Chrome ל-Windows 10 Fall Update, ולעדכון ליוצרים בסתיו, יש ב-Chrome גם תמיכה בהפעלת סרטונים באיכות HDR כשWindows 10 במצב HDR. הערה טכנית: מעכשיו, ב-Chrome 64 יש תמיכה בפרופיל הצבעים scRGB, שמאפשר הפעלה של מדיה באיכות HDR.

כדי לבדוק את זה, אפשר לצפות בתוכנית The World in HDR in 4K (ULTRA HD) ב-YouTube ולבדוק אם היא פועלת באיכות HDR לפי הגדרת האיכות בנגן YouTube.

הגדרת האיכות של נגן YouTube עם HDR
הגדרת האיכות של נגן YouTube עם HDR

בינתיים, כל מה שצריך הוא עדכון Windows 10 Fall Creator, כרטיס מסך ותצוגה שתואמים ל-HDR (למשל, כרטיס מסדרת NVIDIA 10, טלוויזיה או צג של LG HDR) ולהפעיל את מצב HDR בהגדרות התצוגה של Windows.

מפתחי אתרים יכולים לזהות את מגוון הצבעים המשוער שנתמך במכשיר הפלט באמצעות שאילתת המדיה color-gamut האחרונה, ואת מספר הסיביות המשמשים להצגת צבע במסך באמצעות screen.colorDepth. לדוגמה, זוהי אחת הדרכים שבהן אפשר להשתמש בהן כדי לזהות אם יש תמיכה ב-VP9 HDR:

// Detect if display is in HDR mode and if browser supports VP9 HDR.
function canPlayVp9Hdr() {

  // TODO: Adjust VP9 codec string based on your video encoding properties.
  return (window.matchMedia('(color-gamut: p3)').matches &&
      screen.colorDepth >= 48 &&
      MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01"'))
}

צריך לעדכן את מחרוזת ה-codec של VP9 עם פרופיל 2 שמועברת אל isTypeSupported() בדוגמה שלמעלה, בהתאם למאפייני קידוד הווידאו שלכם.

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

רישיונות קבועים ל-Windows ול-Mac

רישיון קבוע ב-Encrypted Media Extensions‏ (EME): הרישיון יכול להישמר במכשיר כדי שאפליקציות יוכלו לטעון אותו לזיכרון בלי לשלוח בקשה נוספת לרישיון לשרת. כך מתאפשרת תמיכה בהפעלה אופליין ב-EME.

עד עכשיו, ChromeOS ו-Android היו הפלטפורמות היחידות שתומכות ברישיונות מתמידים. זה כבר לא נכון. עכשיו אפשר להפעיל תוכן מוגן באמצעות EME כשהמכשיר במצב אופליין גם ב-Chrome 64 ל-Windows ול-Mac.

const config = [{
  sessionTypes: ['persistent-license'],
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(access => {
  // User will be able to watch encrypted content while being offline when
  // license is stored locally on device and loaded later.
})
.catch(error => {
  // Persistent licenses are not supported on this platform yet.
});

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

  1. עוברים לכתובת https://biograf-155113.appspot.com/ttt/episode-2/.
  2. לוחצים על 'הגדרה כזמין במצב אופליין' וממתינים להורדת הסרטון.
  3. משביתים את החיבור לאינטרנט.
  4. לוחצים על הלחצן 'הפעלה' ונהנים מהסרטון.

ברירת המחדל של טעינת המדיה מראש היא 'מטא-נתונים'

בהתאם להטמעות של דפדפנים אחרים, עכשיו ב-Chrome למחשב מוגדר ערך ברירת המחדל של טעינה מראש לרכיבים <video> ו-<audio> כ-"metadata", כדי לצמצם את רוחב הפס ואת השימוש במשאבים. החל מגרסה 64 של Chrome, ההתנהגות החדשה הזו חלה רק במקרים שבהם לא מוגדר ערך טעינה מראש. שימו לב שהרמז של מאפיין ההטענה מראש מבוטל כשהקוד MediaSource מצורף לאלמנט המדיה, כי האתר מטפל בהטענה מראש שלו.

במילים אחרות, ערך הטעינה מראש של <video> הוא עכשיו "metadata", בעוד שערך הטעינה מראש של <video preload="auto"> נשאר "auto". כדאי לנסות את הדוגמה הרשמית.

Intent to Ship | Chromestatus Tracker | באג ב-Chromium

אם הערך של playbackRate לא נתמך, מתרחשת חריגה

בעקבות שינוי במפרט ה-HTML, כשהערך ב-playbackRate של רכיבי מדיה מוגדר לערך שלא נתמך על ידי Chrome (למשל ערך שלילי), תתבצע קריאה של "NotSupportedError" DOMException ב-Chrome 63.

const audio = document.querySelector('audio');
try {
  audio.playbackRate = -1;
} catch(error) {
  console.log(error.message); // Failed to set the playbackRate property
}

דרך אגב, ההטמעה הנוכחית של Chrome מפעילה את החריג הזה כשהערך של playbackRate הוא שלילי, קטן מ-0.0625 או גדול מ-16. כדאי לנסות את הדוגמה הרשמית כדי לראות את התכונה בפעולה.

Intent to Ship | Chromestatus Tracker | באג ב-Chromium

אופטימיזציה של טראק הווידאו ברקע

הצוות של Chrome תמיד מנסה למצוא דרכים חדשות לשיפור חיי הסוללה, ו-Chrome 63 לא יוצא מן הכלל.

אם הסרטון לא מכיל טראקים של אודיו, הוא יושהה באופן אוטומטי כשהוא יופעל ברקע (למשל, בכרטיסייה לא גלויה) במחשב עם Chrome (ב-Windows,‏ Mac,‏ Linux ו-ChromeOS). זהו המשך של שינוי דומה שהוחל רק על סרטוני MSE ב-Chrome 62.

באג ב-Chromium

הסרת ההשתקה במהירות הפעלה קיצונית

לפני Chrome 64, הצליל הושתק כשהערך של playbackRate היה נמוך מ-0.5 או גבוה מ-4, כי האיכות הייתה נמוכה מאוד. מכיוון ש-Chrome עבר לגישת Waveform-Similarity-Overlap-Add (WSOLA) בגלל פגיעה באיכות, אין יותר צורך להשתיק את הצלילים. זה אומר שאפשר עכשיו להשמיע צליל ממש לאט ומהיר מאוד.

באג ב-Chromium