Как скрыть отображение заглушенных видеостримов (videoMuted) в миксере?

McSeemZ · Feb 9, 2021

Добрый день, коллеги!
@Max отличный продукт собрали. Но есть вопросы:

1. Для проведения конференций нам надо акцентировать одного из нескольких ведущих, на время скрывая остальных (но оставляя голос). Вопрос в том, как скрыть. Пробовали заглушать видеопоток через /mixer/setAudioVideo, но черный прямоугольник остается на экране. Я так понимаю, настройка mixer_show_separate_audio_frame=false работает только потоков, сразу инициализированных без видео.
Управление Layout тут тоже не помогает, потому что имя стрима не говорит о наличии видео. Есть ли какие-то готовые подходы к такой ситуации?

2. При Share screen экран десктопа тоже подписан именем стрима. Как можно его выключать в режиме mixer_video_desktop_fullscreen=true ? А то ненужная информация на экране болтается.

3. Какие вы можете порекомендовать гайды по управлению битрейтом и размерами картинки? А то при Share screen картинка экрана получается страшненькая, не заточенная под статическое изображение

Спасибо!

Max · Feb 10, 2021

Добрый день.

McSeemZ said:
1. Для проведения конференций нам надо акцентировать одного из нескольких ведущих, на время скрывая остальных (но оставляя голос). Вопрос в том, как скрыть. Пробовали заглушать видеопоток через /mixer/setAudioVideo, но черный прямоугольник остается на экране. Я так понимаю, настройка mixer_show_separate_audio_frame=false работает только потоков, сразу инициализированных без видео.
Управление Layout тут тоже не помогает, потому что имя стрима не говорит о наличии видео. Есть ли какие-то готовые подходы к такой ситуации?

Наоборот, настройка mixer_show_separate_audio_frame=false работает для потоков, которые изначально опубликованы с видео и аудио, а в микшер добавлены только с аудио. И это как раз подходит для данного случая:
1. Устанавливаем настройку

Code:

mixer_show_separate_audio_frame=false

2. Публикуем поток с видео и аудио, добавляем его в микшер.
3. Когда необходимо акцентировать ведущего, убираем поток участника из микшера и добавляем его как поток только с аудио следующим REST API запросом

Code:

POST /rest-api/mixer/add HTTP/1.1
HOST: wcs:8081
content-type: application/json

{
    "uri": "mixer://mixer1",
    "remoteStreamName": "participant_stream",
    "hasVideo":false,
    "hasAudio":true
}

В этом случае поток от участника не будет отображаться в картинке микшера, но голос останется

McSeemZ said:
2. При Share screen экран десктопа тоже подписан именем стрима. Как можно его выключать в режиме mixer_video_desktop_fullscreen=true ? А то ненужная информация на экране болтается.

Можно задать для надписей прозрачный фон

Code:

mixer_text_background_opacity=0

и публиковать поток экрана с меткой имени

Code:

session.createStream({
    streamName: "desktop#mixer1?label=+",
    display: localDisplay,
    ...
}).publish();

Поскольку символ + заменяется на пробел, на потоке экрана надпись отображаться не будет

McSeemZ said:
3. Какие вы можете порекомендовать гайды по управлению битрейтом и размерами картинки? А то при Share screen картинка экрана получается страшненькая, не заточенная под статическое изображение

Посмотрите, пожалуйста, здесь. У публикации экрана, действительно, битрейт может падать при статической картинке, поэтому рекомендуется задать нижнюю границу в зависимости от разрешения экрана. Например, для FullHD нижнюю границу можно задать на уровне 1000000 бит/с

Code:

session.createStream({
    streamName: "desktop#mixer1?label=+",
    display: localDisplay,
    constraints: {
           video: {
                  ...
                  minBitrate: 1000
           }
    }
    ...
}).publish();

Однако, следует учесть, что при публикации потока экрана без использования расширения, ограничения на стороне клиента могут не примениться. Необходимо обновить Web SDK до сборки 0.5.28.2753.152 и новее. В Safari в этом случае ограничения все равно не применяются.
С другой стороны, если установить нижнюю границу битрейта на стороне сервера

Code:

webrtc_cc_min_bitrate=1000000

это будет действовать на все потоки от всех клиентов. Возможно ухудшение качества изображения и фризы потока клиента, если пропускная способность канала клиента ниже заданного битрейта.
В связи с этим, рекомендуется установить на стороне сервера минимальную границу битрейта публикации на уровне не более 300-500 кбит/с

Code:

webrtc_cc_min_bitrate=500000

McSeemZ · Feb 10, 2021

