Со спутника видео передается либо в кодеке MPEG-2, либо в H.264 (он же AVC или MPEG-4 part10). Как правило для простоты MPEG-4 part 10 сокращают до MPEG-4, но тут важно не спутать с MPEG-4 part 2, который совершенно никак не совместим и не похож на H.264 и использовался в старых IP камерах.

Аудио передается в MPEG audio layer 2 (сокращенное mp2), либо в ac3 (a/52).

Причём важно понимать, что сегодня H264 как правило сжимается с intra-refresh, т.е. в видео потоке нет опорных кадров (IDR или keyframe). Такой метод сжатия позволяет сгладить скачки битрейта.

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

При передаче через интернет как правило можно смело сжимать видео из mpeg2 в h264 с трехкратным снижением трафика.

При передаче HD каналов через интернет сегодня приходится сжимать поток в несколько разных качеств: от HD с максимальным качеством до стандартного SD для компенсации перегруженных каналов.

В итоге видео со спутника для предоставления качественного OTT сервиса надо транскодировать в другие кодеки и качества.

Важно не путать транскодирование с перепаковкой. Транскодирование - крайне ресурсоёмкая операция, включающая в себя:

• распаковку потока до кодированного видео/аудио
• декодирование до сырого видео/аудио
• изменение размеров и прочих параметров
• кодирование обратно
• упаковка в транспорт для потока

Упаковка и распаковка относительно легкие операции, стриминговый сервер может обрабатывать до 1000 каналов на одном компьютере. Транскодировать на одном компьютере можно от 1 до 30 каналов в зависимости от размера и мощности компьютера.

Для транскодирования можно использовать специализированные выделенные устройства, центральный процессор или видеоплату: внешнюю или встроенную в процессор.

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

H.264

Для обработки видео на CPU существует несколько разных программ, но по большому счёту на сегодняшний день существует лишь две библиотеки, которые имеет смысл использовать для сжатия в кодек H.264 на CPU: это бесплатная libx264 и платная MainConcept. Всё остальное либо хуже, либо сильно хуже, причём как по выходному результату, так и по использованию ресурсов.

Практика работы с MainConcept в этой статье рассматриваться не будет, будет упомянута только libx264

Кодек H.264 является стандартом де-факто на сегодняшний день для видео, потому что он поддерживается во всех современных устройствах, за исключением разве что некоторых устройств от Google.

Альтернатив ему практически нет. Сегодня появился и развивается H.265, у него уже есть большая поддержка, но пока что работа с ним - это инвестиции в будущее.

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

При кодировании видео надо понимать, что приходится балансировать между такими параметрами:

• задержка внутри энкодера в кадрах
• использование CPU (сколько миллисекунд требуется на сжатие одного кадра)
• выходное качество картинки (насколько пиксельная и какие цвета)
• выходной битрейт

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

Для VOD такого жесткого ограничения нет и фильм длиной в час вполне можно кодировать три часа, если хочется понизить битрейт. При этом для эфирного видео обычно всё таки стараются использовать не всю мощность процессора, что бы обрабатывать на одном компьютере не 4 канала, а 10.

Что касается задержки внутри энкодера, то она критична для видеоконференций, но совершенно некритична для IPTV. Даже 5 секунд задержки при вещании телевидения не меняют качество сервиса.

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

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

Flussonic Media Server для транскодирования

Отдельным пакетом к Flussonic Media Server идет транскодер .

Flussonic Media Server может декодировать видео из UDP/HTTP MPEG-TS, RTMP источников и кодировать его в несколько качеств и размеров.

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

Важно отметить, что для того, что бы видео игралось на айфоне, надо даже H264 со спутника транскодировать, потому что как правило на спутнике для плавного битрейта используется intra-refresh режим кодирования, создающий видео, которое не играется на айфоне.

Flussonic Media Server удобнее чем VLC или другие варианты для организации транскодирования, потому что управляется одним конфигурационным файлом и автоматически следит за состоянием транскодирования. VLC же требует написания большого количества мониторинговых скриптов для отслеживания состояния транскодирования.

