- Chrome admite la decodificación de video AV1.
- Consultar qué esquemas de encriptación son compatibles con EME ya está disponible.
- Los desarrolladores web pueden consultar si se puede aplicar una política HDCP determinada.
- Las extensiones de fuente de medios ahora usan PTS para rangos de almacenamiento en búfer y valores de duración.
- Los usuarios de Android Go pueden abrir el audio, el video y las imágenes que se hayan descargado en Chrome.
- Se quitan los eventos inactivos de los elementos multimedia que utilizan ECM.
Decodificador de video de AV1
Seguimiento de Chromestatus | Error de Chromium
EME: Consulta de compatibilidad con esquemas de encriptación
Algunas plataformas o sistemas clave solo admiten el modo CENC, mientras que otras solo admiten Modo CBCS. Sin embargo, otros pueden admitir ambos. Estos dos esquemas de encriptación son incompatibles, por lo que los desarrolladores web deben ser capaces de tomar decisiones inteligentes sobre qué contenido publicar.
Para evitar tener que determinar en qué plataforma se encuentra para verificar si es "conocida"
compatibilidad con el esquema de encriptación, se agrega una nueva clave encryptionScheme en
MediaKeySystemMediaCapability diccionario para permitir que los sitios web especifiquen
qué esquema de encriptación podría usarse en extensiones de medios encriptados (EME)
La nueva clave encryptionScheme puede ser uno de dos valores:
'cenc'Encriptación de muestra completa y NAL de video en modo AES-CTR.'cbcs'Encriptación parcial de patrón NAL de video en modo AES-CBC.
Si no se especifica, indica que cualquier esquema de encriptación es aceptable. Nota
que Clear Key siempre admite el esquema 'cenc'.
En el siguiente ejemplo, se muestra cómo consultar dos parámetros de configuración con diferentes esquemas de encriptación. En este caso, solo se elegirá una.
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']
},
]);
En el siguiente ejemplo, solo una configuración con dos opciones de encriptación esquemas se consultan. En ese caso, Chrome descartará cualquier objeto de capacidad no admite, por lo que la configuración acumulada puede contener una encriptación o ambos.
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']
}]);
Intención de implementación | Seguimiento de Chromestatus | Error de Chromium
EME: Verificación de las políticas de HDCP
En la actualidad, HDCP es un requisito de política común para transmitir contenido en alta resolución. de contenido protegido. Y a los desarrolladores web que quieren aplicar de manera forzosa una política HDCP debe esperar a que se complete el intercambio de licencias o comenzar a transmitir contenido con baja resolución. Esta es una situación lamentable que la política de HDCP Check API pretende resolver.
Esta API propuesta permite a los desarrolladores web consultar si una política HDCP determinada
para que la reproducción pueda iniciarse con la resolución óptima
la mejor experiencia del usuario. Consiste en un método simple para consultar el estado de
una clave hipotética asociada con una política HDCP, sin la necesidad de crear una
MediaKeySession o busca una licencia real. No es necesario que MediaKeys
a cualquier elemento de audio o video.
La API de Policy Check de HDCP funciona con solo llamar
mediaKeys.getStatusForPolicy() por un objeto que tiene una clave minHdcpVersion
y uno válido. Si HDCP está disponible en la versión especificada, el valor devuelto
se resuelve con un MediaKeyStatus de 'usable'. De lo contrario, la promesa
se resuelve con otros valores de error de MediaKeyStatus, como
'output-restricted' o 'output-downscaled'. Si el sistema de claves no
admitir la Verificación de políticas de HDCP en absoluto (p.ej., borrar el sistema de claves), la promesa se rechaza.
En pocas palabras, a continuación, te mostramos cómo funciona la API por el momento. Consulta el ejemplo oficial para probar todas las versiones de 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...
});
Disponible para pruebas de origen
Para obtener comentarios de los desarrolladores web, anteriormente agregamos la Política de HDCP Verifica la función de la API en Chrome 69 para computadoras (ChromeOS, Linux, Mac y Windows).
La prueba finalizó correctamente en noviembre de 2018.
Intención de experimentar | Seguimiento de Chromestatus | Error de Chromium
Cumplimiento de EMS PTS/DTS
La marca de tiempo de la presentación ahora informa los rangos y los valores de duración almacenados en búfer (PTS) en lugar de intervalos de decodificación de marcas de tiempo (DTS) en los contenido multimedia Extensiones de fuente (ECM)
Cuando el ECM era nuevo, la implementación de Chrome se probó con WebM y MP3, algunas formatos de transmisión multimedia en los que no había distinción entre PTS y DTS. Y funcionaba bien hasta que se agregó ISO BMFF (también conocido como MP4). Este contenedor frecuentemente contiene secuencias de tiempo de presentación desordenadas frente a transmisiones de tiempo de decodificación (para como H.264), lo que causa que DTS y PTS difieran. Eso provocó Chrome informará (por lo general solo un poco) diferentes rangos de almacenamiento en búfer y duración de los esperados. Este nuevo comportamiento se lanzará de forma gradual en Chrome 69 y hacer que su implementación de ECM cumpla con la especificación de ECM.
Este cambio afecta a MediaSource.duration (y, en consecuencia,
HTMLMediaElement.duration), SourceBuffer.buffered (y, en consecuencia,
HTMLMediaElement.buffered) y SourceBuffer.remove(start, end).
Si no sabes qué método se usa para informar la duración y los rangos almacenados en búfer
puedes ir a la página interna de chrome://media-internals y buscar
"ChunkDemuxer: almacenamiento en búfer por PTS" o "ChunkDemuxer: almacenamiento en búfer por DTS" en la
los registros del sistema operativo.
Intención de implementación | Error de Chromium
Manejo de intents de vista de contenido multimedia en Android Go
Android Go es una versión ligera de Android diseñada para el nivel básico smartphones. Por eso, no necesariamente se envía con cierto nivel de visualización Así, si un usuario intenta abrir un video descargado, por ejemplo, no tendrá ninguna aplicación para manejar ese intent.
Para solucionar este problema, Chrome 69 en Android Go ahora detecta intents de visualización de contenido multimedia, por lo que los usuarios pueden ver el audio, las imágenes y los videos que se descargaron. En otras palabras, lleva el lugar de las aplicaciones de visualización faltantes.
Ten en cuenta que esta función de Chrome está habilitada en todos los dispositivos que ejecuten Android Android O y versiones posteriores con 1 GB de RAM o menos.
Eliminación de "Detenido" eventos para elementos de medios con ECM
Un problema "detenido" evento se genera en un elemento multimedia si la descarga de datos multimedia
no pudo progresar durante unos 3 segundos. Cuando use extensiones de fuente de medios
(ECM), la app web administra la descarga y el elemento multimedia no tiene conocimiento de
su progreso. Esto provocó que Chrome mostrara el estado "detenido" eventos con
veces el sitio web no ha agregado nuevos fragmentos de datos de medios con
SourceBuffer.appendBuffer() en los últimos 3 segundos.
Como los sitios web deciden agregar grandes bloques de datos con una frecuencia baja, no es un indicador útil del estado del almacenamiento en búfer. Quitando el contenido "detenido" eventos para elementos multimedia que usan el ECM aclara la confusión y alinea a Chrome más con la especificación de ECM. Ten en cuenta que los elementos multimedia que no usan ECM siguen generando "atascado" eventos como lo hacen en la actualidad.
Intención de dar de baja y quitar | Seguimiento de Chromestatus | Error de Chromium