Обработка аудиопотоков от одноранговых соединений WebRTC на сервере
Я работаю над экспериментальным одноранговым проектом WebRTC, в котором
- клиенты (Chrome) отправляют свой локальный аудиопоток на удаленный сервер
- удаленный сервер записывает этот аудиопоток в файл для последующей обработки
- сервер делает этот конкретный файл доступным для клиента, который отправил его на прослушивание в своем браузере
- сервер делает 2 и 3, когда приходят аудиопотоки
Я знаю, как это сделать 1. Для 2 я в настоящее время использую нативный API WebRTC (т.е. StartRecordingPlayout) внутри «Ствол \ Обсуждение \ Примеры \ PeerConnection \ клиента«Проект, написанный на C ++. Мне удалось записать аудиопоток, отправленный с удаленного узла (Chrome), в файл WAV на принимающей стороне и прослушать его с помощью медиаплеера VLC.
Сейчас я изучаю, какие другие технологии / языки доступны для моего проекта. Это потому, что я чувствую, что на данный момент не так много ресурсов для разработки собственных приложений WebRTC. Я тогда недавно обнаружил Node.js.
Будет ли сочетание WebRTC и Node.js хорошим выбором для создания такого серверного приложения, описанного выше?
Любой совет будет принят во внимание.
Решение
Единственный реальный способ в настоящее время состоит в том, чтобы записать или манипулировать аудио потоком изначально. Audio Web API (в частности, AudioContext), который доступен в JavaScript не может разобрать буферы удаленной стороны которые прибывают из rtcpeerconnection. Это ток ошибка с низким приоритетом в Chrome. Я не уверен, что все другие реализации API имеют те же проблемы.
Вы можете попытаться получить аудио API, который реализован Node.js или RecordRTC для узла но держу пари, что у обоих будут одинаковые проблемы. Я был бы рад удивлен, если они этого не делают, и если они этого не делают, оба могут быть действительными вариантами для вашего приложения.
Единственным вариантом, отличным от нативного решения, было бы, чтобы клиент отправлял аудиобуферы отдельно от однорангового соединения, но это в значительной степени противоречило бы цели использования однорангового соединения WebRTC.
Другие решения
detector