- Chrome은 AV1 동영상 디코딩을 지원합니다.
- 이제 EME를 통해 지원되는 암호화 스키마를 쿼리할 수 있습니다.
- 웹 개발자는 특정 HDCP 정책을 적용할 수 있는지 쿼리해 볼 수 있습니다.
- 이제 미디어 소스 확장 프로그램에서 버퍼링된 범위 및 재생 시간 값에 PTS를 사용합니다.
- Android Go 사용자는 다운로드한 오디오, 동영상, 이미지를 Chrome에서 열 수 있습니다.
- MSE를 사용하는 미디어 요소의 지연된 이벤트가 삭제되었습니다.
AV1 동영상 디코더
Chromestatus Tracker | Chromium 버그
EME: 암호화 스키마 지원 쿼리
일부 플랫폼 또는 키 시스템은 CENC 모드만 지원하고 다른 플랫폼 또는 키 시스템은 CBCS 모드만 지원합니다. 두 가지를 모두 지원할 수도 있습니다. 이 두 가지 암호화 체계는 호환되지 않으므로 웹 개발자가 제공할 콘텐츠를 지능적으로 선택할 수 있어야 합니다.
'알려진' 암호화 스킴 지원을 확인하기 위해 현재 설치된 플랫폼을 확인할 필요가 없도록, 새로운 encryptionScheme 키가 MediaKeySystemMediaCapability 사전에 추가되어 웹사이트에서 암호화된 미디어 확장 프로그램 (EME)에서 사용할 수 있는 암호화 스키마를 지정할 수 있습니다.
새 encryptionScheme 키는 다음 두 값 중 하나일 수 있습니다.
'cenc'AES-CTR 모드 전체 샘플 및 동영상 NAL 서브 샘플 암호화'cbcs'AES-CBC 모드 부분 동영상 NAL 패턴 암호화
지정되지 않으면 모든 암호화 스키마가 허용됨을 나타냅니다. 키 지우기는 항상 '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 Policy Check API로 해결하려는 슬픈 상황입니다.
이 제안된 API를 사용하면 웹 개발자가 특정 HDCP 정책을 적용할 수 있는지 쿼리하여 최상의 사용자 환경을 위한 최적의 해상도에서 재생을 시작할 수 있습니다. MediaKeySession를 만들거나 실제 라이선스를 가져올 필요 없이 HDCP 정책과 관련된 가상 키의 상태를 쿼리하는 간단한 메서드로 구성됩니다. MediaKeys를 오디오 또는 동영상 요소에 연결할 필요도 없습니다.
HDCP Policy Check API는 minHdcpVersion 키와 유효한 값이 있는 객체로 mediaKeys.getStatusForPolicy()를 호출하기만 하면 작동합니다. 지정된 버전에서 HDCP를 사용할 수 있는 경우 반환된 프로미스는 'usable'의 MediaKeyStatus로 확인됩니다. 그렇지 않으면 프로미스가 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...
});
오리진 트라이얼 사용 가능
Google에서는 웹 개발자의 의견을 듣기 위해 이전에 데스크톱용 Chrome 69 (ChromeOS, Linux, Mac, Windows)에 HDCP Policy Check API 기능을 추가했습니다.
무료 체험이 2018년 11월에 종료되었습니다.
실험 의도 | Chromestatus Tracker | Chromium 버그
MSE PTS/DTS 규정 준수
버퍼링된 범위 및 지속 시간 값은 이제 미디어 소스 확장 프로그램(MSE)의 DTS (Decode Time Stamp) 간격이 아닌 프레젠테이션 타임 스탬프 (PTS) 간격으로 보고됩니다.
MSE가 처음이었을 때 Chrome의 구현은 PTS와 DTS 간에 차이가 없는 일부 미디어 스트림 형식인 WebM 및 MP3를 대상으로 테스트되었습니다. 그리고 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'를 검색해 보세요.
Android Go에서 미디어 뷰 인텐트 처리
Android Go는 초급 스마트폰용으로 설계된 Android의 경량 버전입니다. 이를 위해 미디어 보기 애플리케이션은 일부 미디어 보기 애플리케이션과 함께 제공되지 않을 수도 있습니다. 따라서 사용자가 예를 들어 다운로드된 동영상을 열려고 해도 이 인텐트를 처리할 애플리케이션이 없습니다.
이 문제를 해결하기 위해 Android Go의 Chrome 69에서는 이제 사용자가 다운로드한 오디오, 동영상, 이미지를 볼 수 있도록 미디어 보기 인텐트를 수신 대기합니다. 즉, 누락된 보기 애플리케이션을 대신합니다.
이 Chrome 기능은 RAM이 1GB 이하인 Android O 이상을 실행하는 모든 Android 기기에서 사용 설정됩니다.
MSE를 사용하여 미디어 요소의 '중단'된 이벤트 제거
미디어 데이터 다운로드가 약 3초 동안 진행되지 않으면 미디어 요소에서 '중단' 이벤트가 발생합니다. 미디어 소스 확장 프로그램(MSE)을 사용할 때 웹 앱은 다운로드를 관리하지만 미디어 요소는 다운로드 진행 상황을 인식하지 못합니다. 이로 인해 웹사이트에서 지난 3초 동안 SourceBuffer.appendBuffer()를 사용하여 새 미디어 데이터 청크를 추가하지 않을 때마다 Chrome에서 부적절한 시간에 '중단'된 이벤트가 발생했습니다.
웹사이트에서 많은 양의 데이터를 낮은 빈도로 추가할 수 있으므로 이는 버퍼링 상태에 관한 유용한 신호가 아닙니다. MSE를 사용하는 미디어 요소의 '중단된' 이벤트를 삭제하면 혼란이 없어지고 Chrome이 MSE 사양에 맞게 조정됩니다. MSE를 사용하지 않는 미디어 요소는 지금처럼 계속해서 '중단'된 이벤트를 발생시킵니다.