Подключение аудио\видео устройства на лету после начала публикаци

Axel

Member
Здравствуйте.

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

Насколько я понимаю, подобная задача сейчас решается путём использования API вида "Stream.switchCam()" и "Stream.switchMic()" при публикации потока и "Stream.setAudioOutputId()" (к слову, он не задокументирован) при его воспроизведении. Тем не менее, исходный код этих методов предполагает, что ранее уже был создан поток соответствующего типа (аудио, видео), и при переключении на новое устройство, код ищет соответствующий инстанс RTCRtpSender`а, и заменяет в нём поток через вызов "sender.replaceTrack()". Такой ход не приводит к изменению ни количества потоков, ни SDP.

В таком случае, для решения задачи, можно было бы стартовать поток с включёнными аудио и видео потоками, а видео поток сразу же замьютить. А при необходимости в дальнейшем его включить, можно было бы выполнить "Stream.unmuteVideo()".

Однако, этот поход имеет следующие недостатки (на примере работы с камерой, но справедливо и для других устройств), перва два - самые важные:

- нет возможности запустить поток без видео вообще (убрать "constraints.video" из вызова "Session.createStream()") и позже, физически подключив новое устройство или выбрав ранее подключённое, активировать передачу видеопотока без разрыва текущего соединения и установления нового
- если начать публикацию с аудио и видео, замьютить видео, физически выключить камеру из USB, включить её обратно, подождать пока она обнаружится ПК, попытаться размьютить видео, то ничего не произойдёт. Попытка обновить список устройств после подключения камеры и свича на эту же камеру ("Stream.switchCam()") приведёт к ошибке "Uncaught (in promise) Number of cams is less than 2 or already used custom stream". Если после этого попытаться такой поток играть плеером, то тоже наблюдается странное поведение, но это тема отдельного разговора
- он потребует доступа к камере даже в случае, если она не нужна на момент начала публикации потока
- нет возможности запустить Stream сразу с замьюченным видео, так как необходимо дождаться установки соединения MediaConnection, что может создать сложности с UX
- фактически, будет выполняться передача "чёрного экрана" на сервер, хоть и мизер, но всё-таки трафик

Как я понимаю, сама возможность добавить новый поток (аудио или видео) в WebRTC предусмотрена и не представляет сложностей, а вот Raw WebSocket API, в частности, его методы "publishStream" и "setRemoteSDP", на подобное не рассчитаны, как и, вероятно, WCS.

Собственно, вопросы следующие:

1. Верны ли мои выкладки выше, и если да, то единственным рабочим вариантом является использование mute-функций сразу после старта потока?
2. Если ответ на п.1 положительный, то, планируете ли вы добавлять подобную функциональность? Ведь решение с mute не покрывает описанный выше кейс с физическим отключением камеры.

Спасибо.
 

Max

Administrator
Staff member
Добрый день.
1. Верны ли мои выкладки выше, и если да, то единственным рабочим вариантом является использование mute-функций сразу после старта потока?
2. Если ответ на п.1 положительный, то, планируете ли вы добавлять подобную функциональность? Ведь решение с mute не покрывает описанный выше кейс с физическим отключением камеры.
В настоящее время изменение состава треков в WebRTC-сессии не поддерживается на стороне сервера. Мы работаем над этим в тикете WCS-2393, для реализации SFU с прицелом на конференции, но это потребует в том числе серьезной переработки Websocket API.
Поэтому пока единственным рабочим вариантом является muteVideo/muteAudio.
 

Axel

Member
Можете назвать сроки реализации WCS-2393 и сопутствующих изменений в других нужных API?
 

Max

Administrator
Staff member
Мы не озвучиваем ETA на форуме для новых фич. Данный тикет пока находится в разработке на уровне пре-альфа.
 
Top