#javascript #webrtc #mime-types #media-source #rtcdatachannel
#javascript #webrtc #mime-типы #медиа-источник #rtcdatachannel
Вопрос:
Перенеся это из softwareengineering. Мне сказали, что этот вопрос может быть лучше для stackoverflow.
Я отправляю видеопоток данных другому одноранговому узлу и хочу повторно собрать эти данные и сделать этот поток источником видеоэлемента. Я записываю данные с помощью пакета npm RecordRTC и получаю большой объем данных каждые 1 секунду.
Я отправляю его по каналу передачи данных WebRTC и первоначально пытался повторно собрать данные с помощью API MediaSource, но оказалось, что MediaSource не поддерживает данные с mimetype of video/webm;codecs=vp8,pcm . Есть ли какие-нибудь мысли о том, как собрать этот поток заново? Можно ли изменить API MediaSource?
Мое единственное требование к этому потоку данных — чтобы звук был закодирован с помощью pcm, но если у вас есть какие-либо мысли или вопросы, пожалуйста, дайте мне знать!
P.S. Я думал, что вопросы, основанные на мнениях, не предназначены для stackoverflow, поэтому я сначала разместил их там.
Комментарии:
1. Почему бы вам просто не передать необработанный медиапоток через ваш сервер WebRTC?
2. @Kaiido потому что webrtc не поддерживает этот тип mimetype. Мне специально нужен wav в качестве аудиокодека, но pcm работает, так как единственное отличие — это магическое число. Идея состоит в том, чтобы обойти это с помощью RTC Datachannel и повторно собрать данные на другом конце, чтобы иметь возможность использовать пользовательский mimetype
3. Тогда зачем, по вашему мнению, вам нужен PCM? Если это должно быть прочитано другим одноранговым узлом, лучшее, что вы можете сделать, — предоставить необработанный медиапоток. Если вы надеялись на лучшее качество, потому что «PCM без потерь», то знайте, что данные, которые RecordRTC производит в любом случае, поступают из этого потока (который, вероятно, закодирован в ogg), так что это генерирует только увеличенную версию тех же данных.
4. Мне нужен аудиокодек без потерь для конкретных потребностей моих приложений. Аудиокодеком WebRTC по умолчанию является Opus, но поскольку он с потерями, его нельзя использовать для нужд моих приложений. Сжатие SDP является жизнеспособным вариантом, но опять же WebRTC не поддерживает pcm, насколько я понимаю.
5. Мне было интересно, возвращается ли необработанный медиапоток из чего-то вроде getusermedia в каком формате это? Мне особенно нужен звук без потерь, потому что я передаю эти данные в DAW, такие как logic pro, fla studio, garageband и т. Д. Для микширования и записи в реальном времени. RecordRTC предоставляет мне параметры, необходимые для таких вещей, как частота дискретизации, звуковые биты в секунду и т.д..
Ответ №1:
Самый простой способ справиться с этим — проксировать поток через сервер, где вы можете вернуть поток в виде HTTP-ответа. Затем вы можете сделать что-то столь же простое, как:
<video src="https://example.com/your-stream"></video>
Недостатком, конечно, является то, что теперь вам приходится покрывать стоимость полосы пропускания, поскольку соединение больше не является одноранговым.
Было бы неплохо, если бы вы могли использовать Service Worker и заставить его возвращать поддельный HTTP-ответ из данных, которые вы получаете от однорангового узла. К сожалению, разработчики браузера нарушили стандарты Service Worker, отключив его, если пользователь перезагружает страницу или использует режимы конфиденциальности. (Похоже, они предполагали, что сервисные работники были полезны только для кэширования.)
Кроме того, заметка о WebRTC … То, что вы делаете, прекрасно. Вы не хотите использовать обычные медиапотоки WebRTC, так как они не только сжимаются с потерями, но и отбрасывают сегменты, отдавая приоритет сохранению реального времени над качеством. Это не похоже на то, что вы хотите.
Мне было интересно, возвращается ли необработанный медиапоток из чего-то вроде getusermedia в каком формате это?
Медиапоток — это необработанные данные, но они недоступны напрямую. Если вы присоедините медиапоток к графику Web Audio API, независимо от формата, в котором записана звуковая карта, она преобразуется в 32-разрядный PCM с плавающей запятой. На этом этапе вы можете использовать узел обработки сценариев для сбора необработанных данных PCM.
Комментарии:
1. Есть ли способ добавить новый ArrayBuffer, если я пошел по маршруту http-прокси? Что касается второй части, касающейся работников сферы обслуживания, то все должно быть в порядке, поскольку независимо от того, обновил ли пользователь страницу, видеочат исчезнет. Что касается getusermedia и прикрепления его к WebAudio graph, есть ли способ сделать это для всего собираемого видеопотока и изменить только настройки звука, потому что, если бы это был просто звук, разве мне не пришлось бы разделять аудио- и видеодорожки, а затем соединять их вместе? Задержка — мой самый большой страх в проекте прямо сейчас, и я стараюсь свести ее к минимуму, насколько это возможно
2. @Malcolm Ваша серверная часть будет просто постоянно получать данные от отправляющего клиента (предположительно через веб-сокет) и будет продолжать отправлять данные через HTTP на принимающую сторону.
3. @Malcolm Работники службы по-прежнему являются проблемой … например, функция отключается, если пользователь обновляет страницу, потому что предполагается, что работники службы предназначены только для кэширования, а обновление заключается в перезагрузке без кэша.
4. @Malcolm Да, нет хорошего способа разделить и воссоединить аудио / видео. Вы можете и можете снова создать из него новый медиапоток, но синхронизация может быть проблемой, потому что встроенные временные метки теперь исчезли.
5. @Malcolm RE: Задержка, вы должны выбрать то, что хотите… качество или низкая задержка. На самом деле у вас не может быть обоих. 🙂 Вам либо придется отбрасывать выборки, чтобы сохранить их в реальном времени, либо сохранить их все, сохранить приличный объем буфера и сохранить этот буфер заполненным во время потока. Вам нужно будет выбрать наилучший баланс. Если задержка является проблемой, вам нужен прямой WebRTC, и вы захотите выбрать высокий битрейт для потока Opus с помощью вашего munging.