- Веб-разработчики теперь могут предсказать, будет ли воспроизведение плавным и энергоэффективным .
- Chrome теперь поддерживает воспроизведение HDR-видео в Windows 10 .
- Автономное воспроизведение с постоянными лицензиями теперь поддерживается на Windows и Mac.
- Значением предварительной загрузки по умолчанию для элементов
<video>и<audio>теперь является"metadata". - Теперь выдается ошибка , когда скорость воспроизведения мультимедиа не поддерживается.
- Chrome теперь приостанавливает все фоновые медиафайлы, содержащие только видео .
- Звук больше не отключается при экстремальной скорости воспроизведения.
Возможности мультимедиа — API декодирования информации
Сегодня веб-разработчики полагаются на isTypeSupported() или canPlayType() чтобы смутно знать, можно ли декодировать некоторые медиафайлы или нет. Однако реальный вопрос должен заключаться в следующем: «Насколько хорошо он будет работать на этом устройстве?»
Это как раз одна из задач, которую хотят решить предлагаемые Media Capabilities : API для запроса браузера о возможностях декодирования устройства на основе такой информации, как кодеки, профиль, разрешение, битрейт и т. д. Он будет предоставлять такую информацию, как должно ли воспроизведение быть плавным и энергоэффективным на основе предыдущей статистики воспроизведения, записанной браузером.
В двух словах, вот как сейчас работает API декодирования информации. Посмотрите официальный образец .
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 как true, когда процент пропущенных кадров составляет менее 10 %, а powerEfficient — как true, когда более 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;
});
}
Доступно для исходных пробных версий
Чтобы получить как можно больше отзывов от разработчиков, использующих Decoding Info API (часть Media Capabilities) на местах, мы ранее добавили эту функцию в Chrome 64 в качестве пробной версии.
Суд успешно завершился в апреле 2018 года.
Намерение экспериментировать | Намерение отправить | Трекер Chromestatus | Ошибка хрома
Воспроизведение HDR-видео в Windows 10
Видео с расширенным динамическим диапазоном (HDR) имеют более высокую контрастность, отображая точные, детализированные тени и потрясающие светлые участки с большей четкостью, чем когда-либо. Более того, поддержка широкой цветовой гаммы делает цвета более яркими.
Поскольку 10-битное воспроизведение профиля VP9 Profile 2 теперь поддерживается в Chrome для Windows 10 Fall Creator Update, Chrome дополнительно поддерживает воспроизведение HDR-видео, когда Windows 10 находится в режиме HDR . С технической точки зрения, Chrome 64 теперь поддерживает цветовой профиль scRGB , который, в свою очередь, позволяет воспроизводить мультимедиа в формате HDR.
Вы можете попробовать его, посмотрев «Мир в HDR в формате 4K (ULTRA HD)» на YouTube, и проверить, воспроизводит ли он HDR, посмотрев настройки качества проигрывателя YouTube.
Все, что вам сейчас нужно, — это обновление Windows 10 Fall Creator, 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 , холсте , изображениях и защищенном контенте . Команда 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.
});
Вы можете попробовать постоянные лицензии самостоятельно, ознакомившись с образцом Media PWA и выполнив следующие действия:
- Перейдите на https://biograf-155113.appspot.com/ttt/episode-2/.
- Нажмите «Сделать доступным офлайн» и дождитесь загрузки видео.
- Отключите подключение к Интернету.
- Нажмите кнопку «Play» и наслаждайтесь видео!
Предварительная загрузка мультимедиа по умолчанию равна «метаданным».
В соответствии с реализациями других браузеров, Chrome для настольных компьютеров теперь устанавливает значение предварительной загрузки по умолчанию для элементов <video> и <audio> на "metadata" , чтобы уменьшить пропускную способность и использование ресурсов. Начиная с Chrome 64, это новое поведение применяется только в тех случаях, когда значение предварительной загрузки не установлено. Обратите внимание, что подсказка атрибута предварительной загрузки отбрасывается, когда MediaSource прикрепляется к элементу мультимедиа, поскольку веб-сайт обрабатывает собственную предварительную загрузку.
Другими словами, значение предварительной загрузки <video> теперь является "metadata" , а значение предварительной загрузки <video preload="auto"> остается "auto" . Попробуйте официальный образец .
Намерение отправить | Трекер Chromestatus | Ошибка хрома
Неподдерживаемая скорость воспроизведения вызывает исключение
После изменения спецификации 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 | Ошибка хрома
Оптимизация фоновой видеодорожки
Команда Chrome всегда пытается найти новые способы увеличить время автономной работы, и Chrome 63 не стал исключением.
Если видео не содержит звуковых дорожек, видео будет автоматически приостановлено при воспроизведении в фоновом режиме (например, на невидимой вкладке) на рабочем столе Chrome (Windows, Mac, Linux и ChromeOS). Это продолжение аналогичного изменения, которое применялось только к видео MSE в Chrome 62 .
Уберите отключение звука для экстремальных скоростей воспроизведения
До версии Chrome 64 звук отключался, когда playbackRate был ниже 0,5 или выше 4, поскольку качество значительно ухудшалось. Поскольку Chrome перешел на подход Waveform-Similarity-Overlap-Add (WSOLA) для снижения качества, звук больше не нужно отключать. Это означает, что теперь вы можете воспроизводить звук очень медленно и очень быстро.