Chrome 70 поддерживает [список фич] и AV1 – почему поддержка этого кодека так важна?

Автор оригинала: Corbin Davenport
  • Перевод
69-я версия Chrome была большииииим обновлением, т.к. показала новый интерфейс для десктопной и мобильной версий. Chrome 70 не столь радикален, но его новые фичи весьма важны. Мы сделали адаптированный перевод и добавили материал про самое, на наш взгляд, важное в новой версии – поддержку кодека AV1, который задает новую планку производительности. Пока что кодек будет использоваться только при воспроизведении видео, но мы надеемся, что он доберется и до WebRTC – это даст нам возможность использовать передовое кодирование в видеозвонках и конференциях (например, используя наш Web SDK).



Поддержка AV1


Почти 10 лет назад, Google выкатил свой собственный кодек-конкурент для H.264 – это был VP8. В то время как технологические конкуренты не особо отличались, VP8 был бесплатным, а H.264 требовал лицензию. Android поддерживал VP8 «из коробки», начиная с 2.3 Gingerbread. Также все основные браузеры (за исключением Safari) могут воспроизводить VP8-видео.

Сейчас Google входит в Альянс Открытых Медиа (Alliance for Open Media), группу компаний, которая разрабатывает преемника VP8/VP9 под названием AV1. Facebook уже тестировал кодек на тысячах популярных видео и выяснил, что он дает прирост в компрессии более 30% по сравнению с VP9, а именно на 50,3%, 46,2% и 34% (по сравнению с основным профилем x264, high-профилем x264 и libvpx-vp9, соответственно).

Начиная с Chrome 70, кодек AV1 поддерживает по умолчанию для десктопа и Android. И хотя кодеку понадобится время, чтобы стать широко используемым, это все равно важный этап, т.к. ни один другой браузер пока не поддерживает AV1.

AV1 в деталях


Пояснение: этот раздел – выдержки из статьи next generation video: Introducing AV1.

Chroma from Luma


Chroma from Luma prediction (далее – CfL) – один из новых способов прогнозирования, который применили в AV1. CfL прогнозирует цвета в изображении (chroma), основываясь на значении яркости (luma). Сначала кодируются/декодируются значения яркости, затем CfL делает попытку предсказать цвета. Если попытка удачная, то снижается количество информации о цвете, которую надо закодировать; следовательно, сохраняется место.

Стоит отметить, что CfL впервые появился не в AV1. Основополагающий документ по CfL датируется 2009 годом; тогда же LG и Samsung предложили раннюю имплементацию CfL под именем LM Mode, но всё это свернулось во время разработки HEVC/H.265. Кодек Thor от Cisco использует схожую технику, а HEVC имплементировал улучшенную версию под названием Cross-Channel Prediction (CCP).

Улучшенное внутрикадровое прогнозирование


До последнего времени сжатие видео основывалось на межкадровом прогнозировании, т.е. на отличии кадра от других, когда в основе прогнозирования лежат опорные кадры. Несмотря на то, что эта техника мощно развилась, она все еще требует опорные кадры, которые не полагаются на другие кадры. В итоге опорные кадры используют только внутрикадровое прогнозирование.

Первые 60 кадров тестового видео. Гистограмма начинаетсся с опорного кадра в ~20 раз больше остальных.

Опорные кадры гораздо больше, чем промежуточные – поэтому их стараются использовать как можно реже. Но если опорных кадров становится много, это повышает битрейт видео. Дабы справиться с этим и уменьшить размер опорных кадров, исследователи кодеков сосредоточились на улучшении внутрикадрового прогнозирования (которое так же можно применять и к промежуточным кадрам).

Резюмируя, можно утверждать, что CfL – это как раз и есть продвинутая техника внутрикадрового прогнозирования, т.к. она работает на основе яркости в пределах кадра.

Цветные мелки


CfL в своей основе – это раскрашивание монохромного изображения исходя из обоснованного, точного предсказания. Предсказание облегчается тем, что изображение бьется на мелкие блоки, в которых кодирование происходит независимо.

Разбиение на блоки, чтобы максимизировать точность кодирования.

Так как кодер работает не со всем изображением, а с его кусочками, достаточно выявить корреляции в небольших областях – этого хватит, чтобы прогнозировать цвета на освное яркости. Возьмем маленький блок изображения:


На основе этого фрагмента, кодер установит, что ярко = зеленому цвету, а чем темнее, тем меньше насыщенность. И так же с остальными блоками.

CfL в AV1


