Я Дейл Кертис, руководитель разработки по воспроизведению мультимедиа в Chromium. Моя команда отвечает за веб-интерфейсы API для воспроизведения видео, такие как MSE и WebCodecs , а также за внутренние компоненты платформы, участвующие в демультиплексировании, декодировании и рендеринге аудио и видео.
В этой статье я познакомлю вас с архитектурой рендеринга видео в Chromium. Хотя некоторые детали, касающиеся расширяемости, вероятно, специфичны для Chromium, большинство обсуждаемых здесь концепций и проектов применимы к другим механизмам рендеринга и даже к собственным приложениям воспроизведения.
Архитектура воспроизведения Chromium существенно изменилась за последние годы. Хотя мы не начали с идеи пирамиды успеха , описанной в первом посте этой серии, в конечном итоге мы пошли по тем же шагам: надежность, производительность и затем расширяемость.
Вначале рендеринг видео был довольно простым — всего лишь цикл for , выбирающий, какое программное обеспечение декодирует видеокадры для отправки в композитор. В течение многих лет это было достаточно надежно, но по мере увеличения сложности сети потребность в большей производительности и эффективности привела к архитектурным изменениям. Многие улучшения требовали примитивов, специфичных для ОС; таким образом, наша архитектура также должна была стать более расширяемой, чтобы охватить все платформы Chromium.
Рендеринг видео можно разбить на два этапа: выбор того, что доставлять, и эффективное предоставление этой информации. В целях удобства чтения я расскажу об эффективной доставке, прежде чем углубиться в то, как Chromium выбирает, что доставлять.
Некоторые термины и макет
Поскольку эта статья посвящена рендерингу, я лишь кратко коснусь аспектов конвейера демультиплексирования и декодирования.
Декодирование и демультиплексирование в нашем современном мире, заботящемся о безопасности, требуют немалой осторожности. Двоичные анализаторы представляют собой богатую целевую среду, а воспроизведение мультимедиа наполнено двоичным анализом. Таким образом, проблемы безопасности в медиа-парсерах чрезвычайно распространены.
В Chromium применяется глубокая защита , чтобы снизить риск возникновения проблем с безопасностью для наших пользователей. На практике это означает, что демультиплексирование и программное декодирование всегда выполняются в процессе с низким уровнем привилегий, тогда как аппаратное декодирование происходит в процессе, у которого достаточно привилегий для взаимодействия с графическим процессором системы.
Механизм межпроцессного взаимодействия Chromium называется Mojo . Хотя в этой статье мы не будем вдаваться в подробности Mojo, поскольку он является слоем абстракции между процессами, но он является краеугольным камнем расширяемого медиаконвейера Chromium. Важно помнить об этом, когда мы проходим через конвейер воспроизведения, поскольку он информирует о сложной оркестровке межпроцессных компонентов, взаимодействующих для получения, демультиплексирования, декодирования и, наконец, отображения мультимедиа.
Так много битов
Понимание современных конвейеров рендеринга видео требует знания того, почему видео является особенным: пропускная способность. Воспроизведение с разрешением 3840x2160 (4K) и частотой 60 кадров в секунду использует полосу пропускания памяти от 9 до 12 гигабит в секунду. Хотя пиковая пропускная способность современных систем может достигать сотен гигабит в секунду, воспроизведение видео по-прежнему составляет значительную часть. Без должного внимания общая пропускная способность может легко увеличиться из-за копий или переключений между памятью графического процессора и процессора.
Целью любого современного механизма воспроизведения видео с учетом эффективности является минимизация пропускной способности между декодером и финальным этапом рендеринга. По этой причине рендеринг видео в значительной степени отделен от основного конвейера рендеринга Chromium. В частности, с точки зрения нашего основного конвейера рендеринга видео — это просто дыра фиксированного размера с непрозрачностью. Chromium достигает этого, используя концепцию под названием « поверхности» , при которой каждое видео напрямую взаимодействует с Viz .
Из-за популярности мобильных компьютеров в нынешнем поколении большое внимание уделяется мощности и эффективности. В результате декодирование и рендеринг более тесно связаны на аппаратном уровне, чем когда-либо, в результате чего видео выглядит просто непрозрачной дырой даже для самой ОС! Декодеры уровня платформы часто предоставляют только непрозрачные буферы, которые Chromium передает в систему композитинга уровня платформы в виде наложений.
Каждая платформа имеет свою собственную форму наложений, с которыми работают API-интерфейсы декодирования их платформы. В Windows есть Direct Composition и Media Foundation Transforms , в macOS — CoreAnimation Layers и VideoToolbox , в Android — SurfaceView и MediaCodec , а в Linux — VASurfaces и VA-API . Абстракции Chromium для этих концепций обрабатываются интерфейсами OverlayProcessor и mojo::VideoDecoder соответственно.
В некоторых случаях эти буферы можно отображать в системную память, поэтому им даже не нужно быть непрозрачными и не использовать пропускную способность до тех пор, пока к ним не будет осуществлен доступ — Chromium вызывает их GpuMemoryBuffers . В Windows они поддерживаются буферами DXGI , в macOS — IOSurfaces , в Android — AHardwareBuffers и в Linux — буферами DMA . Хотя для воспроизведения видео обычно такой доступ не требуется, эти буферы важны для захвата видео, поскольку обеспечивают минимальную пропускную способность между устройством захвата и возможными кодировщиками.
Поскольку графический процессор часто отвечает как за декодирование, так и за отображение, использование этих (также часто) непрозрачных буферов гарантирует, что видеоданные с высокой пропускной способностью фактически никогда не покинут графический процессор. Как мы обсуждали ранее, хранение данных на графическом процессоре невероятно важно для эффективности; особенно при высоких разрешениях и частоте кадров.
Чем больше мы можем использовать преимущества примитивов ОС, таких как оверлеи и буферы графического процессора, тем меньше пропускной способности тратится на ненужное перетасовывание видеобайтов. Хранение всего в одном месте, от декодирования до рендеринга, может привести к невероятной энергоэффективности. Например, когда Chromium включил оверлеи в macOS, энергопотребление при полноэкранном воспроизведении видео сократилось вдвое! На других платформах, таких как Windows , Android и ChromeOS , мы можем использовать наложения даже в неполноэкранных случаях, почти везде экономя до 50%.
Рендеринг
Теперь, когда мы рассмотрели оптимальные механизмы доставки, мы можем обсудить, как Chromium выбирает, что доставлять. Стек воспроизведения Chromium использует архитектуру, основанную на «вытягивании», то есть каждый компонент в стеке запрашивает входные данные у того, что находится ниже него в иерархическом порядке. Наверху стека находится рендеринг аудио- и видеокадров, ниже — декодирование, за которым следует демультиплексирование и, наконец, ввод-вывод. Каждый визуализируемый аудиокадр опережает тактовую частоту, которая используется для выбора видеокадров для рендеринга в сочетании с интервалом представления.
В каждом интервале представления (каждом обновлении дисплея) средству рендеринга видео запрашивается предоставление видеокадра с помощью CompositorFrameSink , прикрепленного к упомянутому ранее SurfaceLayer . Для контента с частотой кадров меньше, чем частота отображения, это означает показ одного и того же кадра более одного раза, а если частота кадров превышает частоту отображения, некоторые кадры никогда не отображаются.
Синхронизировать аудио и видео способами, приятными для зрителей, можно гораздо больше. См. Project Butter для более подробного обсуждения того, как достигается оптимальная плавность видео в Chromium. Он объясняет, как рендеринг видео можно разбить на идеальные последовательности, показывающие, сколько раз должен быть показан каждый кадр. Например: «1 кадр в каждом интервале отображения ([1], 60 кадров в секунду при 60 Гц)», «1 кадр каждые 2 интервала ([2], 30 кадров в секунду при 60 Гц)» или более сложные шаблоны, такие как [2:3 :2:3:2] (25 кадров в секунду при 60 Гц), охватывающее несколько отдельных кадров и интервалов отображения. Чем ближе средство рендеринга видео придерживается этого идеального шаблона, тем больше вероятность того, что пользователь воспримет воспроизведение как плавное.
Хотя большинство платформ Chromium отображают кадр за кадром, не все это делают. Наша расширяемая архитектура также позволяет выполнять пакетный рендеринг. Пакетный рендеринг — это эффективный метод, при котором композитору уровня ОС заранее сообщается о нескольких кадрах, и он обрабатывает их выпуск по графику, предоставленному приложением.
Будущее - сегодня?
Мы сосредоточились на том, как Chromium использует преимущества примитивов ОС для обеспечения лучшего в своем классе качества воспроизведения. Но как насчет веб-сайтов, которые хотят выйти за рамки простого воспроизведения видео? Можем ли мы предложить им те же мощные примитивы, которые использует сам Chromium для создания веб-контента следующего поколения?
Мы думаем, что ответ – да! Расширяемость лежит в основе того, как мы думаем о веб-платформе в наши дни. Мы работаем с другими браузерами и разработчиками над созданием новых технологий, таких как WebGPU и WebCodecs , чтобы веб-разработчики могли использовать те же примитивы, которые Chromium использует при взаимодействии с ОС. WebGPU обеспечивает поддержку буферов графического процессора , а WebCodecs обеспечивает примитивы декодирования и кодирования платформы, совместимые с вышеупомянутыми системами наложения и буферов графического процессора.
Конец потока
Спасибо за прочтение! Надеюсь, вы получили лучшее представление о современных системах воспроизведения и о том, как Chromium обеспечивает несколько сотен миллионов часов просмотра каждый день. Если вы ищете дополнительную информацию о кодеках и современном веб-видео, я рекомендую H.264 — это волшебство Сида Бала, «Как работают современные видеоплееры» Эрики Бивз и « Упаковка отмеченных наградами шоу с помощью отмеченных наградами технологий» Сирила Конколато.
Одна иллюстрация (красивая!) Уны Кравец.