Actualizaciones multimedia en Chrome 63/64

François Beaufort
François Beaufort
GitHub

Funciones de medios: API de Decoding Info

Actualmente, los desarrolladores web dependen de isTypeSupported() o canPlayType() para saber de forma vaga si se puede decodificar algún contenido multimedia. Sin embargo, la pregunta real debería ser: "¿Qué tan bien funcionaría en este dispositivo?".

Esto es exactamente uno de los problemas que la propuesta de Media Capabilities quiere resolver: una API para consultar al navegador sobre las capacidades de decodificación del dispositivo en función de información como los códecs, el perfil, la resolución, las tasas de bits, etcétera. Expondría información como si la reproducción debería ser fluida y eficiente en cuanto al consumo de energía en función de las estadísticas de reproducción anteriores registradas por el navegador.

En resumen, así es como funciona la API de Decoding Info por el momento. Consulta la muestra oficial.

const mediaConfig = {
  type: 'media-source', // or 'file'
  audio: {
    contentType: 'audio/webm; codecs=opus',
    channels: '2', // audio channels used by the track
    bitrate: 132266, // number of bits used to encode a second of audio
    samplerate: 48000 // number of samples of audio carried per second
  },
  video: {
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    width: 1920,
    height: 1080,
    bitrate: 2646242, // number of bits used to encode a second of video
    framerate: '25' // number of frames used in one second
  }
};

navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
  console.log('This configuration is' +
      (result.supported ? '' : ' NOT') + ' supported,' +
      (result.smooth ? '' : ' NOT') + ' smooth and' +
      (result.powerEfficient ? '' : ' NOT') + ' power efficient.');
});

Puedes probar diferentes configuraciones de medios hasta encontrar la mejor (smooth y powerEfficient) y usarla para reproducir el flujo de medios adecuado. Por cierto, la implementación actual de Chrome se basa en la información de reproducción registrada anteriormente. Define smooth como verdadero cuando el porcentaje de fotogramas descartados es inferior al 10%, mientras que powerEfficient es verdadero cuando el hardware decodifica más del 50% de los fotogramas. Los marcos pequeños siempre se consideran eficientes en cuanto al consumo de energía.

Te recomiendo que uses un fragmento similar al que se muestra a continuación para detectar la disponibilidad y volver a tu implementación actual para los navegadores que no admiten esta API.

function isMediaConfigSupported(mediaConfig) {

  const promise = new Promise((resolve, reject) => {
    if (!('mediaCapabilities' in navigator)) {
      return reject('MediaCapabilities API not available');
    }
    if (!('decodingInfo' in navigator.mediaCapabilities)) {
      return reject('Decoding Info not available');
    }
    return resolve(navigator.mediaCapabilities.decodingInfo(mediaConfig));
  });

  return promise.catch(_ => {
    let fallbackResult = {
      supported: false,
      smooth: false, // always false
      powerEfficient: false // always false
    };
    if ('video' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.video.contentType);
      if (!fallbackResult.supported) {
        return fallbackResult;
      }
    }
    if ('audio' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.audio.contentType);
    }
    return fallbackResult;
  });
}

Disponible para pruebas de origen

Para obtener la mayor cantidad posible de comentarios de los desarrolladores que usan la API de Decoding Info (parte de Media Capabilities) en el campo, anteriormente agregamos esta función en Chrome 64 como prueba de origen.

La prueba finalizó correctamente en abril de 2018.

Intención de experimentar | Intención de lanzar | Seguimiento de Chromestatus | Error de Chromium

Reproducción de video HDR en Windows 10

Los videos de alto rango dinámico (HDR) tienen un mayor contraste, lo que revela sombras precisas y detalladas, y zonas brillantes deslumbrantes con más claridad que nunca. Además, la compatibilidad con la amplia gama de colores significa que los colores son más vibrantes.

Comparación simulada de SDR y HDR (para ver el HDR real, se requiere una pantalla HDR)
Comparación simulada de SDR y HDR (para ver el HDR real, se requiere una pantalla HDR)

Como ahora se admite la reproducción de 10 bits del perfil 2 de VP9 en Chrome para la actualización de Fall Creators de Windows 10, Chrome también admite la reproducción de video HDR cuando Windows 10 está en modo HDR. En cuanto a los aspectos técnicos, Chrome 64 ahora admite el perfil de color scRGB, que a su vez permite que el contenido multimedia se reproduzca en HDR.

Para probarlo, mira The World in HDR in 4K (ULTRA HD) en YouTube y verifica que se reproduzca en HDR en la configuración de calidad del reproductor de YouTube.

Configuración de calidad del reproductor de YouTube con HDR
Ajuste de calidad del reproductor de YouTube con HDR

Por ahora, solo necesitas la actualización Fall Creators Update de Windows 10, una tarjeta gráfica y una pantalla compatibles con HDR (p.ej., una tarjeta de la serie 10 de NVIDIA, una TV o un monitor HDR de LG) y activar el modo HDR en la configuración de pantalla de Windows.