В CfL не стали использовать алгоритм PVQ, поэтому затраты при пиксельной и частотной областях примерно одинаковы. Плюс AV1 использует дискретное синусное преобразование и преобразование пиксельной области (pixel domain identity transform), поэтому выполнить AV1 CfL в частотной области не очень легко. Но – сюрприз – AV1 и не нуждается в CfL в частотной области, т.к. основные уравнения CfL одинаково работают в обеих областях.

СfL в AV1 призван максимально упростить реконструкцию. Для этого необходимо явным образом кодировать α и на его основе вычислить β, хотя… Можно и не вычислять β, а вместо него использовать уже спрогнозированное кодером DC-смещение цветности (оно будет менее точным, но все же подходящим):

Сравнение DC-прогноза по умолчанию (расчет на основе соседних пикселей) с рассчитанным β-значением (расчет на основе пикселей в текущем блоке).

Таким образом, сложность аппроксимации на стороне кодера макисмально оптимизируется за счет использования прогнозирования. Если прогнозирования недостаточно, то выполняются остальные преобразования; если же прогнозирование не дает выгоды в битах, то оно не используется вовсе.

Немного тестов


Альянс Открытых Медиа использует ряд тестов, которые также доступны в инструменте Are We Compressed Yet?

Ниже представлена таблица с битрейтом в разрезе по разным показателям. Обратите внимание на CIE delta-E 2000, это метрика перцептивно-равномерной ошибки цвета. Заметно, как экономится битрейт? Вплоть до 8%!
BD-rate
PSNR PSNR-HVS SSIM CIEDE2000 PSNR Cb PSNR Cr MS SSIM
Average -0.43 -0.42 -0.38 -2.41 -5.85 -5.51 -0.40
1080p -0.32 -0.37 -0.28 -2.52 -6.80 -5.31 -0.31
1080p-screen -1.82 -1.72 -1.71 -8.22 -17.76 -12.00 -1.75
720p -0.12 -0.11 -0.07 -0.52 -1.08 -1.23 -0.12
360p -0.15 -0.05 -0.10 -0.80 -2.17 -6.45 -0.04

… и прочие новинки в Chrome 70


PWA на Windows


Хотя поддержка Progressive Web Apps в основном реализована на мобильных платформах, Google не забывает и о десктопе. В десктопном Chrome 67 появилась кнопка установки PWA, а уже Chrome 70 привнес несколько улучшений для пользователей Windows.


Теперь Chrome показывает поп-ап «Install app?» для PWA (после того, как вы какое-то время взаимодействовали с ними). Если вы установите PWA, браузер создаст ярлык для PWA в меню «Пуск». По аналогии с мобильным опытом, интерфейс браузера будет скрыт в открытом PWA.

Google обещает, что выкатит эту функциональность для Mac и Linux в 72 версии.

Shape Detection API


Веб-приложения умеют по-разному считывать штрихкоды и распознавать лица, обычно с помощью JS-библиотек машинного обучения, но это может очень медленно работать. Чтобы сделать эту фичу более доступной и производительной, Google внедряет свою собственную функциональность в Chrome – shape detection.

Shape Detection API в Chrome 70 – это экспериментальная функция (origin trial), т.е. она еще не готова для широкого использования. API может определять 3 типа объектов/изображений – лица, штрикоды и текст. На данный момент, совместимость варьируется на разных платформах, потому что от ОС требуется функциональность по определению объектов. Вы можете попробовать демо здесь.

TLS 1.3


Transport Layer Security – это протокол, который позволяет безопасно передавать данные через Интернет. Когда вы пользуетесь сайтом на HTTPS, то скорее всего, данные отправляются по TLS. Chrome 70 поддерживает TLS 1.3, который зарелизили в прошлом месяце.

Список изменений доступен здесь, но если говорить в общем, версия 1.3 повышает как эффективность, так и безопасность (например, «победили» BREACH и CRIME, благодаря чему можно снова безопасно использовать сжатие на https – прим.переводчика, спасибо menstenebris). Требуется меньше шагов для установки соединения, так что можно заметить небольшое улучшение во времени (если сайт, на который вы зашли, поддерживает TLS 1.3, разумеется). Вот наглядное сравнение разницы от CloudFlare:



С выходом TLS 1.3 также прекращается поддержка старых фич, например SHA1 и MD5. Google заявил об этом на Status Page:
TLS 1.3 был многолетним проектом, объединившим сторонников из разных индустрий, исследовательских групп и других участников при работе над стандартом. Ранее мы экспериментировали с черновыми версиями стандарта, но когда стандарт был полностью реализован, мы наконец можем внедрить его в Chrome.

