Методы отображения мультимедийных материалов в мультиэкранных системах

Одной из задач, возникающих при работе с мультиэкранными системами, является отображение видеоданных, поступающих в реальном масштабе времени из потоковых источников, например, видеокамер или данных, передаваемых по локальным или глобальным сетям [1].

Воспроизведение потоковых видеоматериалов отличается от воспроизведения видеоматериалов, хранящихся в виде файлов [2]. Основной задачей при воспроизведении потоковых видеоматериалов является достижение наименьшей задержки между получением информации с внешнего устройства и отображением уже преобразованной информации. При воспроизведении видеоматериалов из файлов для обеспечения плавности воспроизведения применяется технология кэширования данных в оперативной памяти. Однако использование кэширования в значительной степени ограничено при воспроизведении потоковых видеоматериалов в мультиэкранных системах. При кэшировании данных образуется дополнительная задержка между получением данных с внешнего устройства и их отображением.

Поток данных с внешнего устройства (с видеокамеры) представляет собой поступающие с равной периодичностью массивы данных одина- кового размера. В зависимости от формата передаваемых данных количество массивов данных в секунду и их размер могут различаться. Также для получения целого видеокадра может потребоваться несколько массивов данных (пакетов).

Зачастую поток данных, приходящий с видеокамеры, совмещает в себе звуковую и видеоинформацию. Такой поток называется мультиплексированным. Для воспроизведения сначала необходимо демультиплексировать поступающую информацию, то есть произвести разделение видео- и аудиоданных на отдельные пакеты. Основной проблемой получения пакетов с видеокамеры является отсутствие единого стандартного интерфейса для работы с внешними устройствами. Так, на операционных системах семейства Windows для работы внешними мультимедийными устройствами применяется интерфейс DirectShow [3], на операционных системах семейства Linux – Video For Linux 2 (v4l2), на операционных системах семейства Macintosh (MacOS) – QuickTime. Каждый из этих интерфейсов имеет собственную структуру и в значительной степени отличается от других интерфейсов.

Разработанная архитектура подсистемы воспроизведения потоковых видеоматериалов позволяет осуществлять захват данных с внешних устройств на операционных системах Windows,

Linux, MacOS X. Архитектуру можно условно разделить на две части: подсистема захвата данных и подсистема декодирования данных.

Подсистема захвата данных использует интерфейсы платформы для захвата данных с таких устройств, как видеокамеры. Подсистема декодирования основана на библиотеке FFmpeg и позволяет осуществлять декодирование большинства современных форматов.

Преимуществом такого разделения функциональности является неизменность подсистемы декодирования для всех платформ, изменяется лишь подсистема захвата данных. Кроме того, использование библиотеки FFMPEG позволяет добиться независимости от декодеров, установленных на машине пользователя.

Рассмотрим реализацию архитектуры на платформе Windows и API DirectShow. Основным объектом в DirectShow является фильтр. Существуют три вида фильтров: фильтры захвата (получения данных), фильтры преобразования и фильтры визуализации (рендеринга) [4].

Для работы с фильтрами DirectShow создается граф фильтров, на который добавляются все необходимые фильтры захвата, преобразования и визуализации (рис. 1).

Вместе с DirectShow поставляется несколько стандартных фильтров для получения данных с внешних источников, преобразования этих данных и их отображения. Например, существуют отдельные фильтры захвата данных как для видеокамер, которые выводят видеоинформацию в формате DV, так и для видеокамер, выводящих информацию в формате MPEG 2. Однако среди представленных стандартных фильтров отсутствует фильтр, который бы позволял получить неизмененные данные с видеокамеры для их дальнейшего преобразования внутри приложения. Было определено, что многие приложения, такие как Media Player Classic, FFmpeg, использующие DirectShow, не способны получать данные с видеокамер формата HDV. Программы, способные получать данные с камер в формате HDV, такие как VLC Player, используют собственные программные компоненты. Следовательно, необходима разработка фильтра получения данных с видеокамеры.

Задачей созданного фильтра является получение и хранение пакетов, поступивших с видеокамеры. Фильтр подсоединяется к выходу фильтра захвата видеокамеры и принимает пакеты данных через определенные интервалы времени (зависит от выходного формата видеоинформации).

Разработанный фильтр состоит из трех основных частей: вход фильтра, который принимает данные с видеокамеры; интерфейс фильтра, позволяющий настраивать работу фильтра; выход фильтра, с которого происходит получение пакетов, полученных с камеры, приложением. Фильтр способен хранить до 20 поступивших с камеры пакетов. При превышении этого порога наиболее старый пакет удаляется из очереди.

