- Chrome admite la decodificación de video AV1.
- Ahora está disponible la consulta qué esquemas de encriptación se admiten a través de EME.
- Los desarrolladores web pueden realizar experimentos y consultar si se puede aplicar una determinada política de HDCP.
- Las extensiones de fuente de medios ahora usan PTS para rangos almacenados en búfer y valores de duración.
- Los usuarios de Android Go pueden abrir el audio, el video y las imágenes descargados en Chrome.
- Se quitan los eventos detenidos para los elementos multimedia que usan ECM.
Decodificador de videos de AV1
Seguimiento de Chromestatus | Error de Chromium
EME: Consulta la compatibilidad con esquemas de encriptación
Algunas plataformas o sistemas de claves solo admiten el modo CENC, mientras que otros solo admiten el modo CBCS. pero hay otras empresas que pueden admitirlas. Estos dos esquemas de encriptación son incompatibles, por lo que los desarrolladores web deben poder tomar decisiones inteligentes sobre qué contenido entregar.
Para evitar tener que determinar la plataforma en la que se encuentran para verificar la compatibilidad con esquemas de encriptación “conocidos”, se agrega una clave encryptionScheme nueva al diccionario MediaKeySystemMediaCapability para permitir que los sitios web especifiquen el esquema de encriptación que se podría usar en las extensiones de medios encriptados (EME).
La nueva clave encryptionScheme puede ser uno de dos valores:
'cenc'Muestra completa del modo AES-CTR y encriptación de submuestra NAL de video.'cbcs'Encriptación de patrón NAL de video parcial en modo AES-CBC.
Si no se especifica, indica que se acepta cualquier esquema de encriptación. Ten en cuenta que Borrar clave siempre admite el esquema 'cenc'.
En el siguiente ejemplo, se muestra cómo consultar dos opciones de configuración con esquemas de encriptación diferentes. 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 se consulta una configuración con dos esquemas de encriptación diferentes. En ese caso, Chrome descartará cualquier objeto de capacidades que no pueda admitir, por lo que la configuración acumulada puede contener un esquema de 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']
}]);
Intent de implementación | Seguimiento de Chromestatus | Error de Chromium
EME: Verificación de la política HDCP
Actualmente, HDCP es un requisito común de las políticas para transmitir en alta resolución de contenido protegido. Y los desarrolladores web que deseen aplicar una política HDCP deben esperar a que se complete el intercambio de licencias o comenzar a transmitir contenido con baja resolución. Esta es una situación triste que la API de verificación de políticas de HDCP pretende resolver.
Esta API propuesta permite a los desarrolladores web consultar si se puede aplicar una política HDCP determinada para que se pueda iniciar la reproducción en la resolución óptima a fin de obtener 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 necesidad de crear un MediaKeySession ni recuperar una licencia real. Tampoco es necesario que MediaKeys se adjunte a ningún elemento de audio o video.
La API de Policy Check de HDCP funciona con solo llamar
a mediaKeys.getStatusForPolicy() con un objeto que tenga una clave minHdcpVersion
y un valor válido. Si HDCP está disponible en la versión especificada, la promesa que se muestra se resuelve con una 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 admite la verificación de políticas de HDCP (p.ej., Clear Key System), se rechaza la promesa.
En resumen, así es como funciona la API por ahora. 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 recibir comentarios de desarrolladores web, ya agregamos la función de la API de HDCP Policy Check en Chrome 69 para computadoras (ChromeOS, Linux, Mac y Windows).
La prueba finalizó correctamente en noviembre de 2018.
Intent de experimentar | Seguimiento de Chromestatus | Error de Chromium
Cumplimiento de MSE PTS/DTS
Los rangos de almacenamiento en búfer y los valores de duración ahora se informan mediante intervalos de marca de tiempo de presentación (PTS), en lugar de intervalos de marca de tiempo de decodificación (DTS) en Extensiones de fuente de contenido multimedia (MSE).
Cuando MSE era nueva, la implementación de Chrome se probó con WebM y MP3, algunos formatos de transmisión multimedia en los que no había ninguna distinción entre PTS y DTS. Y funcionó bien hasta que se agregó ISO BMFF (también conocido como MP4). Este contenedor suele contener transmisiones de tiempo de presentación desordenadas en comparación con transmisiones de tiempo de decodificación (para códecs como H.264), lo que causa que DTS y PTS difieran. Eso hizo que Chrome informara (por lo general, solo un poco) rangos de búfer y valores de duración diferentes de los esperados. Este nuevo comportamiento se lanzará de forma gradual en Chrome 69 y hará que su implementación de ECM cumpla con la especificación de MSE.
Este cambio afecta a MediaSource.duration (y, en consecuencia, a HTMLMediaElement.duration), SourceBuffer.buffered (y, en consecuencia, HTMLMediaElement.buffered) y SourceBuffer.remove(start, end).
Si no sabes qué método se usa para informar rangos almacenados en búfer y valores de duración, puedes ir a la página interna chrome://media-internals y buscar “ChunkDemuxer: buffering by PTS” o “ChunkDemuxer: buffering by DTS” en los registros.
Intent de implementación | Error de Chromium
Control de intents de vista de contenido multimedia en Android Go
Android Go es una versión ligera de Android diseñada para smartphones básicos. Con ese fin, no necesariamente se envía con algunas aplicaciones de visualización de contenido multimedia, por lo que, si un usuario intenta abrir un video descargado, por ejemplo, no tendrá ninguna aplicación para controlar ese intent.
Para solucionar este problema, Chrome 69 en Android Go ahora detecta intents de visualización de contenido multimedia para que los usuarios puedan ver el audio, las imágenes y los videos descargados. En otras palabras, toma el lugar de las aplicaciones de visualización faltantes.
Ten en cuenta que esta función de Chrome está habilitada en todos los dispositivos Android que ejecutan Android O y versiones posteriores con 1 GB de RAM o menos.
Eliminación de eventos "detenidos" para elementos multimedia que usan ECM
Se genera un evento "detenido" en un elemento multimedia si la descarga de datos multimedia no progresa durante aproximadamente 3 segundos. Cuando se usan extensiones de fuente de medios (MSE), la aplicación web administra la descarga, y el elemento multimedia no está al tanto de su progreso. Esto provocó que Chrome generara eventos "detenidos" en momentos inapropiados cuando el sitio web no agregó nuevos fragmentos de datos multimedia con SourceBuffer.appendBuffer() en los últimos 3 segundos.
Como los sitios web deciden adjuntar grandes cantidades de datos con baja frecuencia, esto no es un indicador útil sobre el estado del almacenamiento en búfer. Quitar los eventos "detenidos" para los elementos multimedia que usan MSE aclara la confusión y hace que Chrome se ajuste mejor a la especificación de MSE. Ten en cuenta que los elementos multimedia que no usan ECM continuarán generando eventos "detenidos" como lo hacen en la actualidad.
Intent de dar de baja y quitar | Seguimiento de Chromestatus | Error de Chromium