עדכוני מדיה ב-Chrome 69

François Beaufort

• Chrome תומך בפענוח סרטוני AV1.
• עכשיו אפשר לשלוח שאילתות לגבי אילו סכמות הצפנה נתמכות באמצעות EME.
• מפתחי אתרים יכולים להתנסות בשליחת שאילתות כדי לבדוק אם ניתן לאכוף מדיניות HDCP מסוימת.
• תוספים של מקורות מדיה משתמשים עכשיו ב-PTS לטווח האחסון במטמון ולערכים של משך הזמן.
• משתמשי Android Go יכולים לפתוח ב-Chrome קובצי אודיו, סרטונים ותמונות שהורדתם.
• אירועים של סטאלס ברכיבי מדיה שמשתמשים ב-MSE יוסרו.

מפענח וידאו AV1

מעקב אחר סטטוס העדכונים של Chrome | באג ב-Chromium

EME: שליחת שאילתה לגבי תמיכה בסכימת הצפנה

פלטפורמות מסוימות או מערכות מפתחות תומכות רק במצב CENC, ואחרות תומכות רק במצב CBCS. יש גם שירותים שתומכים בשניהם. שתי סכימות ההצפנה האלה אינן תואמות, ולכן מפתחי אתרים צריכים להיות מסוגלים לקבל החלטות חכמות לגבי התוכן שיוצג.

כדי להימנע מהצורך לקבוע באיזו פלטפורמה הם נמצאים כדי לבדוק אם יש תמיכה בסכימת הצפנה 'ידועה', מפתח encryptionScheme חדש נוסף במילון של MediaKeySystemMediaCapability כדי לאפשר לאתרים לציין באיזו סכמת הצפנה אפשר להשתמש בתוספים של מדיה מוצפנת (EME).

המפתח החדש encryptionScheme יכול להיות אחד משני ערכים:

• 'cenc' הצפנה של נתוני NAL של וידאו ושל נתונים לדוגמה מלאים במצב AES-CTR.
• 'cbcs' הצפנה חלקית של תבניות NAL של וידאו במצב AES-CBC.

אם לא צוין, המשמעות היא שכל סכימה להצפנה תקפה. חשוב לזכור ש-Clear Key תמיד תומך בסכמה 'cenc'.

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

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
    {
      label: 'configuration using the "cenc" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      }],
      initDataTypes: ['keyids']
    },
    {
      label: 'configuration using the "cbcs" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      }],
      initDataTypes: ['keyids']
    },
  ]);

בדוגמה הבאה, מתבצעת שאילתה רק על הגדרה אחת עם שתי שיטות הצפנה שונות. במקרה כזה, Chrome יטמיע רק את אובייקט היכולות שהוא תומך בו, כך שההגדרה המצטברת עשויה לכלול רק תוכנית הצפנה אחת או את שתיהן.

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
    videoCapabilities: [
      { // A video capability using the "cenc" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      },
      { // A video capability using the "cbcs" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      },
    ],
    audioCapabilities: [
      { // An audio capability using the "cenc" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      },
      { // An audio capability using the "cbcs" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      },
    ],
    initDataTypes: ['keyids']
  }]);

כוונה להטמעה | מעקב אחרי סטטוס ההטמעה ב-Chrome | באג ב-Chromium

EME: בדיקת מדיניות HDCP

כיום, HDCP היא דרישת מדיניות נפוצה לסטרימינג ברזולוציה גבוהה של תוכן מוגן. בנוסף, מפתחי אתרים שרוצים לאכוף מדיניות HDCP צריכים להמתין עד שהחלפת הרישיונות תסתיים או להתחיל לשדר תוכן ברזולוציה נמוכה. זהו מצב עצוב שHDCP Policy Check API נועד לפתור.

ה-API המוצע הזה מאפשר למפתחי אתרים לבדוק אם אפשר לאכוף מדיניות HDCP מסוימת כדי שאפשר יהיה להתחיל את ההפעלה ברזולוציה האופטימלית לחוויית המשתמש הטובה ביותר. הוא מורכב משיטה פשוטה לשליחת שאילתה לגבי סטטוס של מפתח היפותטי שמשויך למדיניות HDCP, בלי צורך ליצור MediaKeySession או לאחזר רישיון אמיתי. אין צורך לצרף את MediaKeys לרכיבי אודיו או וידאו.

כדי להשתמש ב-HDCP Policy Check API, פשוט קוראים ל-mediaKeys.getStatusForPolicy() עם אובייקט שיש לו מפתח minHdcpVersion וערכים תקינים. אם HDCP זמין בגרסה שצוינה, ההתחייבות שתוחזר תיפתר עם MediaKeyStatus של 'usable'. אחרת, ההבטחה נפתר עם ערכי שגיאה אחרים של MediaKeyStatus, כמו 'output-restricted' או 'output-downscaled'. אם מערכת המפתחות לא תומכת בכלל בבדיקת מדיניות HDCP (למשל, מערכת Clear Key), ההתחייבות תידחה.

בקצרה, כך פועל ה-API כרגע. בדוגמה הרשמית אפשר לראות את כל הגרסאות של HDCP.

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

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {

  // Get status for HDCP 2.2
  return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
  .then(status => {
    if (status !== 'usable')
      return Promise.reject(status);

    console.log('HDCP 2.2 can be enforced.');
    // TODO: Fetch high resolution protected content...
  });
})
.catch(error => {
  // TODO: Fallback to fetch license or stream low-resolution content...
});

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

