Здравствуйте.
Возникла следующая задача: необходимо иметь возможность в произвольный момент времени включать и выключать передачу аудио или видео потока, и, соответственно, иметь возможность на стороне плеера воспроизвонить аудио или видео, которое появилось.
Насколько я понимаю, подобная задача сейчас решается путём использования 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 не покрывает описанный выше кейс с физическим отключением камеры.
Спасибо.
Возникла следующая задача: необходимо иметь возможность в произвольный момент времени включать и выключать передачу аудио или видео потока, и, соответственно, иметь возможность на стороне плеера воспроизвонить аудио или видео, которое появилось.
Насколько я понимаю, подобная задача сейчас решается путём использования 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 не покрывает описанный выше кейс с физическим отключением камеры.
Спасибо.