Firefox 60 добавил поддержку TLS 1.3 (драфт 23), который выкатили в мае этого года; тогда его начал использовать и CloudFlare.

Другие фичи


Как и всегда, Chrome 70 включает нововведения для пользователей и разработчиков. Вот список прочих изменений в этом обновлении:

  • Speech synthesis API не будет работать, пока страница хотя бы единожды не взаимодействовала с этим API. Это API часто использовали для спамерских поп-апов на мобильных устройствах вплоть до новой политики autoplay в Chrome 66;
  • Touch ID на Macbook Pro можно использовать как способ логина в Web Authentication API;
  • если страница в режиме полного экрана, то появление поп-апа выведет страницу из полного экрана;
  • AppCache больше не работает на НЕ https-страницах;
  • на Android-устройствах номер сборки OC (например, «NJH47F») больше не входит в user agent, чтобы предотвратить идентификацию браузера. Chrome на iOS оставит номер сборки «15E148» вместо того, чтобы полностью его убрать, дабы следовать реализации в Safari;
  • аудио в формате opus теперь поддерживается для контейнеров MP4, Ogg и WebM;
  • WebUSB теперь использует контекст отдельного worker’а, что должно повысить производительность;
  • Web Bluetooth теперь работает в Windows 10;
  • новый диалог синхронизации на десктопах;
  • service worker’ам можно давать имена;
  • Credential Management API теперь поддерживает PublicKeyCredential;
  • первоначальные реализации Custom Elements, HTML импортов, navigator.getGamepads и Shadow DOM API теперь в статусе deprecated;
  • Lazy Loading теперь можно включить с помощью флагов #enable-lazy-frame-loading и #enable-lazy-image-loading.
Voximplant
156,00
Облачная платформа голосовой и видеотелефонии
Поделиться публикацией