Следующая важная возможность Flussonic Media Server для транскодирования - автоматическая перебалансировка потоков при падении одного из серверов. Если один из 20 транскодеров ночью сломается, то остальные транскодеры можно настроить на автоматический захват потоков для транскодирования, причём стример сам заберет потоки с резервных транскодеров.

Потребность в транскодировании видео

Сегодня технологии сжатия цифрового видео важны практически во всех типах видеоприложений. Значимость таких параметров как сжатие и совместимость данных еще более возрастает из-за усиливающейся тенденции к конвергенции средств коммуникации.
К наиболее известным приложениям в области цифрового видео относятся DVD, телевидение высокой четкости (HDTV), видеотелефония/обеспечение телеконференций и, с недавних пор, видеонаблюдение. Каждая из этих технологий имеет свою историю развития, соответственно, в каждой из них существуют собственные алгоритмы сжатия.
Транскодирование играет две важные роли. Во-первых, оно обеспечивает коммуникации между существующими и вновь появляющимися устройствами. Например, многие существующие системы видеоконференций основаны на стандарте кодирования видеоданных H.263. Более новые системы видеоконференций используют базовый профиль H.264/AVC. Таким образом, для обеспечения коммуникации между этими системами необходимо транскодирование видео в реальном времени. Во-вторых, информационные сети, в особенности Интернет, имеют ограниченную пропускную способность при передаче видео. Так, большинство видеофильмов в настоящее время хранится на дисках DVD в формате MPEG2. Ограничения на пропускную способность в сервисах видео по запросу и потокового видео по IP-сетям требуют преобразования этих видеоданных в формат с большей степенью сжатия. Это достигается путем транскодирования видео в режиме реального времени перед передачей. В целом, в результате транскодирования высвобождается до 50% пропускной способности сети без потери качества видео.
Транскодирование в видеоконференциях

Итак, одно из применений транскодирования – системы видеоконференций. Рассмотрим типичную схему транскодирования, применяемую в таких системах (рис.1). Один сигнальный процессор (DSP2) декодирует входной видеопоток и генерирует восстановленный видеокадр, который передается на другой цифровой сигнальный процессор (в данном примере это DSP1) через последовательный интерфейс RapidIO (sRIO). DSP1 кодирует восстановленный видеокадр в нужный формат. Обычно на одной стороне видеоконференции используется оборудование на базе стандарта H.263, тогда как другая сторона использует оборудование на базе стандарта H.264.
Хост-процессор, управляющий сетевым трафиком, взаимодействует с несколькими цифровыми сигнальными процессорами (в данном случае с четырьмя) через соединение по шине PCI.
Ключевая особенность взаимодействия процессоров в этом примере – это их соединение через интерфейс sRIO. Поскольку данные, передаваемые между цифровыми сигнальными процессорами, представляют собой несжатое видео, как правило, с частотой 30 кадров/с, то требования к пропускной способности линии связи между устройствами очень высоки.
Если взять видео в стандартном разрешении NTSC (720 на 480 пикселов) YUV 4:2:0, то размер каждого кадра составит 720×480×1,5 = 518400 байт. Соответственно, при частоте 30 кадров в секунду пропускная способность линии должна составлять примерно 124 Мбит/с.
Выбор интерфейса sRIO диктуют требования к скорости передачи видеоданных и поддержке гибкой структуры коммутации. sRIO поддерживает три скорости передачи данных: 1,24 Гбит/с, 2,5 Гбит/с и 3,125 Гбит/с. В данном интерфейсе применяется технология SerDes для восстановления тактовой синхронизации по потоку данных и используется кодирование 8-b/10-b. Эта спецификация последовательного интерфейса поддерживает порты с одной линией (1X) и с четырьмя линиями (4X). Физический уровень интерфейса sRIO определяет механизм квитирования, который применяют при установлении связи между устройствами, а также порядок обнаружения ошибок, основанный на циклическом избыточном коде. Физический уровень интерфейса устанавливает и приоритет пакетов, используемый при маршрутизации в пределах коммутирующей матрицы.
Чтобы в полной мере воспользоваться преимуществами пропускной способности sRIO, процессоры должны иметь эти интерфейсы. Такие процессоры предлагает компания Texas Instruments. Например, сигнальный процессор TMS320C6455 снабжен встроенным интерфейсом sRIO, который обеспечивает четыре одновременных соединения и имеет пиковую скорость передачи данных 20 Гбит/с в обе стороны.
Процессор TMS320C6455

