Синхронизация кадров видеоизображения с частотой обновления экрана

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

Введение

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

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

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

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

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

Цикл обновления дисплея

Частота обновления экрана ПК (screen refresh rate) синхронизируется с частотой графического адаптера (видеокарты). Рассмотрим самый общий пример ­– когда видеокарта и монитор поддерживают частоту 60Гц. Эта комбинация возможна благодаря тому, что монитор синхронизируется с сигналом 60Гц, поступающим с видеокарты. На самом деле, монитор поддерживает синхронизацию даже в случаях незначительного отклонения частоты выходного сигнала графического адаптера (например, 60,06 Гц вместо стандартных 60 Гц).

В течение цикла обновления изображение на экране перерисовывается из буфера дисплея (адресуемой памяти графического адаптера). Происходит последовательное обновление каждой горизонтальной строки на дисплее в соответствии с новыми данными, содержащимися в буфере видеопамяти. Обновляемая в данный момент времени строка называется строкой развертки. В случае графического адаптера с частотой 60 Гц, процесс обновления экрана происходит 60 раз в секунду, таким образом, изображение на мониторе ПК также обновляется 60 раз в секунду.

Рисунок 1 – Обновление дисплея

Артефакты разрыва изображения

Следует учитывать потенциальную проблему неравномерного обновления буфера графического адаптера. Если содержимое буфера видеопамяти изменилось в момент, когда изображение на мониторе еще полностью не отрисовалось (цикл обновления не завершен), то на экране будет показана только часть нового изображения, следующая после строки развертки (см. Рис. 2). Этот артефакт изображения, при котором на верхней части экрана показывается старое изображение, а на нижней части – новое изображение, получил название «разрыва» (tearing). В сущности, этот термин весьма нагляден, так как получающееся в итоге изображение выглядит как бы «разорванным» пополам.

Рисунок 2 – Артефакты «разрыва» изображения

Команда Flip

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

По этой причине был предложен алгоритм синхронизации переключения буфера (Flip). Команда Flip весьма проста по своей сути – она позволяет программе обновлять изображение в любой момент цикла обновления экрана, однако его результат фактически не передается в видеопамять до тех пор, пока не завершится текущий цикл. Таким образом, обновление изображения на мониторе происходит в интервал, следующий за выполнением команды Flip. При использовании метода синхронизации буфера «разрывы» изображения исключены, так как команда Flip гарантирует, что к каждому циклу обновления будет готово полное новое изображение (см. Рис. 3). Тем не менее, в следующем разделе мы продемонстрируем, что использование одной лишь команды Flip не гарантирует решения всех проблем.

Рисунок 3 – Последовательность команды Flip

Потенциальные проблемы

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

При использовании команды Flip условия программного рендеринга видео изменяются. Для исполнения Flip программному обеспечению приходится регулировать интервал обновления кадрового буфера (frame rate) в соответствии с определенной частой кадров. Единственной тактовой частотой, на которой кадры могут быть синхронизированы, является частота обновления дисплея (или кратная). Другими словами, новый кадр может быть изображен только в начале цикла обновления – фактически, интервалы вывода кадров привязаны к частоте обновления дисплея.

Рисунок 4 – Несовпадение частоты кадров и частоты дисплея

Этот факт подразумевает, что если частота обновления дисплея не совпадает с частой кадров воспроизводимого содержимого или не является кратной величиной, полноценное воспроизведение содержимого на дисплее невозможно. На Рис. 4 показан частный случай данной проблемы. В рассматриваемом сценарии частота кадров содержимого меньше, чем частота обновления дисплея. По причине фазового сдвига между этими двумя частотами интервалы выполнения команды Flip для двух кадров в конечном итоге растянутся на полный цикл обновления (обратите внимание на синхронизацию кадров 3 и 4). В результате кадр 3 будет отображаться почти в два раза дольше, чем требуется. Таким образом, следует стремиться к совпадению частоты кадров и частоты обновления дисплея, хотя это и не всегда возможно.

