Материал статьи взят с моего дзен-канала.

Все статьи цикла

Статья 1
Статья 2
Статья 3
Статья 4
Статья 5
Статья 6
Статья 7
Статья 8
Статья 9
Статья 10
Статья 11
Статья 12
Статья 13

Книгу на основе статей можно свободно скачать по ссылке: pdf-файл.

Введение

Эта статья является началом цикла статей о реалтайм обработке медиаданных с помощью движка Mediastreamer2.

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

Mediastreamer2 это VoIP-движок, лежащий в основе популярного open-source проекта программного voip-телефона Linphone. В Linphone Mediastreamer2 реализует все функции связанные со звуком и видео. Подробный список возможностей движка можно увидеть на этой странице Mediastreamer. Исходный код находится здесь: GitLab.

Материал статьи взят с моего дзен-канала.

Создаем тональный генератор

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

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

Материал статьи взят с моего дзен-канала.

Улучшаем пример тонального генератора

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

Материал статьи взят с моего дзен-канала.

Создаем измеритель уровня сигнала

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

В этой статье мы соберем схему измерителя уровня сигнала и научимся читать результат измерения из фильтра. Оценим точность измерения.

Материал статьи взят с моего дзен-канала.

Обнаружитель тонального сигнала

В прошлой статье мы создали измеритель уровня сигнала. В этой мы научимся обнаруживать тональный сигнал.

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

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

Материал статьи взят с моего дзен-канала.

Передача звукового сигнала через RTP-поток

В прошлой статье мы собрали схему дистанционного управления из генератора и детектора тональных сигналов, которые работают внутри одной программы. В этой статье мы научимся использовать протокол RTP (RFC 3550 — RTP: A Transport Protocol for Real-Time Applications) для приема/передачи звукового сигнала по Ethernet-сети.

Материал статьи взят с моего дзен-канала.

Используем TShark для анализа RTP-пакетов

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

В этой статье мы продолжаем изучать передачу звукового сигнала с помощью RTP-протокола. Сначала разделим наше тестовое приложение на передатчик и приемник и научимся исследовать RTP-поток с помощью анализатора сетевого трафика.

Материал статьи взят с моего дзен-канала.

Структура RTP-пакета

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

Взглянем на тот же пакет, но уже с подкрашенными полями и с поясняющими надписями:

Материал статьи взят с моего дзен-канала.

Дуплексное переговорное устройство

В прошлой статье было анонсировано дуплексное переговорное устройство, а в этой мы его сделаем.

Материал статьи взят с моего дзен-канала.

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

Разрабатываем плагин

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

Чтобы использовать плагин в своей программе, вы с помощью include должны подключить заголовочный файл плагина. В теле программы, с помощью функции у ms_filter_register() выполнить регистрацию нового фильтра. Естественно, ваша программа и и исходник плагина должны быть скомпилированы и собраны в одно приложение.

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

Материал статьи взят с моего дзен-канала.

Механизм перемещения данных

• Блок данных dblk_t
• Сообщение mblk_t
• Функции работы с сообщениями mblk_t
• Очередь queue_t
• Функции работы с очередями queue_t
• Соединение фильтров
• Сигнальная точка графа обработки данных
• Закулисная деятельность тикера
• Буферизатор MSBufferizer
• Функции работы с MSBufferizer

В прошлой статье мы разработали свой собственный фильтр. Эту статью мы посветим устройству внутреннего механизма перемещения данных между фильтрами медиастримера. Это позволит в дальнейшем писать изощренные фильтры с меньшими усилиями.

Материал статьи взят с моего дзен-канала.

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

Отладка крафтовых фильтров

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

Материал статьи взят с моего дзен-канала.

Все статьи цикла

Статья 1
Статья 2
Статья 3
Статья 4
Статья 5
Статья 6
Статья 7
Статья 8
Статья 9
Статья 10
Статья 11
Статья 12
Статья 13

Книгу на основе статей можно свободно скачать по ссылке: pdf-файл.

В прошлой статье, мы рассмотрели вопросы отладки крафтовых фильтров, связанные с перемещением данных.

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