Комментарии 46

    –12
    >Shape Detection API, WebUSB, Web Bluetooth
    +Web Assembly. WebRTC, WebGL
    Продолжают пропихивать сомнительные стандарты с функциональностью для 1,5 сайтов разной степени кривости и поддержки другими браузерами, вместо того чтобы выпустить официальные дополнения с предложением установить их когда они понадобятся.
      +4
      ВЫ очень далеки от многих ниш где люди используют эти API. Например для меня в моей нише Web Assembly и WebUSB это просто манна небесная.
        0
        А что у вас за ниша? Может статью вводную напишите, поделитесь каким-нибудь хэло-ворлдом с использованием этих двух API?
        +1
        Кажется, мы это уже проходили с ActiveX, как-то не очень вышло.

        К тому же, а что такого можно установить дополнением, что нельзя реализовать на вебасме, который всё равно сjitится в машинный код в итоге? Полный доступ к железу? Хм, а стоит ли?
        +1
        Как-то забыли написать что TLS 1.3 важен тем что CRIME и BREACH на нем не работают. А это значит что можно вновь использовать сжатие на https.
          0
          Благодарю. Добавили это как примечание и упомянули вас.
          +1
          Custom Elements, HTML импорты, navigator.getGamepads и Shadow DOM API теперь в статусе deprecated;

          The original Custom Elements, HTML Imports, navigator.getGamepads, and Shadow DOM APIs are now deprecated.

          Ну вы и дали дрозда, я аж присел.
            +3
            Вот это сейчас было ценно, спасибо, поправили. Можете спокойно вставать :)
            +5
            на Androig-устройствах номер сборки OC (например, «NJH47F») больше не входит в user agent, чтобы предотвратить считывание отпечатка пальца.

            Фингерпринт это отпечаток клиента (браузера), а не пальца, в данном случае. На хабре его можно просто оставить "фингепринтом".

              0
              или «идентификация». Спасибо большое, исправили.
                +4
                мы наконе можем внедрить его в Chrome.

                Тыгыдык-тыгыдык)

                  +1

                  «Поспешишь – людей насмешишь», как говорится :) Спасибо, вернули «ц» на место.

                +1
                Правильно понимаю, что в AV1 более чувствителен к потере ключевых кадров? Или там есть защитные механизмы?
                Повышенное прогнозирование требует повышенных вычислительных мощностей, или обеспечивается за счёт оптимизации алгоритмов?
                  +1
                  Похоже, я всё же ошибся. Но было бы интересно почитать и о ток как кодек борется с возможными потерями ключевой информации, или с превышением предельной нагрузки.
                    +1
                    вряд ли AV1 более/менее чувствителен к потере key frames, но сам факт того, что в нем имплементировано продвинутое внутрикадровое прогнозирование, дает уменьшение размера как key frames, так и промежуточных кадров. Разузнать подробности про борьбу с потерями – звучит как интересная идея, взяли на заметку.
                  +1
                  ютубу теперь переведут с vp9 на av1?
                  –1
                  >AV1

                  Угу. В то время как ваши Intel i5/i7 CPU справляется с кодированием HEVC 1080p@60 со скоростью 60/80+ fps… Данный сабж кодируется со скоростью 2 кадра в минуту потребляя 8 гб оперативки.
                    +1

                    дет быстрый аппаратный кодер. На CPU никто не кодирует большие объемы видео

                    0

                    А чем декодировать этот кодек они думали? Поддержка аппаратного декодирования VP9 появилась не так давно ( намного позже, чем VP9 появился на YouTube).

                      0
                      интересно, какой процессор без разгона вытянет AV1 1080@60?
                      0
                      дык на gpgpu
                      правда видеокарта понадобится неслабая
                      ps 8k@60fps vp9 грузит 1050ti на 92-100%
                      пруф на моем компе
                      image


                      встройка даже от i7 7700k такое не тянет
                      +3
                      увеличивает производительность на 50,3%, 46,2% и 34% (по сравнению с основным профилем x264, high-профилем x264 и libvpx-vp9, соответственно)

                      производительность чего? в исходном тексте это gain. кодирование и декодирование у AV1 тормозное.
                        +1
                        Мне нравится идея VP8/9/AV1 технологически и в плане того, что это более свободный стандарт, но на практике без поддержки аппаратного де(кодирования) оно только вредит. Поддержка VP9, к примеру, появилась в мобильных ЦПУ intel только к 2017 году, начиная с Kaby Lake (i7-7500U, например).
                        То что youtube по умолчанию отдает VP9 (а теперь и AV1) вместо х264 — это какое-то неуважение к пользователям. При этом даже не проверяют, поддерживает ли клиентское устройство аппаратное декодирование VP9.
                        The bitstream was finally frozen on 28 March 2018, meaning chips could be available sometime between March and August 2019.[103] According to the above forecast, products based on chips could then be on the market at the end of 2019 or the beginning of 2020.

                        В данный момент я выключаю VP9 в пользу h264 на youtube так как это существенно экономит батарею. На ТВ-приставках 4K@60Hz VP9 видео вообще тормозит, в отличии от x264/265. То есть первые устройства с аппаратной поддержкой AV1 появятся в 2020, если все будет хорошо. Широкого распространения можно ждать не ранее 2022-23, наверное.
                        image
                          0

                          Потому что если не пропихивать то все так и будут сидеть на

                            0
                            Посмотрите, какие компании стоят за стандартом AV1:
                            Браузеры: Apple, Google, Mozilla, Microsoft,
                            Контент: Apple, Amazon, Facebook, Google, Hulu, Netflix,
                            Хард: Intel, AMD, Nvidia, Arm, Apple, Broadcom.
                            Эти ребята контролируют едва ли не 100% современного айти. Вы считаете, что они не смогут обеспечить распространение формата, не навязывая его там, где устройства не имеют аппаратной поддержки?
                            Почему нельзя отдавать VP9/AV1 только в том случае, если устройство поддерживает его аппаратно? Почему бы не дождаться, пока Intel, AMD, Nvidia, Arm и Apple выпустят устройства с его поддержкой, пройдет 3-5 лет, что бы пользователи обновили свои устройства и тогда переходить на него «по умолчанию»?
                              –1
                              Типичное сборище корпоративных жидов же. Вместо того чтобы скинутся и выкупить патенты на h264/h265 и продолжить развитие их идей, сделав h266 — будем издеваться над потребителями, обходить патенты дикими бессмысленными расходами вычислительной мощности дабы ни заплатить ни цента, и при этом еще и наживемся на всех тех, у кого наш супер-дупер AV1 работать не будет, ибо им придется раскошелиться на очередной i69-100500 в котором мы великодушно добавили ускорение этого нашего великолепного кодека.

                              Знаете что? Идите вы все в сраку!
                              С уважением, нищий студент с нетбуком на целероне.
                                +1
                                Разработка AV1 обходится недёшево тем компаниям, что вкладываются в его развитие. Так что касательно «не заплатить ни цента» вы сильно ошибаетесь.
                                  0
                                  Обойти патенты дешевле, чем их выкупить (иначе бы не обходили).
                                  А в итоге как всегда в мире копирастов: каждый пилит свой велосипед с уникальной формы колесами, в то время как если бы все эти патентные тролляки скинулись и использовали все имеющиеся наработки в совместном продукте — получилась бы универсальная вещь на все случаи жизни.

                                  Opus — наглядный пример, и заодно исключение из правил.
                                    +1
                                    Дело в том, что AV1 и есть эта попытка создать современный видеокодек, который подойдёт всем. И это уникальный случай, когда большое количество компаний собрались вместе, чтобы воплотить это в жизнь. До AV1 было несколько свободных видеокодеков в разработке: Google занималась VP10, Mozilla и Xiph занимались Daala, Cisco делала свой Thor. Но потом все объединили свои усилия для создания AV1, в качестве ответа на третий (!) пул патентов HEVC, что сулило не самые позитивные перспективы для всех.
                                      0
                                      А я пытаюсь сказать, что затея хорошая, но без отжима в свободный доступ тех самых патентов на технологии, примененные в h264 и h265 — идиотизм, за который приходится расплачиваться много возросшими требованиями к вычислительной мощности.

                                      В AV1 приходится разменивать производительность на лицензионно-свободные алгоритмы. И это плохо.

                                      Если бы вместо изобретения алгоритмов обходящих патенты они выкупили те самые патенты, дело шло бы быстрее и легче. Да и кодек вышел бы лучше.
                                      Но они не выкупили.
                                        +1
                                        Те компании, что вошли в AOMedia, поделились своими патентами (многие члены AOMedia являются также и патентодержателями h265/HEVC). Если победа AV1 и поражение h265 станет очевидным для всех, больше компаний присоединится к AOMedia, чтобы от своих патентов получить хотя бы плюсик в репутацию. И возможно что-то из этого будет использовано в AV2. Например, Apple запрыгнула на этот поезд ровно перед релизом AV1 — наверняка, её патенты ещё не успели применить, но у разрабочтиков будет возможность их использовать для AV2.

                                        Выкупить все патенты касательно h265 нереально — их там тысячи (можете посмотреть ради любопытства первый пул и второй пул — там списки номеров патентов на сотни страниц), и их владельцы могут запросить за них любую сумму, хоть миллиард долларов за каждый.

                                        Год назад вышел только референсный кодек, который ожидаемо очень медленный, потому что цель его была просто продемонстрировать другим разработчикам, как нужно кодировать и декодировать AV1. Оптимизированные кодеры и декодеры появляются сейчас, и они показывают большой прогресс в улучшении производительности. Аппаратная поддержка в массовых процессорах начнёт появляться где-то через год-два (такие вещи не делаются быстро).

                                        AV1 всего один год. h264 уже 16 лет. Дайте первому достаточно времени для развития прежде, чем судить о том, насколько он хорош.
                                          –1
                                          Моего процессора хватает софтварно vp9@1080p30 декодировать. h265 и vp8 он умеет аппаратно. Но и их принудительно в программном режиме он тоже декодирует.

                                          dav1d затыкается на 720p30

                                          Мобильный соплерон, да.
                                          Особо лучше не будет. Выкрутят пару процентов, может 720 и перестанет лагать.
                                            0
                                            Не переживайте. К тому времени, как AV1 станет стандартом де-факто (на что уйдёт много лет) и будет предлагаться без альтернативы в виде h264, вы уже успеете обновить свою машину.
                            0
                            В данный момент я выключаю VP9 в пользу h264 на youtube так как это существенно экономит батарею.

                            Если не секрет — браузером или как?

                              0
                              Плагин для фаерфокса «h264ify».
                            0
                            по мне встраивать в браузер qr code это уже бред
                              +1
                              >а также увеличивает производительность на 50,3%, 46,2% и 34%
                              В оригинальной статье очевидно имеется в виду не производительность (производительность чего?), а степень сжатия.
                                0

                                Похоже, что Android Police немного вырвали слова из контекста:
                                https://code.fb.com/video-engineering/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/


                                Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively.


                                То есть была задана планка – достигнуть/превысить 30% по сжатию и AV1 преодолел ее. Внесли правки, благодарю.

                                  0

                                  А чем отличается libvpx-vp9 от VP9?

                                    +1
                                    VP9 — это формат сжатого видео. libvpx-vp9 — конкретный кодек, который умеет сжимать видео в этот формат.
                                +1
                                Touch ID на Macbook Pro можно использовать как способ логина в Web Authentication API

                                Только для эпл? А планируется ли поддержка аутентификации по отпечатку на других ноутбуках?

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое