Процесс Google Chrome Helper «съел» 258 % процессора =) (для Mac’a это значение нормальное и показывает, что полностью загружено 2,5 ядра)
Если же просматривать видео в браузере Safari, то картина меняется
Загрузка процессора 25% и кулер не шумит и температура процессора нормальная.
А причина всего этого кроется в том, что Chrome поддерживает воспроизведение HTML5 видео используя кодеки VP8/VP9, что подтверждается переходом в Chrome по ссылке
Современная поддержка это отлично, но проблема в том, что не все железо поддерживает программное декодирование VP8/VP9 и приходится «подключать» силы основного CPU для того, чтобы такое видео воспроизводить.
Safari поддерживает HTML5 видео, но в свою очередь использует кодек H.264, который без проблем поддерживается железом и силы CPU не привлекаются, и да — VP8/VP9 не поддерживает
Немного отступим в сторону. Когда Google в середине 2010
В недавном
Эта проблема, как и многие проблемы производительности Chrome проявилась в Mac. Разработчики Chrome
Вернемся.
Проблема получилась двусторонняя: производители не спешат реализовывать аппаратную поддержку VP8/VP9 до тех пор, пока не поймут, что это действительно нужно и используется, а Chrome просто по умолчанию использует эти кодеки, но нагружая при этом CPU. Использование VP8/VP9 сокращает время загрузки видео, но вместе с этим нагружает CPU и как следствие, время автономной работы мобильных устройств сокращается.
Что делать? Конечно можно перейти на использование Safari, MS Edge или IE (упаси Г…), но и для Chrome есть решение — использовать расширение
Как понять, что расширение работает. Очень просто. Запускаем ролик HD и желательно с 60fps, кликаем правой кнопкой мыши на ролике и выбираем «Статистика для сисадминов».
Если параметр Mime Type имеет значение «video/webm; codecs=»vp9», то используется «прожорливый» кодек.
Но после установки расширение картина должна измениться
И теперь параметр Mime Type имеет значение «video/mp4; codecs=»…», что означает использование аппаратного декодирования.
Что в итоге: VP9 задумка хорошая, но неспешность производителей железа реализовывать поддержку этого кодека приводит к тому, что пользователи расплачиваются излишним использованием процессора и сокращением автономной работы. Видимо, пока что лучше использовать H.264.