Получение данных с видеокамеры и определение параметров входного потока состоит из нескольких этапов. Первым этапом является инициализация и поиск внешних устройств захвата. Такими устройствами могут являться видеокамеры, платы видеозахвата или устройства захвата звука (например звуковые карты). Если хотя бы одно устройство было найдено, то происходит переход ко второму этапу. В первую очередь осуществляется поиск видеокамер и плат видеозахвата.

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

Однако для формата MPEG 2 это невозможно, так как информация о параметрах выходного сигнала хранится не в каждом пакете, а только в пакетах, предшествующих началу группы изображений (Group of Pictures), в так называемых заголовках начала последовательности (sequence header) [5]. Для получения информации о параметрах выходного сигнала необходимо декодировать несколько пакетов. При обнаружении выходного сигнала в формате MPEG 2 потоку данных присваиваются параметры по умолчанию, а конкретные параметры определяются на следующих этапах. Третьим этапом является создание экземпляра разработанного фильтра для получения данных с видеокамеры и присоединение его входа к выходу фильтра захвата видеокамеры. После выполнения третьего этапа возможно получение пакетов данных с видеокамеры.

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

Рисунок 1. Пример использования графа фильтров для воспроизведения видеофайла

от формата входного сигнала требуется различное количество пакетов. Например, для формата DV достаточно всего одного пакета для определения всех необходимых параметров декодирования подсистемы FFmpeg. Для формата MPEG 2 требуется порядка 130-140 пакетов для корректного определения параметров входного сигнала. Во время определения параметров обрабатываемые пакеты автоматически демультиплексируются и сохраняются во внутренних буферах FFmpeg. После определения параметров входного сигнала все использованные пакеты удаляются из очереди хранения и внутренних буферов FFmpeg, чтобы исключить повреждение отображаемого при воспроизведении изображения из-за несовпадения изображений, хранимых в старых и новых пакетах. По завершении четвертого этапа видеоматериалы, полученные с видеокамеры, могут быть воспроизведены в виртуальной трехмерной сцене.

Декодер потоковых видеоматериалов

После команды запуска воспроизведения видеоматериалов, поступающих с видеокамеры, создается три независимых потока и запускается фильтр получения пакетов с видеокамеры. В потоке получения пакетов с видеокамеры после запуска происходит кэширование пакетов. Число кэшированных пакетов зависит от формата входного сигнала. Например, для формата DV кэшируется до 4 пакетов, для формата MPEG от 2 до 10. После окончания кэширования заданного числа пакетов запускается рабочий цикл потока, в котором последовательно происходит получение пакетов с видеокамеры, их демультиплексирование и сортировка полученных видео- и аудиопакетов по соответствующим очередям. В этом же рабочем цикле происходит проверка на необходимость кэширования декодированных аудио- и видеоданных. Если воспроизведение видеоматериалов было только что запущено, то при каждой итерации рабочего цикла потока происходит проверка на количество декодированных видеокадров и аудиоданных. Если число декодированных видеокадров меньше установленного порога, то отправляется запрос на декодирование потоку декодирования видеопакетов. Аналогично проверяется количество декодированных аудиоданных.

Потоки декодирования работают в непрерывном режиме до тех пор, пока не обработается заданный объем мультимедийной информации. После этого выполнение потока останавливается до тех пор, пока от управляющего приложения не придет сигнал о необходимости декодирования следующих пакетов. Существует возможность ускорения процесса декодирования поступающих потоковых данных благодаря использованию вычислений на видеокарте (GPGPU). Данная возможность способна значительно повысить скорость декодирования, однако дает дополнительную нагрузку на видеокарту.

Если видеокарта задействована в ресурсоемких процессах, например используется для визуализации, детализированной виртуальной трехмерной сцены, то она может не успеть своевременно декодировать поступающие данные, что может привести к рассинхронизации видео- и аудиоданных, задержкам и рывкам изображения. Несмотря на указанное ограничение, при необходимости декодирования нескольких потоковых видеоматериалов с разрешением 3840×2160 и выше использование мощностей видеокарты является оправданным.

Первоначально планировалось использовать стандартные фильтры, поставляемые вместе с ОС Windows, для демультиплексирования сигнала, поступающего с видеокамеры. Однако у данного подхода были выявлены существенные недостатки. Во-первых, для каждого выходного формата требуется свой фильтр демультиплексирования. Тестирование всех возможных выходных форматов является трудоемкой задачей. Соответственно, существует риск, что разработчик не сможет определить и предоставить вместе со своим приложением все необходимые фильтры, что повлечет за собой невозможность воспроизведения потоковых видеоматериалов на компьютере пользователя при определенной конфигурации оборудования. Во-вторых, для настройки работы фильтров демультиплексирования могут потребоваться дополнительные фильтры. Например, для фильтра-демультиплексора формата MPEG 2 требуется дополнительный PSI-фильтр, который по входящему на фильтр-демультиплексор сигналу определяет наличие видео- и аудиосигналов, и создает соответствующие выходы у фильтра-демультиплексора. Данный PSI-фильтр не поставляется вместе с ОС Windows и должен быть включен в комплект поставки приложения.

В-третьих, при использовании фильтров демультиплексирования могут возникнуть существенные проблемы с определением параметров входящего сигнала. Например, для успешного декодирования входного сигнала в формате MPEG 2 необходимо инициализировать подсистему декодирования FFMPEG с корректными параметрами. Для того чтобы получить данные из входного сигнала, необходимо в каждом поступающем с демультиплексора видеопакете проверять наличие так называемого заголовка начала последовательности (sequence header). В данном заголовке хранятся данные о высоте и ширине изображения, о формате видеокадра: независимо сжатые кадры (I-кадры), кадры, сжатые с использованием предсказания движения в одном направлении (P-кадры), и кадры, сжатые с использованием предсказания движения в двух направлениях (B-кадры), скорость передачи данных и т.д.

Кроме того, специфика формата MPEG 2 состоит в том, что присутствует механизм расширений, который позволяет хранить в заголовке начала последовательности только часть необходимой информации. Другая часть хранится в так называемом расширении заголовка начала последовательности (sequence extension). Для получения корректных данных о входном сигнале необходимо вручную, побитно (в MPEG 2 многие данные хранятся в нестандартных типах данных для экономии места, например переменная, определяющая высоту изображения, занимает 12 бит) декодировать входящие видеопакеты, объединить данные, полученные из основного заголовка и его расширения, и только затем применить полученные данные для инициализации подсистемы FFMPEG [6].

В зависимости от типа поставленной задачи применение аппаратных декодеров может быть предпочтительнее программных реализаций. Одной из таких задач является одновременное отображение разнородных типов видеоинформации в системах отображения информации коллективного пользования.

В отличие от программных декодеров, аппаратные декодеры зачастую ограничены в количестве воспроизводимых форматов. В настоящее время чаще всего применяются декодеры, способные декодировать формат сжатия данных H264, реже применяются декодеры, поддерживающие форматы MPEG 4 и H265. Аппаратные декодеры также вводят определенные ограничения на форматы отображаемых данных. В частности, некоторые декодеры могут не поддерживать воспроизведение видео с разрешением FullHD (1920×1080) и частотой 60 кадров в сек. Следует также обратить внимание на то, что аппаратные декодеры часто реализуют только часть стандартов декодирования, например многие декодеры H264 поддерживают только профиль сжатия «baseline». Соответственно, видео, сжатое другим профилем сжатия, воспроизводиться не будет или будет отображаться с графическими артефактами.

Для использования аппаратных декодеров в системах отображения информации коллективного пользования необходимо наличие стабильного потока поступающих видеоданных. Зачастую данные на аппаратный декодер поступают из локальной вычислительной сети при помощи одного из популярных протоколов передачи видео, таких как RTP, RTSP, RTCP [7]. Кроме того, видео- и аудиоданные обычно передаются в мультиплексированном потоке данных для снижения объемов трафика. Соответственно, для воспроизведения поступающих данных требуется определить протокол, при помощи которого передаются данные, произвести демультиплексирование и передать полученные аудио- и видеопакеты аппаратному декодеру.

Зачастую устройства, использующие аппаратные декодеры, обладают низкой вычислительной мощностью для решения задач, отличных от обработки видеоданных. Поэтому задача по приему, обработке и передаче данных аппаратному декодеру должна быть выполнена за наименьшее количество операций. Решение этой задачи возможно двумя способами: создание обрабатывающего программного обеспечения «с нуля» или доработка существующих программных библиотек.

Каждый способ имеет свои достоинства и недостатки. В случае написания собственного ПО «с нуля» возможно создание оптимизированного решения под конкретное устройство. Однако данный подход сопряжен с существенными временными затратами на создание и отладку программного кода. Второй способ позволяет быстрее получить результаты, однако существенно усложняет устранение ошибок, возникающих при работе в сторон- них программных библиотеках, а также является более затратным при оптимизации под конкретное устройство по сравнению с разработкой собственного ПО. В статье рассматривается способ с доработкой сторонних программных библиотек.

Одной из проблем, возникающих при приеме данных по ЛВС, является задержка при первоначальном воспроизведении видео. Она связана с определением параметров входящего потока данных. На сегодняшний день в большинстве случаев видеопоток, закодированный в формате H264, передается по сети в контейнере MPEG 2. Как было сказано выше в описании разработанного программного декодера, структура контейнера MPEG 2 предполагает пересылку параметров о видеопотоке только в составе группы изображений (Group of Pictures, GOP), количество которых определяется на этапе создания контейнера MPEG 2. Таким образом, нередко возникает ситуация, когда между двумя группами изображений проходит несколько секунд. Приемное устройство для определения параметров видеопотока должно обработать все приходящие пакеты в поисках группы изображений, что и приводит к задержкам в воспроизведении. Одним из решений данной проблемы является передача описания о пересылаемом потоке данных отдельным пакетом – данный подход позволит вручную настроить декодер до получения первого пакета и максимально снизить начальную задержку.

Необходимо подчеркнуть, что файл сессии sdp, используемый при передаче данных по протоколам RTP и RTSP, не содержит данных о разрешении передаваемого видеопотока, а только данные о формате изображения и частоте дискретизации [8]. Еще одним подходом является принудительное снижение времени анализа приходящего видеопотока до определенного значения (например одна секунда). Данный подход применим, если существует возможность настройки потока, передаваемого на устройства с аппаратным декодером [9-10].

Для параллельного отображения информации в мультиэкранных системах была разработана следующая архитектура программного модуля, включающая в себя: графический интерфейс управления системой; компонент воспроизведения поступающих данных, включающий в себя аудио- и видеоподсистемы; компонент обработки поступающих данных, включающий в себя подсистемы приема данных, демультиплексирования и декодирования.

При помощи графического интерфейса задаются источники данных для видео- и аудиосиг- налов. Источником данных может являться файл, внешнее устройство с потоковым сигналом, такое как видеокамера, или потоковый источник в сети Internet. Источник может содержать в себе одновременно видео- и аудиосигналы (мультиплексированный сигнал) или только определенный тип данных, например видео – в этом случае существует возможность выбора дополнительного источника данных со звуковыми данными. В разработанной системе мультимедийные данные, содержащие и аудио- и видеоинформацию, либо только видео, называются видеоматериалами. Воспроизведение данных, содержащих только аудиосигналы, не предусмотрено.

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

Компонент обработки поступающих данных состоит из четырех независимых частей, каждая из которых использует собственный поток обработки:

– блок управления, осуществляющий запуск, остановку, а также обработку ошибок, в случае их возникновения;

– блок получения пакетов из файла или внешнего источника, их демультиплексирование (при необходимости) и сортировка видео- и аудиопакетов по соответствующим очередям;

– блок декодирования видеопакетов;

– блок декодирования аудиопакетов.

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

Если видеосигнал получен из видеокамеры, то необходимо учитывать формат передаваемого изображения – прогрессивный или чересстрочный.

Большинство современных видеокамер применяют прогрессивный формат изображения, однако для снижения объема передаваемых данных может применяться чересстрочная развертка. Для устранения эффектов появления полос и мерцания изображения применятся деинтерлейсинг.

Системой предусмотрено автоматическое распределение воспроизводимых видеоматериалов по доступным экранам. В случае когда количество окон превышает количество доступных экранов, группирует несколько видеоматериалов на одном экране. Работа выполнена в рамках проекта № 2.9 программы фундаментальных исследований ОНИТ.

Выводы

Задача отображения данных на мультиэкранных системах является комплексной и требует решения ряда сопутствующих задач, в частности, задач декодирования и визуализации видеоданных. Декодирование и отображение видео может выполняться как программным способом, так и с использованием аппаратных средств декодирования, позволяющих применять устройства с меньшой производительно-стью. Разработанный программный декодер видеоматериалов может быть использован для воспроизведения видео на операционных системах Windows, Linux, MacOS. Проанализированы достоинства и недостатки существующих аппаратных декодеров, возможности и ограничения их применения в мультиэкранных системах. Созданная архитектура программного модуля отображения позволяет реализовать воспроизведение поступающих потоковых видеоматериалов в мультиэкранных системах в реальном масштабе времени. Планируется дальнейшее развитие разработанной системы, в частности рассмотрение возможности отображения одного видеоматериала на нескольких устройствах отображения информации.