Рассматриваемая ситуация только усугубляется в случае, если разница между частотой кадров и частотой обновления дисплея невелика. Когда время смены кадров близко к интервалам циклов обновления даже небольшие неточности в расчетах программного таймера могут привести к тому, что несколько последовательных команд Flip будут сбиваться относительно начала обновления. Это означает, что некоторые команды Flip будут выполняться слишком рано, а некоторые слишком поздно, что приведет к появлению «дублированных» и «выпавших» кадров. Данный случай проиллюстрирован на Рис. 5 – таймер срабатывает некорректно (через неравные промежутки), в результате кадры 2 и 4 не показываются, а кадры 3 и 5 показываются дважды.

Рисунок 5 – Результат использования Flip при сбоях таймера

Это явление может иметь место даже в том случае, когда частота кадров содержимого и частота обновления дисплея одинаковы. Очевидно, что использование лишь таймера и команды Flip недостаточно для обеспечения качественного воспроизведения видео. Как объясняется в следующем разделе, для правильного выполнения команд Flip программное обеспечение должно поддерживать ”умную” синхронизацию с циклами обновления дисплея.

Привязка команд Flip по времени

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

Лучше всего вызывать команду Flip в самом начале цикла обновления, непосредственно перед началом соответствующего интервала обновления кадра (см. пример на Рис. 3). Это дает наибольшую вероятность фактического выполнения команды до начала соответствующего цикла обновления и обеспечивает вывод кадра в нужный момент. Следует учесть, что в случаях, когда частота видео кадров и частота обновления дисплея не совпадают, оптимизации цикла обновления кадров с помощью Flip недостаточно для обеспечения видео приемлемого качества. Существуют некоторые способы формирования или изменения кадров содержимого, которые позволяют устранить указанные проблемы, однако они выходят за рамки данной публикации.

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

WaitForVerticalBlank() – это стандартная процедура библиотеки DirectDraw (в рамках интерфейса IDirectDraw), которая блокирует обращающийся к интерфейсу поток до начала следующего цикла обновления. Эта процедура может быть использована для синхронизации, однако ее следует выполнять однократно или со значительным интервалом, поскольку обращение к ней сопряжено с большими затратами времени. Тем не менее, данная процедура полезна при выполнении начальной синхронизации с циклом обновления.

GetScanLine() - это стандартная процедура, которая может использоваться для получения данных о том, какая строка развертки в настоящий момент обновляется на дисплее. Если известно общее количество строк и текущая строка развертки, то не составляет труда определить состояние цикла обновления дисплея. Например, если общее количество строк дисплея составляет 1024, а процедура GetScanLine() возвращает значение 100, текущий цикл обновления в данный момент определяется отношением 100 к 1024, то есть завершен примерно на 10 процентов. Применение GetScanLine() позволяет приложению отслеживать состояние цикла обновления и на его основе определять, к какому циклу привязывать следующий отображаемый кадр, и настраивать таймер на нужное время переключения буфера. Ниже приводится примерный алгоритм:

Рисунок 6

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

Альтернативное решение для записанного содержимого

Рассматриваемые нами проблемы относятся ко всем сценариям воспроизведения видео, как в случае вещания в прямом эфире, так и при воспроизведении записанного видео. Однако, в последнем случае можно прибегнуть и к альтернативному решению. Если разница между частотой кадров содержимого и частотой обновления дисплея невелика, можно скорректировать частоту кадров видео (и таким же образом скорректировать аудиопоток) таким образом, чтобы он соответствовал частоте обновления экрана, без ухудшения качества содержимого. В качестве примера возьмем воспроизведение телевизионного сигнала стандартного разрешения с частотой 59,94 кадров в секунду (с деинтерлейсингом по алгоритму Bob) на мониторе с частотой 60 Гц. За счет ускорения воспроизведения видео и аудио до 60 кадров в секунду можно добиться того, что время смены кадров будет соответствовать интервалам обновления экрана и при этом не будут возникать артефакты изображения.

Резюме

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

Дополнительные сведения

DirectX 9.0 SDK, ©2004, Microsoft Corporation.

http://microsoft.com/directx*

Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.
Категории: