Мир вокруг меняется, кассеты сменились дисками, а диски — файлами, файлы — стримингом, но если задуматься, это не революция, а эволюция. Революция сопровождает сейчас преимущественно газетно-журнальную журналистику, а радио и интернет просто адаптируются. Печатным журналистам нужно осваивать мир, ставший во много раз более динамичным, в то время как формат телевизионного и радиовещания по сути не поменялся. Телеканал «Дождь», например, стал охватывать интернет-аудиторию, но никакого технологического прорыва в самом вещании не случилось. С точки зрения механизма доставки контента сменилась только среда передачи данных, разве что появилась возможность смотреть архив, да читать расшифровки. Телевидение идет в сторону количественного развития, а не качественного — увеличиваются мегапикселы, в звонках в эфир пейджеры и телефоны сменяются твиттерами и форумами. Скоро до нас дойдет цифровое радио — но по сути, это просто другая упаковка того же стриминга. Революции нет.
В сегодняшней статье я хочу поделиться с вами своим представлением о технологической революции в аудио- и ТВ-вещании. Точнее, ее технической основой. Мне не удалось встретить ничего похожего, и буду признателен за наводку на хорошие примеры.
Речь пойдет об открытом проекте протокола стриминга аудио и видео, позволяющем использовать максимально возможности плеера-приемника.
Кратко о технологии
Для знакомых с HTML и CSS объяснение будет простым. Представьте себе, что HTML-страница бесконечна, но на лету можно ее дополнять, заменять стили, изображения и джаваскрипты. И представьте, что таким вот HTML описывается не визуальная страница, а мультимедийный стриминговый аудио- или видеоконтент.
В качестве еще одной «параллели из нашей реальности» вспомним Youtube. При открытии страницы с видео мы сначала загружаем HTML, затем ресурсы — джаваскрипты, CSS, картинки, флэш-модули, причем что-то из этого всего берем из кэша, если оно использовалось ранее и не поменялось, затем флэш-модуль (или сам браузер, если HTML5) начинает тянуть стриминг-контент — собственно видео, походу отдельными каналами подгружается реклама, накладывающаяся на видео.
В итоге выходит, что наш плеер-приемник собирает аудиопоток из составляющих — MIDI-фоновая музыка, голос, рекламные ролики, текст воедино в соответствии с некоторой логикой. Часть этой логики хранится в настройках плеера-приемника, часть — приходит вместе с этим контентом из эфира. Плеер-приемник может использовать механизм синтеза речи или отображение текста/графики/видео на экране (если он есть у приемника). Ну и конечно, у него есть буферизация, позволяющая подгружать контент заранее, до того, как он должен «выйти в эфир», использовать его для других нужд. Например, реклама приходит только один раз и потом много раз за день прокручивается, в это время подгружается что-то еще.
Ключевое отличие от цифрового радио или ТВ в том, что архитектура не ограничивает приемник одним потоком одного типа, позволяет совершенствовать приемники и передатчики, сохраняя протокол и совместимость со «старыми» устройствами. К примеру, получим мы лет через 5-10 совершенный синтез речи, и по отдельному каналу можно гнать текст целой аудиокниги с MIDI-музыкой. В том, что кроме прямого эфира владелец приемника получает массу закэшированного контента, который можно слушать и до, и после, и сохранять «на флэшку», и перематывать на начало «с прямого эфира», и слушать в «расширенном варианте» и т.д. В том, что активно используется кэширование и повторное использование контента.
Каким должен быть приемник для такого контента?
Да, фактически это компьютер, со специализированным «браузером». Приемники могут быть понавороченее (если это радио, то с экранчиком, большой памятью, хорошей аудиочастью) и попроще. Они могут поддерживать обратную связь (делать запрос к серверу) или не поддерживать (играть, «что дают»).
Специализированный плеер-приемник такого протокола имеет несколько параллельных каналов, курсор, двигающийся по шкале времени, микширующий соответствующие куски в каждом из каналов, закэшированные ресурсы. Один из каналов — управляющий, по сути, это программа, собирающая контент из других каналов в один, учитывающий предпочтения пользователя. Например, какой-то канал может содержать «аудиосубтитры», которые приемник может озвучивать самостоятельно или не озвучивать совсем, а другой канал содержать бегущую строку новостей.
Каким должен быть протокол?
По сути, это стриминговый протокол, поддерживающий обратную связь (если на это способен приемник) и специальный язык управления/разметки, ориентированый на мультимедийный контент.
Каким должен быть передатчик?
?
Для интернета и для радиоэфира архитектура выглядит несколько разной. Для систем с обратной связью (интернет, например), где нагрузку на канал желательно минимизировать, работает схема веб-сервисов — приемник делает запрос, получает ресурс или поток, то есть, схема аналогично имеющейся в сети. Для радиоканала без обратной связи можно передавать ресурсы регулярно, равномерно нагружая канал по полной. Тут как с телетекстом — пришла информация, приемник ее у себя записал и готов, если понадобится ее вытащить и использовать, а пока ее нет — молчит, все ждут, да. Возможны смешанный режим — сразу после включения идет голос, потом его догоняет фоновая музыка в MIDI, отдельным каналом загружается рекламный ролик, который по программе дожен включиться в начале часа.
Это открывает море возможностей для построения «умных приемников», адаптированных под те или иные нужды.
Backward compatibility
Интересной особенностью этого протокола является то, что он совместим с существующим «старым радио» или «старым ТВ» и позволяет мягко перейти на новую систему. По сути, при переходе на подобную систему сначала создается канал с существующим вещаним, затем к нему прибавляется один опциональный канал, передающий то же, но логически разбитое на части (реклама, новости, погода и т.д.), затем потихоньку появляется все больше устройств, которые преимущественно используют этот «продвинутый» набор каналов и пользователей «старого радио» становится все меньше, в итоге оно когда-нибудь отключается вообще.
Из существующих систем мне не удалось найти ничего в области аудиостриминга, и какие-то отдаленно похожие системы в области ТВ-приставок (settopboxes). Например, есть такая технология HbbTV — Hybrid Broadcast Band TV. Специальные приемники, объединение навигации по информации с видеопотоком. Там можно, например, посмотреть детальную информацию по футболисту параллельно трансляции.
Есть близкая к описанному выше технология CMML — Continuous Media Markup Language или связанный с ним Annodex или Kate.… Но большого развития они не получили и концепции, заложенные в них — лишь срез описанного выше.
Как вы думаете, «взлетит» что-то подобное?
Автор: raliev
