עדכוני מדיה ב-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 System), ההבטחה תידחה.

בקיצור, כך פועל ה-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.

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

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

הערכים וטווחי משך הזמן ששמורים במאגר נתונים מדווחים עכשיו לפי מרווחים של presentation Time Stamp (PTS) ולא לפי מרווחים Decode Time Stamp (DTS) בקטע Media Source תוספים (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 ואילך, עם זיכרון RAM בנפח של 1GB או פחות.

באג ב-Chromium

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

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

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

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