Створення комплексу синхронного відтворення контенту
Все життя вважав себе технарем і взагалі людиною далекою від мистецтва. Але так склалося життя, що останні роки професійна діяльність пов'язана з мистецтвом загалом і театрами зокрема. Історією створення одного із проектів хочу тут поділитися. Область театрального мистецтва дуже специфічна. Особливістю роботи з творчими людьми є їхня непередбачуваність. Тому працювати потрібно швидко, якісно (код пишеться фактично з першого разу з мінімальним налагодженням) і заздалегідь закладати в прилади можливість гнучкого налаштування під бажання замовника, що змінюються.
З великими театрами та постановками все може бути дещо простіше — там уже є багато сучасного обладнання та грамотних спеціалістів, здатних зробити якісний контент. Проблеми найчастіше виникають із невеликими об'єктами — музеями чи інтерактивними театрами. Там з усього обслуговуючого персоналу добре, якщо є один електрик і пара екскурсоводів. Та й бюджети у таких проектах зазвичай не дуже великі.
Після аналізу вихідних текстів програвача проекту omxplayer-sync-2 (https://github.com/pukster/omxplayer-sync-2) стало зрозуміло, що він може вирішити наші завдання. Плеєр мав можливість апаратного декодування потоку h.264, використовував бібліотеку ffmpeg (що давало велику свободу у виборі формату зберігання контенту) та синхронізацію кількох відомих плеєрів з майстром протоколу UDP, що не створювало великого навантаження на мережу.
У процесі налагодження цього проекту з'ясувалися й недоліки. Алгоритм був написаний таким чином, що спочатку необхідно запустити всі відомі в режимі очікування, а потім останнім запустити майстер, який давав команду на старт усіх плеєрів. Логіка старту була змінена на універсальнішу — коли при запуску веденого вінавтоматично підхоплює позицію відтворення майстра.
Сам протокол синхронізації теж був доопрацьований з урахуванням ідей з протоколу NTP, що дозволило веденим отримати точну позицію відтворення майстра з урахуванням затримки передачі пакетів Ethernet.
По апаратній частині плата Raspberry Pi була доповнена зовнішнім процесором, який обробляє потік DMX-512 в обидві сторони плюс транслює RDM, декодерує синхросигнал SMPTE і зв'язується з виносною платою кнопок запуску основного шоу однією з чотирьох мов.
Окремою проблемою виявився звук. Передбачалося, що HDMI-виходу у форматі 5.1 з майстер-плеєра на кімнату буде достатньо. Але в одній із кімнат каналів не вистачило. Вирішили використовувати аудіовиход веденого плеєра. Композитор писав звук на двох ноутбуках Macbook, синхронізованих через протокол MIDI Timecode. При цьому було чути, що звук веденого комп'ютера часом розсинхронізується з ведучим. Некритично, але чути. Коли готовий проект скопіювали на плеєри і запустили, то навіть чуйне вухо композитора не змогло причепитися. Було повне відчуття що грає одна багатоканальна аудіо система.
Результат доопрацювання викладено назад на GitHub.
Якщо хтось захоче подивитися результат на власні очі — ласкаво просимо до міста Таллінна.
Повністю всі роботи були виконані за 6 місяців командою з: