Микширование видеопотока и аудио

[gekz]

Доброго времени суток
не хотелось дублировать темы, по сути вопрос тоже связан с микшером, в общем сейчас тестируем эксплуатацию медиа сервера на триал лицензии ( до этого использовали чистый webrtc peer-to-peer), но возникла задача, которую без сервера не решить, а именно:

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

Сейчас тестируем базовый функционал (микшер реального времени с MCU ) при 7 участниках, в дальнейшем может быть и более.

Проблема №1: при просмотре “своего” микшер потока (где отображается видео всех в тч себя + аудио всех, кроме себя) есть приличные задержки именно в отображении себя, другие может тоже идут с задержкой, но мне они приходят синхронизировано и это не заметно. А вот когда смотришь на себя там приличная задержка, соответственно вопрос:

Можно ли при определенной реализации получить микшер где есть все, кроме меня, а себя выводить где-то отдельно от микшера локально, но при этом чтоб всем мой поток с аудио и видео уходил?

Проблема №2: у некоторых картинка сыпется в плане качества … возможно слабый интернет и тд, можно ли, и вообще, есть ли какие советы по MCU и/или по MCU в реальном времени по настройки сервера/кодеков/битрейтов для минимизации потерь качества и работы минимально без задержек. Так как при peer to peer таких проблем не было, но были проблемы с большой нагрузкой на компьютеры участников конференции. И вообще может есть какие советы.

Еще я так понял микшер создается в h264 всегда и при ретрансляции на ютуб тоже ? и соотвественно нет смысла передавать vp8 для минимизации конвертаций? Или я не прав ?


Буду благодарен за любые референсы на документацию, может темы на форуме( хотя смотрел )/примеры и другие статьи.

Интересует именно WEB SDK

 

[Max]

Добрый день

не хотелось дублировать темы,

Это неправильный подход. Форум используется, в том числе, как публичный баг-трекер, поэтому вопросы, которые не относятся к проблемам, упомянутым в теме, следует задавать отдельно.

Проблема №1: при просмотре “своего” микшер потока (где отображается видео всех в тч себя + аудио всех, кроме себя) есть приличные задержки именно в отображении себя, другие может тоже идут с задержкой, но мне они приходят синхронизировано и это не заметно.

Задача микшера в конференции как раз в том и состоит, чтобы доставить один поток всем участникам. Т.е. Вы видите себя таким, каким Вас видят остальные участники конференции. Микшер буферизирует потоки участников, чтобы синхронизировать их. Вы можете включить отображение буферизации для потоков

mixer_display_stream_name=true 
mixer_debug_mode=true

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

mixer_video_width=640
mixer_video_height=360

Можно ли при определенной реализации получить микшер где есть все, кроме меня, а себя выводить где-то отдельно от микшера локально, но при этом чтоб всем мой поток с аудио и видео уходил?

Нет, этого сделать нельзя.

Проблема №2: у некоторых картинка сыпется в плане качества … возможно слабый интернет и тд, можно ли, и вообще, есть ли какие советы по MCU и/или по MCU в реальном времени по настройки сервера/кодеков/битрейтов для минимизации потерь качества и работы минимально без задержек. Так как при peer to peer таких проблем не было, но были проблемы с большой нагрузкой на компьютеры участников конференции. И вообще может есть какие советы.

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

constraints.video.maxBitrate=600

- либо ограничивать максимальный битрейт на стороне сервера (это будет действовать на все публикуемые потоки), указывается в бит/с

webrtc_cc_max_bitrate=600000

Подробнее об управлении битрейтом можно прочитать здесь. Обратите внимание, что не рекомендуется ограничивать минимальный битрейт во избежание фризов потока участника в микшере.
Рекомендуется также снижать разрешение публикации при плохом канале участника

constraints.video = {
    width: 320,
    height: 240
};

Методика оценки качества канала публикации и воспроизведения, на базе которой можно реализовать индикатор для клиента, приведена здесь.

Еще я так понял микшер создается в h264 всегда и при ретрансляции на ютуб тоже ? и соотвественно нет смысла передавать vp8 для минимизации конвертаций? Или я не прав ?

Да, выходной поток микшера кодируется в H264 + Opus, для записи звук перекодируется в AAC.
Рекомендованный Youtube и поддерживаемый нами способ ретрансляции предполагает использование RTMP, поэтому здесь также используется H264 + AAC.
VP8 имеет смысл использовать для публикации/воспроизведения, если браузер не поддерживает H264 без установки сторонних библиотек, но число конвертаций это не уменьшит.

Буду благодарен за любые референсы на документацию, может темы на форуме( хотя смотрел )/примеры и другие статьи.

Вот, например, статья по практической реализации MCU микшера

 

[gekz]

Обратите внимание, что не рекомендуется ограничивать минимальный битрейт во избежание фризов потока участника в микшере.

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

 

[dmitry1987]

Начиная со сборки 5.2.689, можно добавить только видео из потока в аудио+видео микшер по REST API, например

Подскажите а возможно ли реализовать так чтобы аудио потоки входящие в микшированный поток, были представлены в выходном стриме отдельными звуковыми дорожками ?

 

[Max]

Подскажите а возможно ли реализовать так чтобы аудио потоки входящие в микшированный поток, были представлены в выходном стриме отдельными звуковыми дорожками ?

Такая возможность не реализована на основе микшера.

Можно попробовать реализовать с помощью WebSDK, т.е. не на стороне сервера, а на стороне клиента.

Например,

На стороне сервера публикуются два потока stream1 и stream2, которые добавляются к микшеру. Выходной поток микшера – mixedStream .

На веб странице (на стороне браузера клиента) воспроизводим видео часть потока mixedStream

function playStream() {
    var constraints = {
    audio: false,
    video: true
    };
    var options = {
        name: "mixedStream",
        display: document.getElementById("myVideo"),
        constraints: constraints
    };
    stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {
     });
    stream.play();
}

По нажатию кнопки Play Sound 1 воспроизводим аудио из потока Stream1

function playSound1() {
    var constraints = {
    audio: true,
    video: false
    };
    var options = {
        name: "stream1",
        display: document.getElementById("sound"),
        constraints: constraints
    };
    stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {
        stream.unmuteRemoteAudio();
        sound1Btn.value = "Mute Sound 1";
    });
    stream.play();

По нажатию кнопки Mute Sound 1 заглушаем воспроизведение аудио из потока stream1. Поток с сервера при этом не останавливается, а продолжает играть на HTML странице, только беззвучно. При необходимости можно снова нажать на кнопку Play Sound 1 и снова включить звук.

sound1Btn.onclick = function() {
        sound1Btn.value = "Play Sound 1";
        stream.muteRemoteAudio();
        clicking();
    }

Вторую кнопку Play Sound 2 программируем идентично, только для потока stream2. Можно запрограммировать сколько угодно кнопок - по числу нужных аудиопотоков. Или сделать чекбоксы или переключатели вместо кнопок.

Полные файлы с минимальным кодом для тестирования в приложенном архиве.

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

 

[dmitry1987]

Можно попробовать реализовать с помощью WebSDK, т.е. не на стороне сервера, а на стороне клиента.

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

Спасибо за ответ. Такой вариант мы тоже рассматривали, но нам бы хотелось серверное решение по микшированию, в том числе для того чтобы экономить ресурсы. Мы так же рассматривали вариант с микшированием через ffmpeg , т.е. сначала микшировать при помощи flashphoner видео, а потом к этому потоку мерджить уже необходимые языковые потоки и выдавать уже микшированную языковую версию. Но при использование ffpmeg появляются задержки (если даже пересобирать один и тот же стрим), а именно тормозит первый подключаемый стрим , т.к. по всему видимому инициализация входящих стримов последовательная и первый стрим успевает накопить буффер и отдает в выходном потоке более старые фреймы, пытались это поправить управляя параметром pts (presentation time stamp) , что немного помогло но все равно остается задержка небольшая. например так:

ffmpeg -i rtmp://ourserver.ru:1935/live/stream_in -i rtmp://ourserver.ru:1935/live/stream_in -vcodec copy -filter_complex "[0:v]setpts='PTS-STARTPTS'[v0];[1:a]asetpts='PTS-STARTPTS'[a1]" -map "[v0]" -map "[a1]" -preset ultrafast -tune zerolatency -copyts -copytb 1 -async 1000 -vsync 1 -acodec aac -vcodec h264 -f flv rtmp://ourserver:1935/live/stream_ffmpeg

параметры -copyts -copytb 1 -async 1000 -vsync 1 практически не влияют на результат, пробовали разные комбинации

если пробовать переопределять таймстемпы на основание текущего времени как описано тут https://ffmpeg.org/ffmpeg-filters.html#Examples-142
Generate timestamps from a "live source" and rebase onto the current timebase
setpts='(RTCTIME - RTCSTART) / (TB * 1000000)'
то видео начинает сильно тормозить (растягиваться во времени, замедляться), возможно в примере какая-то ошибка.

если пробовать убрать буффер входящего потока , то ситуация меняется противоложно, начинает тормозить второй поток. причем лаг видео и аудио отличается если их менять местами, видимо инициализация видео занимает больше времени.

возможно можно как-то полагаться на таймстемпы входящих потоков от flashphoner и их пробрасывать в выходной поток ? чтобы исходящий стрим был синхронизирован по таймстемпам которые отдает flashphoner ? не оч глубоко понимаем протокол и состав контейнеров, в них присутствуют абсолютные серверные таймстемпы по которым синхронизируются потоки на уровне сервера flashphoner ?

 

[Max]

Результат микширования, в нашем случае, это один суммированный сигнал, который нельзя поделить, т.е. одна видео дорожка в потоке и одна аудиодорожка.
Если мы правильно понимаем задачу, вы хотите добавить к одному видеостриму несколько звуковых дорожек и переключаться между ними на стороне плеера.
Для WebRTC подписчиков это можно реализовать на стороне клиента, как мы предложили выше. Такой вариант не дает дополнительной нагрузки на сервер и дает небольшую дополнительную нагрузку на канал клиента, т.к. требуется принять все аудиопотоки для быстрого переключения между ними.
Можно также реализовать на стороне сервера получение нескольких видеопотоков, каждый со своей звуковой дорожкой. Для этого видео поток нужно смикшировать с каждой из аудио дорожек отдельно. В последних сборках WCS есть возможность добавить один и тот же поток в несколько микшеров. Этот вариант дает более высокую нагрузку на сервер, а на стороне клиента для переключения между звуковыми дорожками необходимо будет запрашивать для воспроизведения поток с соответствующей дорожкой, что даст паузу до нескольких секунд при переключении, либо запросить все потоки, скрывать HTML5 видео элементы на странице и глушить аудио. Таким образом, это вариант выглядит сложнее по реализации и дороже обходится по ресурсам и каналу.
Пожалуйста, уточните, по какой технологии клиент должен играть поток: WebRTC, RTMP, HLS?
Также обращаем внимание, что при любом из этих способов аудио не будет точно синхронизировано с видео, поскольку с точки зрения как микшера, так и плеера эти потоки идут с разных источников. Например, при подаче видео и аудио с разных источников в один микшер синхронизация в выходном потоке будет плавать примерно +-200 мс.

 

[Max]

Добрый день.
В последних сборках WCS мы добавили функции публикации/проигрывания нескольких потоков в одном WebRTC соединении: Функции SFU с поддержкой Simulcast
Также мы добавили несколько примеров использования SFU SDK в браузере:

• SFU Player
• SFU Two Way Streaming

Этот функционал позволяет добавлять аудиодорожки без микширования.