כדי לקבל משוב ממפתחי אתרים, הוספנו בעבר את התכונה HDCP Policy Check API ל-Chrome 69 למחשב (ב-ChromeOS,‏ Linux,‏ Mac ו-Windows).

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

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

תאימות ל-MSE PTS/DTS

ערכי משך הזמן והטווחים שנשמרו במטמון מדווחים עכשיו לפי מרווחי חותמת זמן הצגה (PTS) ולא לפי מרווחי חותמת זמן פענוח (DTS) בתוספים של מקורות מדיה (MSE).

כש-MSE היה חדש, ההטמעה ב-Chrome נבדקה בפורמטים של WebM ו-MP3, וגם בפורמטים מסוימים של סטרימינג של מדיה שבהם לא היה הבדל בין PTS ל-DTS. והוא עבד מצוין עד להוספת ISO BMFF (נקרא גם MP4). בדרך כלל הקונטיינר הזה מכיל זרמי זמן שלא תואמים לפענוח מול מקודדים (לדוגמה, קודקים כמו H.264), שגורמים להבדלים ב-DTS וב-PTS. כתוצאה מכך, דיווח Chrome על טווחי זמן אחסון זמני ועל ערכי משך זמן שונים מהצפוי (בדרך כלל רק במעט). ההתנהגות החדשה הזו תושק בהדרגה ב-Chrome 69, והטמעת ה-MSE תהיה תואמת למפרט MSE.

השינוי הזה משפיע על MediaSource.duration (וכתוצאה מכך על HTMLMediaElement.duration), על SourceBuffer.buffered (וכתוצאה מכך על HTMLMediaElement.buffered) ועל SourceBuffer.remove(start, end).

אם אתם לא בטוחים באיזו שיטה נעשה שימוש כדי לדווח על טווחי זמן אחסון במטמון ועל ערכי משך זמן, תוכלו לעבור לדף הפנימי chrome://media-internals ולחפש ביומני המערכת את האפשרויות 'ChunkDemuxer: buffering by PTS' או 'ChunkDemuxer: buffering by DTS'.

כוונה להטמעה | באג ב-Chromium

הטיפול בכוונות צפייה במדיה ב-Android Go

Android Go היא גרסה קלה של Android שמיועדת לסמארטפונים ברמה בסיסית. לשם כך, לא בטוח שתקבלו אפליקציות מסוימות לצפייה במדיה, כך שאם משתמש מנסה לפתוח סרטון שהורד למשל, לא תהיה לו אפליקציות לטיפול בכוונה הזו.

כדי לפתור את הבעיה, בגרסת Chrome 69 ל-Android Go יש עכשיו הקשבה לכוונות צפייה במדיה, כדי שהמשתמשים יוכלו לצפות בתמונות, בסרטונים ובאודיו שהורדתם. במילים אחרות, היא מחליפת את האפליקציות החסרות לצפייה.

לתשומת ליבכם: התכונה הזו של Chrome מופעלת בכל מכשירי Android עם מערכת הפעלה Android O ואילך, עם 1GB של RAM או פחות.

באג ב-Chromium

הסרה של אירועים 'תקוע' עבור רכיבי מדיה באמצעות MSE

האירוע 'השהיה' מופעל ברכיב מדיה אם הורדת נתוני המדיה לא התקדמה במשך כ-3 שניות. כשמשתמשים ב-Media Source Extensions‏ (MSE), אפליקציית האינטרנט מנהלת את ההורדה ורכיב המדיה לא מודע להתקדמות שלה. כתוצאה מכך, Chrome דיווח על אירועים מסוג 'השהיה' בזמנים לא מתאימים, בכל פעם שהאתר לא הוסיף קטעי נתוני מדיה חדשים עם SourceBuffer.appendBuffer() ב-3 השניות האחרונות.

מאחר שאתרים עשויים להחליט לצרף קטעי נתונים גדולים בתדירות נמוכה, זהו לא אות שימושי לגבי בריאות האחסון במטמון. הסרת אירועים "נתקעים" לרכיבי מדיה באמצעות MSE מבהירה את הבלבול ומשפרת את ההתאמה של Chrome למפרט ה-MSE. חשוב לזכור שרכיבי מדיה שלא משתמשים ב-MSE ימשיכו לשלוח אירועים מסוג 'השהיה', כמו שהם עושים היום.

Intent הוצאה משימוש והסרה | מעקב אחר Chromestatus | באג ב-Chromium