Виктор Сухов
Member
Здравствуйте!
Есть потребность в реализации стриминга с функцией переключения туда-сюда с демонстрации экрана на показ потока вебкамеры и обратно(вебинарная комната). Нет необходимости одновременно транслировать и экран и камеру(т.е. только по очереди).
Как вы рекомендовали бы решить эту задачу используя web sdk?
Наши текущие варианты и проблемы
С Микшером:
Реализация:
1. Запускается стриминг(камера или экран) по publishing переходим к п.2.
2. Создаётся микшер
3. Добавляется стрим из п.1 к микшеру
4. При необходимости переключить источник(экран-вебкамера) останавливается стрим из п.1. и по unpublish запускается новый стрим с новым источником
5. Добавляется этот новый стрим из п.4 по событию publishing к микшеру.
У нас этот вариант столкнулся со следующими препятствиями
1. Значительное потребление ресурсов процессора при реализации с помощью микшера(фактически один стрим одно ядро на 100% забирает).
2. Большое время когда первый стрим уже выключен, а второй ещё не транслируется. Т.е. клиент видит несколько секунд черный экран и звука соответственно тоже нет
Реализация без микшера:
1. Запускается стриминг(камера или экран).
2. При необходимости переключить источник(экран-вебкамера) останавливается стрим из п.1. по unpublish запускается новый стрим с новым источником
У нас этот вариант столкнулся со следующими препятствиями:
1. Обрыв трансляции у клиента и необходимость либо совершать действие вручную смотрящим(на safari IO нельзя использовать autoplay(описывал эту проблему раньше)) либо каким-то образом модифицировать плеер(описано ниже)
2. Так же как и в случае с микшером большие задержки между концом прошлого потока и воспроизведением нового
Действия на клиенте(плеер)
Модифицировали embed_player(используем с autoplay=true), добавив возможность автоматического переподключения: запуск
функции start() при событиях
STREAM_STATUS.STOPPED и STREAM_STATUS.FAILED(приводит кстати к тому, что на сервере появляются много соединений типа pending от одного и того же клиента)
Сначала пробовал как можно быстрее коннектится при этих событиях обратно, однако браузер набирал очень быстро порядка нескольких сот попыток и блокировал дальнейшие попытки коннектится с ошибкой типа слишком много соединений...
Пришлось ограничить кол-во попыток и распределить их по времени, т.е. делать запуск start() раз в несколько секунд с всё возрастающим интервалом при очередном FAILED.
--------------------------
Нам бы хотелось реализовать возможность бесшовного переключения видеоисточников(экран-вебкамера) хотябы в плане звука, т.е. чтобы звук не пропадал
Либо максимально уменьшить этот промежуток для смотрящего
По возможности без использования мишкера(требует много ресурсов)
Подскажите варианты
----------------------
Спасибо!
Есть потребность в реализации стриминга с функцией переключения туда-сюда с демонстрации экрана на показ потока вебкамеры и обратно(вебинарная комната). Нет необходимости одновременно транслировать и экран и камеру(т.е. только по очереди).
Как вы рекомендовали бы решить эту задачу используя web sdk?
Наши текущие варианты и проблемы
С Микшером:
Реализация:
1. Запускается стриминг(камера или экран) по publishing переходим к п.2.
2. Создаётся микшер
3. Добавляется стрим из п.1 к микшеру
4. При необходимости переключить источник(экран-вебкамера) останавливается стрим из п.1. и по unpublish запускается новый стрим с новым источником
5. Добавляется этот новый стрим из п.4 по событию publishing к микшеру.
У нас этот вариант столкнулся со следующими препятствиями
1. Значительное потребление ресурсов процессора при реализации с помощью микшера(фактически один стрим одно ядро на 100% забирает).
2. Большое время когда первый стрим уже выключен, а второй ещё не транслируется. Т.е. клиент видит несколько секунд черный экран и звука соответственно тоже нет
Реализация без микшера:
1. Запускается стриминг(камера или экран).
2. При необходимости переключить источник(экран-вебкамера) останавливается стрим из п.1. по unpublish запускается новый стрим с новым источником
У нас этот вариант столкнулся со следующими препятствиями:
1. Обрыв трансляции у клиента и необходимость либо совершать действие вручную смотрящим(на safari IO нельзя использовать autoplay(описывал эту проблему раньше)) либо каким-то образом модифицировать плеер(описано ниже)
2. Так же как и в случае с микшером большие задержки между концом прошлого потока и воспроизведением нового
Действия на клиенте(плеер)
Модифицировали embed_player(используем с autoplay=true), добавив возможность автоматического переподключения: запуск
функции start() при событиях
STREAM_STATUS.STOPPED и STREAM_STATUS.FAILED(приводит кстати к тому, что на сервере появляются много соединений типа pending от одного и того же клиента)
Сначала пробовал как можно быстрее коннектится при этих событиях обратно, однако браузер набирал очень быстро порядка нескольких сот попыток и блокировал дальнейшие попытки коннектится с ошибкой типа слишком много соединений...
Пришлось ограничить кол-во попыток и распределить их по времени, т.е. делать запуск start() раз в несколько секунд с всё возрастающим интервалом при очередном FAILED.
--------------------------
Нам бы хотелось реализовать возможность бесшовного переключения видеоисточников(экран-вебкамера) хотябы в плане звука, т.е. чтобы звук не пропадал
Либо максимально уменьшить этот промежуток для смотрящего
По возможности без использования мишкера(требует много ресурсов)
Подскажите варианты
----------------------
Спасибо!