Los desarrolladores web pueden detectar la gama de colores aproximada que admite el dispositivo de salida con la reciente consulta de medios color-gamut y la cantidad de bits que se usan para mostrar un color en la pantalla con screen.colorDepth. Aquí tienes una forma de usarlos para detectar si se admite VP9 HDR, por ejemplo:

// Detect if display is in HDR mode and if browser supports VP9 HDR.
function canPlayVp9Hdr() {

  // TODO: Adjust VP9 codec string based on your video encoding properties.
  return (window.matchMedia('(color-gamut: p3)').matches &&
      screen.colorDepth >= 48 &&
      MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01"'))
}

La cadena de códec VP9 con el perfil 2 que se pasa a isTypeSupported() en el ejemplo anterior debe actualizarse según las propiedades de codificación de video.

Ten en cuenta que aún no es posible definir colores HDR en CSS, canvas, imágenes ni contenido protegido. El equipo de Chrome está trabajando en ello. ¡No te pierdas las novedades!

Licencias persistentes para Windows y Mac

Una licencia persistente en Encrypted Media Extensions (EME) significa que la licencia se puede conservar en el dispositivo para que las aplicaciones puedan cargarla en la memoria sin enviar otra solicitud de licencia al servidor. Así es como se admite la reproducción sin conexión en EME.

Hasta ahora, ChromeOS y Android eran las únicas plataformas que admitían licencias persistentes. Ya no es así. Ahora también es posible reproducir contenido protegido a través de EME cuando el dispositivo está sin conexión en Chrome 64 para Windows y Mac.

const config = [{
  sessionTypes: ['persistent-license'],
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(access => {
  // User will be able to watch encrypted content while being offline when
  // license is stored locally on device and loaded later.
})
.catch(error => {
  // Persistent licenses are not supported on this platform yet.
});

Puedes probar las licencias persistentes por tu cuenta. Para ello, consulta la PWA de Sample Media y sigue estos pasos:

  1. Ve a https://biograf-155113.appspot.com/ttt/episode-2/.
  2. Haz clic en “Disponible sin conexión” y espera a que se descargue el video.
  3. Desactiva la conexión a Internet.
  4. Haz clic en el botón "Reproducir" y disfruta el video.

La configuración predeterminada de la precarga de medios es "metadata".

Para que coincida con las implementaciones de otros navegadores, Chrome para computadoras ahora establece el valor de carga previa predeterminado para los elementos <video> y <audio> en "metadata" para reducir el uso de ancho de banda y recursos. A partir de Chrome 64, este nuevo comportamiento solo se aplica a los casos en los que no se establece ningún valor de precarga. Ten en cuenta que la sugerencia del atributo de precarga se descarta cuando se adjunta un MediaSource al elemento multimedia, ya que el sitio web controla su propia precarga.

En otras palabras, el valor de precarga de <video> ahora es "metadata", mientras que el valor de precarga de <video preload="auto"> sigue siendo "auto". Prueba la muestra oficial.

Intención de lanzamiento | Chromestatus Tracker | Error de Chromium

Unsupported playbackRate raises an exception

Tras un cambio en la especificación de HTML, cuando el atributo playbackRate de los elementos multimedia se establece en un valor que Chrome no admite (p.ej., un valor negativo), se arroja un "NotSupportedError" DOMException en Chrome 63.

const audio = document.querySelector('audio');
try {
  audio.playbackRate = -1;
} catch(error) {
  console.log(error.message); // Failed to set the playbackRate property
}

Por cierto, la implementación actual de Chrome genera esta excepción cuando playbackRate es negativo, inferior a 0.0625 o superior a 16. Prueba el ejemplo oficial para ver esto en acción.

Intención de lanzamiento | Chromestatus Tracker | Error de Chromium

Optimizaciones de pistas de video en segundo plano

El equipo de Chrome siempre intenta encontrar nuevas formas de mejorar la duración de la batería, y Chrome 63 no fue la excepción.

Si el video no contiene pistas de audio, se pausará automáticamente cuando se reproduzca en segundo plano (p.ej., en una pestaña no visible) en Chrome para computadoras (Windows, Mac, Linux y ChromeOS). Este es un seguimiento de un cambio similar que solo se aplicaba a los videos de MSE en Chrome 62.

Error de Chromium

Se quita el silenciamiento para los valores extremos de playbackRate

Antes de Chrome 64, el sonido se silenciaba cuando playbackRate era inferior a 0.5 o superior a 4, ya que la calidad se degradaba significativamente. Como Chrome cambió a un enfoque de superposición y suma de similitud de forma de onda (WSOLA) para la degradación de la calidad, ya no es necesario silenciar el sonido. Esto significa que ahora puedes reproducir sonido muy lento y muy rápido.

Error de Chromium