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

François Beaufort

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

מפענח וידאו AV1

הערה: נאלצנו לדחות את התמיכה במפענח וידאו ב-AV1 ל-[Chrome 70] בגלל בקישור ל-MP4.

Chromestatus tracker | באג ב-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']
  }]);

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

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

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

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

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

בקיצור, כך ה-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 בודקים את תכונת ה-API ב-Chrome 69 למחשב (ChromeOS, Linux, Mac ו-Windows).

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

הכוונה היא לניסוי | 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.

PTS/DTS

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

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

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

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

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

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

handler של כוונות מדיה

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

באג ב-Chromium

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

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

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

כוונת הוצאה משימוש והסרה | Chromestatus tracker | באג ב-Chromium