Sync a New Level of Show
TIME SYNC PROTOCOLS. HOW SMPTE WORKS
Таймкод в шоу-индустрию пришел с телевидения. И называется он SMPTE. Аббревиатура расшифровывается как Society of Motion Picture and Television Engineers. Это ассоциация, которая приняла единый стандарт кодирования времени, разработанный в 1967 году. Чуть позже к ним присоединился EBU (European Broadcasting Union). Сейчас существует множество других стандартов записи таймкода, которые намного удобнее и функциональнее, но старый добрый SMPTE до сих пор жив и широко используется в шоу-индустрии.
LTC (Longitudinal Time Code)
Первая технология записи движущегося изображения появилась в кино. Изображение писалось на кинопленку кадр за кадром. Это был довольно большой прорыв. Позже, в 1920 году, на свет появилось телевидение, которое очень активно развивалось. Но мало кто знает, что долгое время все телевизионные программы передавались в прямом эфире! Тогда не существовало технологий записи и воспроизведения изображения для ТВ-трансляций. Первые ТВ-камеры были сделаны на основе иконоскопа. Это как кинескоп, который используется для формирования изображения, только наоборот: он преобразует видимый свет в электрический сигнал, который напрямую транслировался в эфир. Способов для записи такого сигнала тогда не существовало. Конечно, позже появились специальные технологии записи и трансляции телепередач и фильмов, но принцип оставался тот же самый: кинопроектор проецировал изображение напрямую в телекамеру. Правда, при таком способе качество изображения падало в разы.
AMPEX quadruplex VR-1000A, первый коммерчески выпущенный в конце 1950-х годов видеомагнитофон, использующий поперечно-строчную ленту с открытой катушкой шириной 2 дюйма
В 1956 году на свет появился первый видеомагнитофон (Video Tape Recorder), который мог записывать изображение и звук в аналоговом формате на ленту и воспроизводить эту информацию. Позже появилась необходимость также записывать информацию о времени, которая была бы синхронна с видеоизображением. Так как на видеоленте было несколько дорожек, предназначенных для записи аудио, одна из этих дорожек использовалась для записи таймкода, где в аналоговом формате был записан SMPTE-код. Такой способ записи SMPTE называется Longitudinal Time Code (LTC), или линейный таймкод. Такое название было дано потому, что информация в этом формате записывается бит за битом последовательно, так как по-другому на ленту информацию не записать. Спустя многие годы эта технология записи таймкода начала использоваться в шоу-индустрии.
SMPTE – это время, которое начинается с нуля. Так же, как и в обычной жизни, в SMPTE есть часы, минуты и секунды. Максимальное значение SMPTE – 24 часа, как и в сутках. Но есть и отличие от привычного для нас измерения времени – это кадры. Терминология пришла из кино. Так как одна секунда видео содержит в себе определенное количество кадров, то и временной код определяется видеокадрами. Но количество кадров может быть различным в зависимости от формата видео. Это применимо также для SMPTE, поэтому он может быть разным.
Есть несколько форматов SMPTE: 24fps (frames per second – кадров в секунду), 25fps, 30fps, 29.97fps (он же 30fps drop). Все эти значения, кроме 24 fps, были обусловлены форматом телевещания в конкретной стране – PAL, SECAM, NTSC – которые, в свою очередь, были обусловлены частотой электросети (50 Гц, 60 Гц) и стандартами передачи цветного изображения. 24 fps – это киноформат, так как кино снимается на пленку, где одна секунда содержит в себе 24 кадра.
В самом начале мы с вами договаривались, что в этой книге будет минимум лирических отступлений, но одно все же сделать нужно, так как эта информация нам нужна для понимания различия между линейным и другими форматами таймкода
Простейшей единицей информации в LTC является блок данных, передающий каждый кадр реального времени, поэтому он так и называется – кадр SMPTE. Для кодирования битов в LTC-сигнале используется схема под названием Bi-Phase Mark: нули кодируются одиночным переворотом фазы на границе периода, единицы – двумя переворотами (один на границе периода, другой в половине периода). LTC-кадр имеет длину 80 бит. Структура кадра показана на рисунке.
Время SMPTE кодируется методом BCD (Binary Coded Decimal). В этом методе под каждую десятичную цифру отводятся четыре бита. В кадре на запись времени отводятся 26 бит. Между ними присутствуют дополнительные данные, которые по большей части относятся к параметрам видеокадра, а также данные User Bits, которые в свободной форме могут использоваться для передачи дополнительной пользовательской информации. На данный момент такой способ передачи дополнительных данных не используется, и информация в этих областях всегда равняется нулю. Завершается блок данных синхрословом (последние 16 бит). Синхрослово используется для определения границы кадра, значение которого фиксировано: 0011 1111 1111 1101.
Если таймкод записан на ленту правильно, то при воспроизведении никаких проблем не возникает, так как информация записана физически. В этом и есть один из секретов надежности LTC.
МТС (MIDI Time Code)
Время прошло, и на телевидении SMPTE стали писать уже в других форматах: VITC, CTL, BITC, Keycode.
Поговорим теперь о другом варианте работы с SMPTE. Следующий интерфейс пришел из мира музыки. Это MIDI. Он очень обширен и позволяет работать с разными форматами данных. Более подробно о MIDI и его структуре мы поговорим в следующей главе, а сейчас затронем формат работы со временем. Называется он MTC (MIDI Time Code).
Первое отличие его от LTC в том, что этот формат полностью цифровой и кодируется в шестнадцатеричной системе исчисления (в то время как LTC кодируется бинарным способом).
Второе: этот формат нельзя записать на носитель (как LTC), он генерируется программно или аппаратно.
Теперь давайте подробнее затронем цифровую часть этого протокола. Существует два типа MTC сообщений: Full-message (полное сообщение) и Quarter-frame (четверть сообщения).
Full-message содержит в себе информацию целого таймкод кадра. Такое сообщение отправляется в определенных случаях: остановка, начало воспроизведения, перемотка и др.
Quarter-frame сообщения отправляются в случае штатного воспроизведения. Как следует из названия, в момент передачи одного таймкод кадра используются четыре Quarter-frame сообщения. Но вот парадокс, чтобы закодировать информацию о полном SMPTE кадре через MTC, необходимо использовать восемь Quarter-frame сообщений. Из этого следует, что, чтобы передать через MIDI информацию о полном кадре таймкода, необходимо потратить время, равное воспроизведению двух кадров SMPTE таймкода. Это означает, что к моменту, когда принимающее устройство декодирует информацию о полном кадре, она уже устареет на два кадра. А также из-за этой особенности принимающее устройство будет получать по MIDI только каждый второй кадр. Чтобы по итогу принимающее устройство смогло корректно интерпретировать принятый таймкод, оно должно сделать поправку на два кадра и также самостоятельно генерировать недостающие кадры. К сожалению, не все производители оборудования реализуют подобные алгоритмы, по этой причине MTC на разных устройствах может работать по-разному.
LTC и MTC – это основные форматы при работе с синхронизацией по времени. Чуть позже мы с вами еще вернемся к вопросу таймкода и разберем несколько альтернативных интерфейсов для кодирования и передачи времени.
EVENT SYNC PROTOCOLS
Поговорим теперь о протоколах, которые передают не время, а сообщения. Они обеспечивают синхронизацию по определенным событиям, а не по времени (в этом случае постоянная синхронизация отсутствует). В начале 70-х годов, в эру зарождения компьютерных технологий, разные компании экспериментировали и придумывали все новые и новые стандарты передачи данных, увеличивая скорость, надежность и дальность их передачи. К этому времени шоу-индустрия нуждалась в более продвинутом и функциональном протоколе синхронизации, так как LTC было уже недостаточно. Настало время появления на свет новых интерфейсов, которые сделали определенный прорыв в шоу-индустрии.
MIDI note / MIDI CC / MIDI PC
Как я уже говорил, новые разработки в мире синхронизации зачастую приходили из музыкальной индустрии. В конце 70-х годов особенное распространение получили музыкальные синтезаторы. Это были электрические музыкальные устройства, которые модулировали определенные звуки, управляемые напряжением.
Для каждой тональности звука существовал свой генератор. Модель каждого синтезатора характеризовалась эффектом или звуком, который она могла модулировать. В те времена рабочее место музыканта состояло из множества различных синтезаторов и управлять всем этим было очень непросто. Потребности росли – и в начале 80-х годов активно развивающиеся технологии в мире электроники подсказали решение этой проблемы. Был сделан шаг в сторону цифрового программного управления. Компании, производившие синтезаторы, смогли удачно договориться о разработке и поддержке единого стандарта интерфейса управления синтезаторами, первая спецификация которого появилась в 1982 году. Смысл заключался в разделении звукообразующего модуля и модуля управления, которые соединялись между собой по цифровому каналу. Протокол, разработанный для этих целей, передавал состояния нажатия клавиши.
Позже его функционал расширили большими возможностями. Благодаря такой системе музыкант мог с одной клавиатуры управлять сразу несколькими синтезаторами. Появилась возможность записывать и воспроизводить сыгранную мелодию. Сложно переоценить влияние нового протокола на музыкальную и шоу-индустрию в целом.
Дамы и господа, позвольте мне представить вам интерфейс синхронизации MIDI Musical Instrument Digital Interface. Несмотря на свой приличный возраст, MIDI до сих пор широко используется в разных направлениях шоу-индустрии.
Язык MIDI состоит только из команд управления и параметров этих команд. Команды в языке MIDI называются сообщениями. Сообщения разделяются на два основных типа: одни управляют звукообразованием, то есть говорят, какую ноту и как громко играть, вторые выполняют служебные функции, то есть регулируют изменения настроек тона генератора и синхронизации.
Сообщения первого типа называются сообщениями канала (Channel Messages).
Сообщения второго типа называются системными (System Messages).
Сообщения канала, в свою очередь, делятся на голосовые (Channel Voice Messages) и сообщения режима канала (Channel Mode Messages).
Системные сообщения делятся на общесистемные (System Common Messages), сообщения реального времени (System Real Time Messages) и эксклюзивные сообщения (System Exclusive Messages).
На изображении выше вы можете увидеть, какой MIDI-протокол к какому типу относится.
При работе непосредственно с MIDI-протоколом мы неоднократно встретим такой параметр, как MIDI Channel – программный канал передачи сообщений. Всего может быть 16 каналов. Этот параметр применим только к сообщениям группы Channel, соответственно, каждое сообщение MIDI note, MIDI CC и MIDI PC несет информацию о том, к какому каналу оно принадлежит. Каналы нужны для разделения в одном потоке нот разных инструментов. Это позволит нам отправить одновременно две одинаковые MIDI-ноты, но для генерации разных музыкальных инструментов.
MIDI note
В сообщении MIDI note содержатся три байта, в которых закодирована информация о номере канала, ноты и ее состояния. Нота может быть активна (Note on) или неактивна (Note off). Каждая нота имеет свой определенный номер – от 0 до 127. Каждый номер соответствует определенной ноте в определенной октаве. Для синхронизации устройств эти ноты могут передавать разные события, с которыми нужно синхронизироваться. Только в отличие от музыкального устройства, принимающее оборудование не генерирует звук, а выполняет определенное действие.
К примеру, можно настроить на световом пульте и на мультимедиа-сервере следующее: при получении ноты до первой октавы первого канала необходимо запустить световую программу и видеоконтент. При получении по MIDI этой ноты мультимедиа-сервер и световой пульт запустят свои программы синхронно. Особенность такого способа в том, что при большом количестве разных команд MIDI note можно запутаться в обозначениях. К тому же при изменении шоу, перемещении CueList внутри пульта нужно следить за ссылками MIDI-команд: будут ли они выполнять то, что нам нужно.
MIDI CC / MIDI PC
Сообщения MIDI CC (Control Change) и MIDI PC (Program Change) очень похожи на сообщения MIDI note. Сообщения этого типа кодируются тремя байтами, где также содержится информация о канале, номере параметра и его состоянии. Используются они для изменения программы с набором инструментов воспроизведения, а также других настроек синтезатора.
Чаще всего при помощи сообщений MIDI CC и MIDI PC производят синхронизацию линейных параметров. К примеру, уровень фейдера или регулятора на MIDI-контроллере. Используя эти сообщения, вы можете передать состояния 128 параметров управления, где каждый канал имеет диапазон от 0 до 127.
MSC (MIDI Show Control)
В определенный момент простого звукового MIDI протокола стало недостаточно для театрально-концертных нужд, и встал вопрос о создании более специализированного протокола управления.
К концу 1989 года Charlie Richmond организовал рабочую группу в составе MMA (MIDI Manufactures Association) и создал общий форум на электронной доске USITT (The United States Institute for Theatre Technology). Созданный в результате проект стандарта был утвержден MMA и JMSC (Japanese MIDI Standard Committee) и 25 июля 1991 года превратился в «Рекомендованную практику RP-002», или иначе – в MIDI Show Control версии 1.0.
Сообщения MIDI Show Control относятся к категории универсальных эксклюзивных сообщений реального времени (Universal Real Time System Exclusive).
В спецификации MSC используется терминология Controller и Controlled Device. Устройство, которое генерирует MSC сообщения, называется Controller, обычно это компьютер со специализированным софтом и MIDI картой. Принимающие устройства, световые пульты, медиа серверы и остальные исполняющие контроллеры— это Controlled Device.
Особенность MSC в том, что сообщения этого формата имеют определенные категории. Они делятся на основные (General Categories) и дополнительные подкатегории. Также есть особая категория All-types, сообщения этого типа транслируются на все типы контроллеров. К общим категориям относятся свет, звук, машинерия, видео, проекция, спецэффекты и пиротехника.
Ко всему этому в MSC сообщении передается информация об устройстве, которое должно получить команду. Каждое устройство внутри одной категории имеет свой собственный ID. Выставляется он вручную в настройках принимающего контроллера.
Внутри одной категории ID всех устройств должны быть разные. Уникальный ID каждого устройства может быть в диапазоне 1–111.
Что нам дает использование ID? Теперь можно каждому принимающему контроллеру отправлять команды, предназначенные конкретно для него, а все остальные контроллеры, которые имеют другую категорию оборудования и ID, эти сообщения будут просто игнорировать.
Также в идеологии MSC есть такое понятие, как Group ID и Broadcast ID.
Каждое устройство может иметь уникальное ID, но при этом быть подписанным на групповые сообщения. Для этого в MSC зарезервированы специальные групповые ID c 112 до 126.
Всего, может быть, 15 независимых групп. Чтобы конкретную команду получили клиенты, подписанные на группу, серверу нужно просто отправить MSC сообщение на один из групповых ID.
Также есть один зарезервированный ID, равный 127 для широковещательных команд. MSC команду, отправленную на этот ID, получат все клиенты.
Дополнительное преимущество MSC перед MIDI note в том, что сообщения этого протокола содержат конкретные команды для действия, а не просто код сообщения, к которому нужно привязывать действие на конечном контроллере. Есть основная группа MSC сообщений – General Commands, которые применимы для всех типов устройств. Помимо General Commands, есть дополнительная группа Sound Commands специально для звуковых систем синхронизации. Для общей синхронизации нам интересны только команды типа General Commands.
Итак, с командами разобрались, куда отправлять команды, тоже
понятно, теперь поговорим о том, к чему эти команды применимы. В MSC сообщениях есть часть кода, в которой зашифрована информация об объекте в контроллере, к которому нужно применить команду.
Этот код состоит из номера сцены, к которой применять команду (CueNumber), в каком списке находится эта сцена (CueList) и путь туда, где находится список сцен (CuePath). Последнее значение осталось еще с тех времен, когда световые пульты сохраняли свои шоу на флоппи дискеты и пульт мог воспроизводить световые сцены как с внутренней памяти, так и с внешнего носителя. QuePath как раз и указывал, где находится финальная цель сообщения.
Не все сообщения из всех команд MSC несут в себе объект, к которому нужно применить команду, в основном это глобальные команды, как, например, ALL OFF или RESET.
Резюмируя все особенности MSC, можно сказать следующее:
• В MSC сообщении содержится информация о том, к какому типу устройства и к какому по номеру устройству предназначается сообщение: Command Format, Device ID.
• MSC сообщение имеет команду, которую нужно выполнить на принимающем устройстве – Command.
• MSC сообщении есть информация, к какому объекту в принимающем устройстве применить команду – Q Number, Q List, Q Path.
Эти возможности во много раз расширяют функционал MSC перед простыми звуковыми MIDI сообщениями. Это позволяет быстро запрограммировать команды на главном контроллере для синхронизации шоу. При этом нет необходимости в сложных настройках на световых консолях и других принимающих устройствах. Всю необходимую информацию они получают по протоколу управления.
Теперь снова вернемся к истории. MSC v1.0 стал настолько популярным, что позже была разработана новая усовершенствованная версия MSC v1.1. Основное его отличие заключалось в том, что эта версия MSC теперь подразумевало обратную связь между сервером и клиентом. Применение новой версии протокола было нацелено на опасные системы, такие, как, к примеру, механика сцены
В новой идеологии протокола клиент перед тем, как получить данные с сервера, должен отправить ответ серверу о возможности выполнения действия, и после получения команды он также должен сообщить серверу, удалось ли выполнить команду или нет. Такая система подтверждения команд рассчитана на то, чтобы повысить безопасность управления сложными системами. Но кроме явных преимуществ обратной связи с сервером был один недостаток, заключался он в скорости синхронизации. Сервер не мог отправить новую команду до тех пор, пока не был получен ответ о выполнении предыдущей команды. К сожалению, усложненная версия MSC v1.1 так и не получила широкого применения в шоу-индустрии. А вот MSC v1.0 был долгое время очень популярен, пока на его смену не пришли новые протоколы, основанные на современных технологиях передачи данных.
MCC (MIDI Machine Control)
Использование MMC для синхронизации в шоу-индустрии применяется довольно редко. Но мы тем не менее еще можем встретить оборудование, которое может генерировать и принимать MMC сообщения. Этот протокол был разработан для того, чтобы дистанционно управлять профессиональными многодорожечными видео и аудио рекордерами на студиях. Основное назначение MMC команд – передача сообщений разных режимов воспроизведений и записи.
Команды MMC находятся в группе SysEx сообщений. MMC сообщения так же, как и MIDI Show Control, несут в себе информацию о номере устройства Device ID и команду. Все команды, которые можно передать в MMC сообщении, находятся ниже в таблице.
Как мы видим, некоторые команды могут нести дополнительную информацию. Как, например, команда Goto, которая передает также время, на которое необходимо перейти устройству. Мы не будем подробно разбирать этот протокол, так как он уже устарел и для синхронизации практически не используется. Но мы все равно его затронули, потому что некоторые профессиональные таймкод генераторы поддерживают этот тип сообщений для настройки и старта генерации времени.
OSC (Open Sound Control)
Время идет и технологии не стоят на месте. Протоколу MIDI уже почти сорок лет! И конечно же, ему на замену пришла более современная альтернатива Open Sound Control. Как понятно по названию, и этот интерфейс пришел из мира музыки. Но как и следовало ожидать, другие направления шоу-индустрии быстро его освоили. Сейчас этот протокол настолько популярен в разных направлениях шоу технологий, что позже сами создатели дали ему второе название: Open System Control. Что же в нем особенного? Давайте разберемся.
Этот протокол был разработан в компании CNMAT (Center for New Music and Audio Technologies) программистами Adrian Freed и Matt Wright еще в 1997 году. У них появилась идея создать новый протокол на базе широко используемого интерфейса Ethernet. Главное преимущество его в том, что для работы с этим протоколом не нужно никакого специального оборудования и коммутации, как в случае с другими интерфейсами и протоколами синхронизации. Также, Ethernet – это отдельное направление, которое развивается и поддерживается разными компаниями и институтами. Сейчас технологии позволяют передавать сигнал по Ethernet, по воздуху и оптическому каналу на многие километры. А скорость передачи по сравнению с MIDI в тысячи раз быстрее, при этом соединение надежнее. Все эти преимущества автоматически унаследует протокол OSC. Но кроме ряда преимуществ есть и недостатки. Он стал сложнее, а как следствие, специалисту необходимо иметь больше знаний об этом протоколе для работы с ним. Как раз цель этой главы – дать вам знания для комфортной и уверенной работы с протоколом синхронизации OSC.
Концепт построения сетей
Так как OSC базируется на сетевом интерфейсе Ethernet, то прежде чем работать с этим проколом, необходимо настроить сеть. Я уверен, что вы и так прекрасно ориентируетесь в этом вопросе, и то, что вы прочитаете ниже, для вас будет не ново, тем не менее я рекомендую освежить свои знания в этом направлении.
Первое, с чем необходимо познакомиться, это с группой протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). Концепт работы со всеми протоколами описан уровнями (слоями), через которые должен пройти каждый пакет данных при отправке или получении.
TCP/IP Уровни (Layers)
Уровень 1. Физический уровень
Уровень 1 является физическим уровнем. Это оборудование интерфейсов, включая электронику и провода.
Уровень 2. Дата линк уровень
Уровень 2 тесно связан с оборудованием. Этот уровень занимается тем, что собирает данные в пакеты для отправки через Физический уровень. Также этот уровень отвечает за корректную передачу и прием данных и исправление ошибок. На этом уровне появляется такое понятие, как MAC адрес (Media Access Address2).
Уровень 3. Сетевой (Internet) уровень
Это Сетевой уровень, отвечающий за логическое направление данных через сеть.
В большой сети может быть множество логических маршрутов связи между устройствами, по которым пакеты данных могут передаваться. Этот уровень занимается анализом доступных возможностей в сети и выбором подходящего маршрута.
Уровень 4. Транспортный уровень
Этот уровень ответственен за обеспечение того, чтобы низкоуровневые пакеты данных были собраны в их оригинальной форме, правильном порядке и без ошибок.