не понятно. в метриках где смотреть? вы дали ссылку снова на документацию не конкретно
Чтобы посмотреть метрики потока, опубликованного на сервере под именем
stream1, необходимо отправить REST API запрос
/stream/find (сборка
5.2.923 и новее)
Code:
POST /rest-api/stream/find HTTP/1.1
Host: wcs:8081
Content-Type: application/json
{
"name":"stream1",
"published":true,
"display":["metrics"]
}
или в любой сборке
/stream/metrics
Code:
POST /rest-api/stream/metrics HTTP/1.1
Host: wcs:8081
Content-Type: application/json
{
"name":"stream1"
}
В ответе будет набор метрик потока
Code:
{
"VIDEO_B_FRAMES": 0,
"VIDEO_WIDTH": 1920,
"VIDEO_SYNC": 1583463093448,
"AUDIO_RATE": 31832,
"VIDEO_PLI": 0,
"VIDEO_HEIGHT": 1080,
"AUDIO_SYNC": 1583463093415,
"VIDEO_FPS": 36,
"AUDIO_CODEC": 111,
"VIDEO_P_FRAMES": 3989,
"VIDEO_RATE": 684352,
"VIDEO_CODEC": 119,
"VIDEO_K_FRAMES": 173,
"VIDEO_NACK": 1,
"VIDEO_LOST": 1,
"AUDIO_LOST": 130
}
Из этого набора Вас интересует метрика
AUDIO_RATE, которая показывает текущее мгновенное значение битрейта аудио составляющей потока.
Именно это и написано в документации и в ответе
выше. Есть ли у Вас затруднения c пониманием вышенаписанного?
Кроме того, на скриншоте все же есть неточность в назначении констрейнтов.
Посмотрите, пожалуйста, на пример из
этого поста на основе кода примера
Media Devices
Code:
@NonNull
private Constraints getConstraints() {
audioConstraints = new AudioConstraints();
/// Настраиваем битрейт аудио публикации
audioConstraints.setBitrate(30000);
/// Указываем null вместо videoConstraints, в этом случае видео не будет публиковаться
return new Constraints(audioConstraints, null);
}
...
StreamOptions streamOptions = new StreamOptions(streamName);
Constraints constraints = getConstraints();
streamOptions.setConstraints(constraints);
publishStream = session.createStream(streamOptions);
...
publishStream.publish();
2 человека подключается на 1 микшер и не могут поговорить . Все заикается , задержка 1-4 секунды, рвется связь постоянно
Это однозначно говорит о проблемах с каналом от паблишера/подписчика до сервера. Для аудио потока высокая пропускная способность обычно не нужна, поэтому, возможно, на канале есть потери. То, что на стороне сервера 10 Гбит, не говорит ни о чем, оценивать необходимо весь канал, включая последнюю милю.
Для проверки рекомендуем использовать примеры на WebSDK, поскольку их проще твикать при необходимости.
1. Проверьте, воспроизводится ли проблема в примере
MCU Client со следующими изменениями в
этом коде
Code:
function getConstraints() {
var constraints = {
audio: $("#hasAudio").is(':checked'),
video: false // Отключаем публикацию видео
};
return constraints;
}
2. Если проблема воспроизводится, уточните, какой канал публикации используется: 2G, 3G, 4G, Wi-Fi, wired? Какова пропускная способность канала от клиента до сервера, измеренная при помощи
iperf:
На стороне сервера (используйте порт, открытый для входящих подключений):
Code:
# Stop WCS
systemctl stop webcallserver
# Install iperf
yum install iperf3
# Run iperf in server mode
iperf3 -s -p 5201
На стороне клиента:
Code:
# Test upstream channel
iperf3 -c wcs -p 5201
# Test downstream channel
iperf3 -c wcs -p 5201 -R
Этот тест покажет пропускную способность канала и потери на канале
3. При публикации потока проверьте метрику
AUDIO_LOST
4. Если тесты показывают потери в канале, может помочь следующее:
- сменить канал у клиента (последнюю милю, провайдера и т.д.)
- мигрировать сервер в датацентр ближе к клиенту (например, из США в Европу)
- использовать TCP транспорт (пример для публикации, для проигрывания настраивается аналогично)
Code:
StreamOptions streamOptions = new StreamOptions(streamName);
Constraints constraints = getConstraints();
streamOptions.setConstraints(constraints);
streamOptions.setTransport("TCP"); /// Настраиваем использование TCP транспорта для WebRTC
publishStream = session.createStream(streamOptions);
Вы можете помочь пожалуйста? конкретно! пошагово! ЧТО СДЕЛАТЬ?
Выше приведен алгоритм выявления и устранения возможной проблемы.
- в пердыдущих тикетах вы говорили, что так можно задать битрейт, щас уже нельзя или вообще непонятно, что вы говорите и как понимать вашу документацию
Битрейт публикации потока задается только в констрейнтах. Настройками сервера можно задать ограничения по битрейту при публикации, но только для видео.
Настройка
opus.encoder.bitrate, как видно из ее названия, управляет битрейтом Opus энкодера. Энкодер, в свою очередь, работает при транскодировании звука из любого другого кодека в Opus, либо на выходе микшера, поскольку микшер декодирует входящие потоки в несжатое PCM аудио, микширует их, а затем кодирует заново.
Ранее мы упоминали эту опцию в ответ на Ваши вопросы, как понизить битрейт выходного потока микшера.
где это вообще? и почему на bitrate есть несколь разных названий "bitrate": 0, "minBitrate": 0, "maxBitrate": 0, "audioBitrate": 0,
но только не ваш "AUDIO_RATE"
Изначально эти параметры предназначались для простановки в событии /publishStream на момент публикации потока на сервере. Сейчас они проставляются только для выходного потока транскодера, но тоже на момент начала публикации.
AUDIO_RATE,
VIDEO_RATE показывают актуальные мгновенные значения битрейтов на момент запроса /stream/find или /stream/metrics. WebRTC работает так, что битрейт может изменяться в зависимости от доступной полосы пропускания, поэтому именно значения метрик являются наиболее актуальными.
Остались ли у Вас затруднения с пониманием вышеприведенных примеров?
