- Веб-разработчики теперь могут предсказать, будет ли воспроизведение плавным и энергоэффективным .
- Chrome теперь поддерживает воспроизведение HDR-видео в Windows 10 .
- Теперь поддерживается автономное воспроизведение с постоянными лицензиями на Windows и Mac.
- Значение предварительной загрузки по умолчанию для элементов
<video>и<audio>теперь —"metadata". - Теперь возникает ошибка , если скорость воспроизведения мультимедиа не поддерживается.
- Chrome теперь приостанавливает воспроизведение всего фонового видео .
- Звук больше не отключается при экстремальной скорости воспроизведения.
Возможности мультимедиа — API декодирования информации
Сегодня веб-разработчики полагаются на isTypeSupported() или canPlayType() чтобы приблизительно определить, можно ли декодировать тот или иной медиаконтент. Однако реальный вопрос должен звучать так: «Насколько хорошо это будет работать на этом устройстве?»
Это как раз одна из задач, которую призваны решить предлагаемые Media Capabilities : API для запроса браузеру сведений о возможностях декодирования устройства на основе такой информации, как кодеки, профиль, разрешение, битрейт и т. д. Он предоставит информацию, например, о том, должно ли воспроизведение быть плавным и энергоэффективным, на основе статистики предыдущего воспроизведения, записанной браузером.
Вкратце, вот как на данный момент работает API Decoding Info. Ознакомьтесь с официальным примером .
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.');
});
Вы можете попробовать различные конфигурации медиа, пока не найдете оптимальную ( smooth и powerEfficient ), и использовать ее для воспроизведения соответствующего медиапотока. Кстати, текущая реализация Chrome основана на ранее записанной информации о воспроизведении. smooth считается истинным, когда процент пропущенных кадров составляет менее 10%, а powerEfficient — истинным, когда аппаратно декодируется более 50% кадров. Небольшие кадры всегда считаются энергоэффективными.
Я рекомендую использовать фрагмент, аналогичный приведенному ниже, чтобы определить доступность и вернуться к текущей реализации для браузеров, которые не поддерживают этот 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;
});
}
Доступно для испытаний на оригинальном оборудовании
Чтобы получить как можно больше отзывов от разработчиков, использующих API Decoding Info (часть Media Capabilities) на практике, мы ранее добавили эту функцию в Chrome 64 в качестве пробной версии.
Судебный процесс успешно завершился в апреле 2018 года.
Намерение экспериментировать | Намерение начать выпуск | Chromestatus Tracker | Ошибка Chromium
Воспроизведение HDR-видео в Windows 10
Видеоролики с высоким динамическим диапазоном (HDR) отличаются повышенной контрастностью, позволяя видеть точные, детальные тени и потрясающие светлые участки с невероятной чёткостью. Более того, поддержка широкого цветового охвата делает цвета более яркими.
Поскольку в Chrome для Windows 10 Fall Creator Update теперь поддерживается воспроизведение 10-битного видео в формате VP9 Profile 2, Chrome также поддерживает воспроизведение HDR-видео в режиме HDR в Windows 10. С технической точки зрения, Chrome 64 теперь поддерживает цветовой профиль scRGB , что позволяет воспроизводить медиаконтент в формате HDR.
Вы можете попробовать это, посмотрев фильм «Мир в HDR в 4K (ULTRA HD)» на YouTube и проверить, воспроизводится ли HDR, посмотрев настройки качества проигрывателя YouTube.
Все, что вам нужно сейчас, — это обновление Windows 10 Fall Creator Update, HDR-совместимая видеокарта и дисплей (например, карта NVIDIA 10 серии, телевизор или монитор LG HDR), а также включение режима HDR в параметрах дисплея Windows.
Веб-разработчики могут определить приблизительный цветовой охват, поддерживаемый устройством вывода, с помощью недавнего медиазапроса «Цветовой охват» , а также количество бит, используемых для отображения цвета на экране, с помощью функции screen.colorDepth . Вот один из способов использования этих данных, например, для определения поддержки VP9 HDR:
// 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"'))
}
Строку кодека VP9 с профилем 2, переданную в isTypeSupported() в примере выше, необходимо обновить на основе свойств кодирования видео.
Обратите внимание, что пока невозможно определять цвета HDR в CSS , Canvas , изображениях и защищённом контенте . Команда Chrome работает над этим. Следите за новостями!
Постоянные лицензии для Windows и Mac
Постоянная лицензия в Encrypted Media Extensions (EME) означает, что лицензия может быть сохранена на устройстве, чтобы приложения могли загружать её в память без отправки нового запроса на лицензию на сервер. Именно так поддерживается автономное воспроизведение в EME.
До сих пор ChromeOS и Android были единственными платформами, поддерживающими постоянные лицензии. Теперь это не так. Воспроизведение защищённого контента через EME при отсутствии подключения к интернету теперь возможно и в Chrome 64 на Windows и 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.
});
Вы можете самостоятельно опробовать постоянные лицензии, изучив Sample Media PWA и выполнив следующие шаги:
- Перейти по ссылке https://biograf-155113.appspot.com/ttt/episode-2/
- Нажмите «Сделать доступным офлайн» и дождитесь загрузки видео.
- Отключите подключение к Интернету.
- Нажмите кнопку «Воспроизвести» и наслаждайтесь видео!
Предварительная загрузка медиафайлов по умолчанию — «метаданные».
Следуя реализациям других браузеров, Chrome для ПК теперь устанавливает значение предварительной загрузки по умолчанию для элементов <video> и <audio> равным "metadata" , чтобы снизить нагрузку на полосу пропускания и потребление ресурсов. Начиная с Chrome 64, это новое поведение применяется только в случаях, когда значение предварительной загрузки не задано. Обратите внимание, что подсказка атрибута preload отбрасывается при присоединении MediaSource к элементу media, поскольку веб-сайт самостоятельно выполняет предварительную загрузку.
Другими словами, значение предварительной загрузки <video> теперь равно "metadata" , а значение предварительной загрузки <video preload="auto"> остаётся "auto" . Попробуйте официальный пример .
Намерение отправить | Chromestatus Tracker | Ошибка Chromium
Неподдерживаемый playbackRate вызывает исключение
После изменения спецификации HTML , когда playbackRate элемента мультимедиа установлено на значение, не поддерживаемое Chrome (например, отрицательное значение), в Chrome 63 возникает исключение DOMException "NotSupportedError" .
const audio = document.querySelector('audio');
try {
audio.playbackRate = -1;
} catch(error) {
console.log(error.message); // Failed to set the playbackRate property
}
Кстати, текущая реализация Chrome вызывает это исключение, когда playbackRate либо отрицательный, либо меньше 0,0625, либо больше 16. Попробуйте официальный пример , чтобы увидеть это в действии.
Намерение отправить | Chromestatus Tracker | Ошибка Chromium
Оптимизация фоновой видеодорожки
Команда Chrome всегда старается найти новые способы увеличения срока службы батареи, и Chrome 63 не стал исключением.
Если видео не содержит аудиодорожек, оно будет автоматически приостановлено при воспроизведении в фоновом режиме (например, в невидимой вкладке) в десктопной версии Chrome (Windows, Mac, Linux и ChromeOS). Это продолжение аналогичного изменения, которое применялось только к видео MSE в Chrome 62 .
Удалить отключение звука для экстремальных скоростей воспроизведения
До Chrome 64 звук отключался при значении playbackRate ниже 0,5 или выше 4, что приводило к значительному ухудшению качества. С переходом Chrome на подход Waveform-Similarity-Overlap-Add (WSOLA) для снижения качества звука, отключать звук больше не требуется. Это означает, что теперь можно воспроизводить звук как очень медленно, так и очень быстро.