Помимо интерфейса sRIO процессор C6455 имеет дополнительный набор важных функций, которые делают его идеальным устройством для транскодирования. Эти функциональные особенности можно объединить в четыре основных блока.
Наличие большого числа высокоскоростных интерфейсов ввода-вывода. Разработчики систем используют различные решения, поэтому цифровой сигнальный процессор для приложений обработки видеоданных должен предусматривать порты ввода-вывода для соединения модулей системы на уровне плат. Как было сказано ранее, в C6455 имеется встроенный порт sRIO для связи между устройствами.
Другие варианты ввода-вывода в C6455 – это контроллер обращения к среде Ethernet (Ethernet Media Access Controller, EMAC) со скоростью 1 Гбит/с, 32-битный контроллер памяти с удвоенной скоростью обмена данными (DDR2-500), а также 66-МГц шина для подключения периферийных устройств (PCI). Встроенный интерфейс ATM (UTOPIA 2) позволяет задействовать процессор C6455 в инфраструктуре телекоммуникаций.
Эффективное перемещение данных внутри микросхемы. Однокристальная архитектура для эффективного перемещения данных – одно из главных преимуществ процессора C6455 по сравнению с его предшественниками. В приложениях обработки видеоданных цифровые сигнальные процессоры работают в качестве ведомых устройств хост-процессора. Следовательно, для них важны высокая пропускная способность, малая задержка и возможность параллельной передачи данных между ведущими и ведомыми устройствами. Данные требования определили архитектуру устройства: периферийные устройства, внутренняя память и ядро процессора взаимодействуют между собой через эффективный коммутатор (switched central resource – SCR) процессора C6455.
Также важна оптимальная организация потока данных. Ее удалось улучшить за счет применения шин памяти с разрядностью 256 бит и внутреннего прямого доступа к памяти (internal direct memory access, IDMA). IDMA обеспечивает перемещение данных в фоновом режиме между двумя уровнями внутренней памяти, а также к шине периферийных устройств и обратно.
Большой объем внутрикристальной памяти. Внутрикристальная статическая оперативная память SRAM работает намного быстрее, чем динамическая внешняя память SDRAM, а ее объем намного меньше ввиду высокой стоимости изготовления. Для типовых приложений в области видео внутрикристальная память служит, главным образом, двум целям: 1) хранит часто используемые код и данные, 2) загружает/выгружает временные данные до и после обработки. Как правило, чем больше объем доступной внутрикристальной памяти, тем выше производительность приложения. В цифровом сигнальном процессоре C6455 размещено целых два мегабайта статической оперативной памяти.
Совместимость программного обеспечения (ПО). Обратная совместимость ПО важна, поскольку множество программ для видеоприложений было разработано задолго до широкого применения транскодирования. Чтобы использовать существующее ПО на новых процессорах, целесообразно повышать производительность DSP не путем изменения его набора команд, а за счет архитектуры ядра процессора. В процессоре C6455 реализованы два архитектурных новшества. Первое связано с введением циклического буфера, потенциально повышающего эффективность программной конвейеризации обработки кода с короткими циклами. Второе – применение 16-разрядных версий изначально 32-разрядных команд, что значительно уменьшает размер программного кода и, таким образом, снижает коэффициент "непопаданий" при обращениях к кэш-памяти.
Прототип системы транскодирования