Max said:
3. Когда необходимо акцентировать ведущего, убираем поток участника из микшера и добавляем его как поток только с аудио следующим REST API запросом

Так если убирать поток из миксера через /mixer/remove, то он закрывается, и обратно его не цепнуть:

JSON:

{
    "exception": "com.flashphoner.rest.server.exception.NotFoundException",
    "path": "/rest-api/mixer/add",
    "error": "Not Found",
    "message": "Stream not found",
    "timestamp": 1612966019536,
    "status": 404
}

а если добавлять не удаляя, то тоже не получается:

JSON:

{
    "exception": "com.flashphoner.rest.server.exception.ConflictException",
    "path": "/rest-api/mixer/add",
    "error": "Conflict",
    "message": "user2#d25fe06e57424087a75cea54087b already added to mixer",
    "timestamp": 1612966748748,
    "status": 409
}

Max · Feb 11, 2021

McSeemZ said:
Так если убирать поток из миксера через /mixer/remove, то он закрывается, и обратно его не цепнуть:

Если поток выводится из микшера, то количество подписчиков этого потока уменьшается на единицу. Если подписчиков не осталось, и если поток опубликован из браузера или по RTMP, он продолжает существовать до окончания публикации. Если поток был захвачен с RTSP или RTMP источника, либо играется как VOD из файла, то без подписчиков он завершается по таймауту (60 секунд по умолчанию).
Проверить, опубликован ли поток на сервере, можно запросом /stream/find

Code:

POST /rest-api/stream/find HTTP/1.1
Host: wcs:8081
Content-Type: application/json
 
{
    "published":true
}

Если поток есть в этом списке, то проблема, скорее всего, не в потоке и не в микшере, а в имени потока в запросе /mixer/add
Поэтому уточните, пожалуйста, как именно публикуется поток, и последовательность действий: как добавляется в микшер, каким запросом выводится, каким запросом добавляется обратно.
Если имя потока в запросе указано правильно, поток опубликован, но в микшер не добавляется с диагнозом 404 Stream not found, воспроизведите проблему, соберите отчет по инструкции и отправьте, используя эту форму.

McSeemZ · Feb 11, 2021

Max said:
Если подписчиков не осталось, и если поток опубликован из браузера или по RTMP, он продолжает существовать до окончания публикации.

Да, поток из браузера, и его публикация у меня завершается сервером при вызове /mixer/remove, поэтому последующий /stream/find его уже не видит.
Я собрал данные и отправил используя указанную форму. Там начало движухи на 13:05:05,803

По остальным двум пунктам всё отработало олично, спасибо огромное!

Max · Feb 12, 2021

Проверили Ваши логи.
Прежде всего, конфигурация сервера 1 CPU core, 1 Gb RAM слабее минимальных рекомендованных параметров, тем более этого недостаточно для тестирования микшера с Вашими настройками (720p 30 fps выходной поток с битрейтом 5 Мбит/с). При микшировании включается транскодинг, что требует минимум 2 ядра CPU на один микшер. Также необходимо добавить памяти на сервер, т.к. 512 Mb под Java heap меньше минимального объема по умолчанию, а при микшировании активно используется как Java heap, так и системная память. Рекомендуемая минимальная конфигурация 4 CPU core и 8 Gb RAM (4 Gb под Java heap).
На указанной конфигурации проблема не воспроизводится, публикация потока, выведенного из микшера, не останавливается. Обращаем внимание, что, если в микшере был всего один поток, микшер с настройкой mixer_idle_timeout=10000 может остановиться быстрее, чем в него добавят новый поток после вывода, если тест проводится вручную, поскольку пустой микшер останавливается через 10 секунд.
Пожалуйста, обновите конфигурацию сервера до указанной, добавьте Java heap

Code:

-Xmx4g
-Xms4g

и повторите тесты.

McSeemZ · Feb 12, 2021

@Max , добрый день

Спасибо за рекомендации. Воспроизвели проблему на рекомендуемой конфигурации машины (4 CPU/8Gb) и java. Абсолюно такое же поведение. Я залил репорт через форму.

Проверяем через Postman, запуская в автоматическом режиме /mixer/remove | /stream/find | /mixer/add. Вот /stream/find находит уже только поток миксера.
Может, с конфигурацией сервера что не так...
Я вижу в логах ошибки 401 при каких-то внутренних вызовах. У нас введена авторизация на REST API, возможно, это влияет как-то?

Max · Feb 15, 2021

У вас используется серверное приложение для обработки REST hook /ConnectionStatusEvent, /StreamKeepAliveEvent, /publishStream, /OnDataEvent, /connect. При этом для операций с микшером используется стандартное приложение defaultApp, у которого, по всей видимости, пользователь по умолчанию изменен, поэтому стандартное приложение возвращает 401 Unauthorized на любой REST hook.
Рекомендуем сделать чистую установку сервера, добавить собственное приложение для REST hook, но не изменять пользователя для defaultApp, и повторить тесты.
Также уточните, используете ли Вы Web SDK для публикации, и, если да, воспроизводится ли проблема при публикации потока из стандартного примера.
Если проблема продолжает воспроизводиться, предоставьте, пожалуйста, доступы к серверу при помощи этой формы

McSeemZ · Feb 15, 2021

@Max Я не менял дефолтового пользователя. Возможно, это специфика AWS-варианта дистрибутива. Я даже не знаю какой у него дефолтовый пароль.
Изменялся пароль для demo и для admin (AWS автоматически выставляет). Какой-то из них используется defaultApp?

Были выполнены только следующие команды:
add user <username> <password>

Но пользователи не привязывались к приложениям.

Далее, у меня включена обязательная аутентификация для REST API через disable_rest_auth=false
с этой настройкой перестает работать стандартный MCU пример с демо-страниц.

отключение настройки запускает пример с MCU, и убирает все 401 ошибки из логов.
Но когда поток убирается из микшера даже в примере с MCU, он всё равно убивается.

Форму с доступом вам отправил.

Max · Feb 16, 2021

McSeemZ said:
Далее, у меня включена обязательная аутентификация для REST API через disable_rest_auth=false
с этой настройкой перестает работать стандартный MCU пример с демо-страниц.

отключение настройки запускает пример с MCU, и убирает все 401 ошибки из логов.

Эту проблему мы воспроизвели и создали тикет WCS-3070 для ее исправления. В качестве временного решения рекомендуем либо отключить аутентификацию для REST API, либо переопределить defaultApp на собственный бэкенд (сейчас используется отдельное приложение только для публикации потоков, и там определены не все методы).

McSeemZ said:
Но когда поток убирается из микшера даже в примере с MCU, он всё равно убивается.

Форму с доступом вам отправил.

Проблему с остановкой публикации мы не смогли проверить, поскольку сервер недоступен по указанному ключу:

Пожалуйста, предоставьте работающий ключ, чтобы мы могли проверить и эту проблему.

McSeemZ · Feb 16, 2021

@Max
если я переопределю defaultApp на свой бэкенд, не принесет ли это побочных эффектов для методов, которые в моем приложении еще не определены?

По поводу доступа - доступ поправлен, проверяйте с тем же ключом и паролем. sudo у вас есть.

Max · Feb 17, 2021

McSeemZ said:
По поводу доступа - доступ поправлен, проверяйте с тем же ключом и паролем. sudo у вас есть

Доступы работают, мы проверили публикацию потока в микшер и удаление из микшера. С настройкой

Code:

disable_rest_auth=true

и использованием бэкенда по умолчанию defaultApp в примере Media Devices на Вашем сервере проблема не воспроизводится, публикация потока не останавливается при выводе из микшера

Видимо, проблема в бэкенде либо во фронте или во взаимодействии бэкенда с фронтом, т.к. по предыдущим логам команда unPublishStream приходит с фронта.

McSeemZ said:
если я переопределю defaultApp на свой бэкенд, не принесет ли это побочных эффектов для методов, которые в моем приложении еще не определены?

Если Ваш бэкенд будет в ответ на REST hook запросы возвращать эхо с 200 OK, то побочных эффектов не должно быть. См также пример REST hook приложения, в котором явно определен только метод /connect, на все остальные методы возвращается тело поступившего запроса c заголовком 200 OK.

McSeemZ · Feb 17, 2021

@Max
Понял Вас. Всё так и есть, фронт неправильно отрабатывал событие с микшера, что поток проигрывания отключен со статусом FAILED (хотя это неочевидно, как публикация связана с проигрыванием для транслирующего), и рубил публикацию.
Спасибо за то, что помогли разобраться.
По остальным вопросам, которые я задавал, всё отработало корректно, спасибо за помощь.

Держите в курсе, когда WCS-3070 будет зарелизен.

Max · Feb 20, 2021

Мы исправили проблему с отклонением запросов к встроенному бэкенду (401 Unauthorized) с настройкой disable_rest_auth=false в сборке 5.2.901. Пожалуйста, обновите сервер и проверьте.

Как скрыть отображение заглушенных видеостримов (videoMuted) в миксере?

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator

McSeemZ

New Member

Max

Administrator