Транскодирование необходимо также для передачи данных с DVD-дисков по IP-сети, например в обучающей системе компании, в приложениях видео по запросу и широковещательной трансляции видео. В этом случае исходным видеоформатом является MPEG2, а в качестве целевого формата используется в основном WMV9. Отметим, что возможность программирования цифровых сигнальных процессоров позволяет легко поддерживать практически любую комбинацию исходного/целевого видеоформата.
Для транскодирования видеоданных нужно решить множество технических вопросов, таких как преобразование формата, уменьшение битрейта видеопотока и его временного и пространственного разрешения. Поэтому были разработаны различные схемы интеллектуального транскодирования видеоданных. Их главный принцип – в максимально возможном повторном использовании информации, которая содержится во входном видеопотоке.
В данном разделе рассматривается прототип системы транскодирования видео, который пригоден для любых схем транскодирования благодаря использованию архитектуры, основанной на гибкой инфраструктуре аппаратного/программного обеспечения. Чтобы удовлетворить различным целевым сценариям транскодирования видео, выбрана простейшая схема транскодирования, в которой видеопоток полностью декодируется, а затем кодируется повторно в соответствии с новыми ограничениями.
Поток данных в системе начинается на левой стороне схемы (рис.2), со сжатого в формате MPEG2 видеофайла, который хранится на жестком диске, и заканчивается на плоскопанельном дисплее, где видео воспроизводится программой Windows Media Player. В этом демонстрационном варианте видео имеет стандартное разрешение NTSC (720 на 480 пикселов) и транскодируется со скоростью 30 кадров в секунду.
Модуль приемника потока, работающий на DSP1, буферизует поток MPEG2 и организует входные данные для модуля декодера MPEG2. Управление операцией приема данных производится с использованием библиотеки средств разработки сетей (Network Development Kit, NDK) компании TI, которая по существу представляет собой стек TCP/IP. Модуль формирователя пакетов ASF, работающий на процессоре DSP2, формирует пакеты в формате ASF из данных, сжатых в модуле WMV9. В DSP2 также присутствует http-сервер на базе NDK, который обрабатывает запросы на передачу потока от программы Windows Media Player и передает в нее пакеты ASF. Windows Media Player декодирует пакеты ASF и показывает видео на экране.
Одним из наиболее интересных и сложных аспектов передачи потока данных является взаимодействие двух цифровых сигнальных процессоров через интерфейс sRIO. При передаче каждого видеокадра происходит следующее. После того, как DSP1 завершит передачу видеокадра, он посылает пакет данных, который в спецификации протокола sRIO называется DOORBELL. Пакет DOORBELL генерирует системное прерывание в процессоре DSP2, уведомляющее о наличии кадра. В ответ DSP2 запускает процесс кодирования в формат WMV9. Завершив кодирование кадра, DSP2 посылает пакет DOORBELL процессору DSP1. При этом в DSP1 генерируется прерывание, чтобы сообщить о готовности процессора DSP1 продолжить передачу следующего кадра. На практике используется схема буферов с попеременным переключением, чтобы операции кодирования/декодирования и передачи данных выполнялись параллельно.
Блок графического пользовательского интерфейса (GUI) обеспечивает встроенные в систему функции управления и мониторинга. Активность канала связи sRIO и каналов связи Gigabit MAC (GMAC) отображается в реальном времени. При передаче по каналу связи потока данных MPEG-2 средняя скорость передачи составляет 8 Мбит/с, что характерно для кодирования при стандартном разрешении с частотой 30 кадров в секунду. При передаче по каналу связи пакетов ASF средняя скорость передачи составляет 4 Мбит/с. Это показывает, что формат WMV9 способен освободить приблизительно 50% полосы пропускания, обеспечивая сходное качество видео. Для канала связи с интерфейсом sRIO средняя скорость передачи данных составляет 124 Мбит/с.

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

Транскодинг (или транскодирование) - это преобразование файла из одного метода кодирования (т.е. формата файла) в другой. Транскодирование может быть представлено как:

1. Кодирование без потерь.
2. Из формата без потерь в формат с потерями.
3. Из формата с потерями в формат с потерями.

Кодирование из формата с потерями в формат с потерями

Каждый раз, когда происходит кодирование с потерями, снижается качество. Его не удастся вернуть, даже если кодировать 128 kbps MP3 в 320 kbps MP3 (или при любом другом высококачественном сжатии). Транскодирование между форматами с потерями не рекомендуемо. Качество звука у результирующего файла всегда будет ниже, чем у исходного файла. Но тем не менее, причины, по которым может быть использован данный вид кодирования - это:

• Снижение скорости передачи данных для переносимых плееров, когда слушателя не сильно заботит качество звука
• Экономия памяти

Данные CD-audio - около 1411 kbps (605 MB в час); кодерам без потерь удается добиться 700 kbps (300 MB/ч). Кодеры с потерями, такие как Vorbis , MPC , и AAC дают снижение качества, незаметного для большинства людей (транспарентности) на 150-170 kbps (69 MB/ч). Для MP3 (с кодером LAME) транспарентность наступает на 192 kbps (82 MB/ч). Для большой музыкальной коллекции сильно заметна разница в занимаемом пространстве, по сравнению с сжатием без потерь. Согласно проводившемуся тесту, где 256 kbps сжимали в 128 kbps MP3 , а затем сравнивали на качество звучания, лучшими оказались Ogg Vorbis и MPC , им уступили WV4 и AAC . Кодирование из 256 kbps MP3 в 128 МP3 вызвало значительное ухудшение в сравнении с изначальным 128 kbps МP3 . Было также рассмотрено транскодирование из 192 kbps. Субъективные мнения (без теста ABX): Ogg 96 или 128 kbps отличаются на слух, но все ещё приемлемы, тогда как MP3 и WMA на 128 kbps сильно ухудшаются. AAC 96 kbps был лучше, чем MP3 и WMA .

Кодирование из формата без потерь в формат без потерь

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

Кодирование из формата без потерь в формат с потерями

Хранение аудио в формате без потерь дает возможность кодировать музыку в форматы с потерями по мере того, как улучшаются кодеры. Например, если текущий формат с потерями Х транспарентен на 192 kbps, тогда как через три года формат Y будет транспарентым на 128 kbps, вряд ли кодирование из X в Y даст приемлемые результаты по сравнению с кодированием из формата без потерь. Это происходит потому, что формат Х, будучи форматом с потерями, удаляет данные, которые считает ненужными, но которые все же нужны формату Y. В результате, кодирование Y будет сильно искажено. Если кодировать в формат с потерями из источника без потерь, настоятельно рекомендуется сохранять файлы-источники. Поэтому, если результат с потерями неудовлетворительный, можно с легкостью перекодировать. При этом нужно помнить, что у некоторых транскодеров имеются опции автоматически удалять исходный файл. Убедитесь, что эта опция выключена.

Разные производители IP-камер наделяют их разными поддерживаемыми процессами сжатия видеосигнала. Обычно, эти процессы лишь отчасти совпадают с требованиями проектов CCTV. В тех случаях, когда пользователи переходят к видеоданным, они начинают сталкиваться с недостатками в сфере функциональности, гибкости и комфорта. Исключение составляют лишь те процессы сжатия, которые были специально модифицированы под систему CCTV.

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

В качестве аргументов для использования технологии транскодирования можно назвать:

• в момент объединения камер разных производителей функциональная гомогенизация системы CCTV. Несмотря на различия производителей камер будут доступны все функции транскодера;
• существование возможности интеграции обработки изображения в транскодер;
• использование функций , к примеру, потоковой динамической передачи данных в реальном масштабе времени (DLS), с автоматическим согласованием разрешения потока с размером окна монитора оператора. Благодаря этому удается существенно сократить ширину полос пропускания, которые используются в реальном масштабе времени для многоканальной трансляции данных.

Резюме

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

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