Зависает микшер

Здравствуйте! Столкнулись со следующей проблемой:

При использовании сценария chat room из двух потоков с помощью rest api создается микшер. Пробуем смотреть полученный поток через rtmp, но через 10-15 секунд он зависает, а ещё через 10-15 секунд исчезает и обьект микшера. Причем входящие потоки все ещё есть и транслируются.

В журнале server_logs/flashphoner.log есть только записи о том, что сессия не найдена, но никакой детальной информации нет.

Пробовали включать следующие настройки
streaming_video_decoder_fast_start=true
mixer_idle_timeout=10000

Тип развёртывания - в Amazon EC2. Поднимаем инстанс WCS создаем там стримы, собираем их в микшер и транслируем поток дальше. После завершения выключаем сервер WCS.

Что ещё можно сделать? На что обратить внимание?

Записи из журнала
Code:
13:54:29,981 INFO          MediaHandler - API-ASYNC-pool-13-thread-1 Client /34.240.220.56:34656/172.20.1.180:1935 playStream Stream{mediaSessionId='4ce86894-314f-4cf2-810f-ac2bdc56c7291/34.240.220.56:34656/1
72.20.1.180:1935', remoteMediaElementId='null', name='4ce86894-314f-4cf2-810f-ac2bdc56c729', published=false, hasVideo=true, hasAudio=true, status=PENDING, sdp='v=0
o=- 1988962254 1988962254 IN IP4 0.0.0.0
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1
a=recvonly
m=audio 0 RTP/AVP 97 8 0 102 103 104 105 106 107 108 109 110
a=rtpmap:97 SPEEX/16000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:102 mpeg4-generic/48000/1
a=rtpmap:103 mpeg4-generic/44100/1
a=rtpmap:104 mpeg4-generic/32000/1
a=rtpmap:105 mpeg4-generic/24000/1
a=rtpmap:106 mpeg4-generic/22050/1
a=rtpmap:107 mpeg4-generic/16000/1
a=rtpmap:108 mpeg4-generic/12000/1
a=rtpmap:109 mpeg4-generic/11025/1
a=rtpmap:110 mpeg4-generic/8000/1
a=recvonly
', audioCodec='null', videoCodec='null', info='null', record=false, recordName='null', width=0, height=0, bitrate=0, minBitrate=0, maxBitrate=0, quality=0, rtmpUrl='null', parentMediaSessionId='null', createD
ate=null, endDate=null, streamInfo=Context{custom={}, nodeId='null', appKey='null', sessionId='null'}, mediaProvider='Flash', timeShift='null', transport='UDP', profile='null', level='null', preset='null', pr
ofiles='null'} Context{custom={}, nodeId='null', appKey='flashStreamingApp', sessionId='/34.240.220.56:34656/172.20.1.180:1935'}
13:54:29,981 INFO         ServerHandler - API-ASYNC-pool-13-thread-1 client requested live stream: 4ce86894-314f-4cf2-810f-ac2bdc56c729, stream not found
13:54:29,981 ERROR         MediaHandler - API-ASYNC-pool-13-thread-1 playStream actualSession doesn't exists, session name 4ce86894-314f-4cf2-810f-ac2bdc56c729
13:54:29,982 INFO            RestClient - API-ASYNC-pool-13-thread-1 SEND REST OBJECT ==>
URL:http://localhost:8081/apps/EchoApp/StreamStatusEvent
OBJECT:
{
  "nodeId" : "iqD9EPRWywJcLfmNSscYQpVOwEF2eelI@18.202.166.166",
  "appKey" : "flashStreamingApp",
  "sessionId" : "/34.240.220.56:34656/172.20.1.180:1935",
  "mediaSessionId" : "4ce86894-314f-4cf2-810f-ac2bdc56c7291/34.240.220.56:34656/172.20.1.180:1935",
  "name" : "4ce86894-314f-4cf2-810f-ac2bdc56c729",
  "published" : false,
  "hasVideo" : true,
  "hasAudio" : true,
  "status" : "FAILED",
  "info" : "Session does not exist",
  "record" : false,
  "width" : 0,
  "height" : 0,
  "bitrate" : 0,
  "minBitrate" : 0,
  "maxBitrate" : 0,
  "quality" : 0,
  "history" : false,
  "gop" : 0,
  "fps" : 0,
  "audioBitrate" : 0,
  "codecImpl" : "",
  "transport" : "UDP",
  "cvoExtension" : true,
  "mediaType" : "play",
  "mediaProvider" : "Flash"
}
13:54:29,987 INFO         RestApiRouter - HTTP-pool-3-thread-9 Use controller class com.flashphoner.rest.server.apps.echo_apps.EchoApp with path /apps/EchoApp/StreamStatusEvent
13:54:29,987 INFO               EchoApp - HTTP-pool-3-thread-9 handleRequest method: StreamStatusEvent params:{nodeId=iqD9EPRWywJcLfmNSscYQpVOwEF2eelI@18.202.166.166, appKey=flashStreamingApp, sessionId=/34.2
40.220.56:34656/172.20.1.180:1935, mediaSessionId=4ce86894-314f-4cf2-810f-ac2bdc56c7291/34.240.220.56:34656/172.20.1.180:1935, name=4ce86894-314f-4cf2-810f-ac2bdc56c729, published=false, hasVideo=true, hasAud
io=true, status=FAILED, info=Session does not exist, record=false, width=0, height=0, bitrate=0, minBitrate=0, maxBitrate=0, quality=0, history=false, gop=0, fps=0, audioBitrate=0, codecImpl=, transport=UDP,
cvoExtension=true, mediaType=play, mediaProvider=Flash}
13:54:29,987 INFO            RestClient - API-ASYNC-pool-13-thread-1 content -> {"nodeId":"iqD9EPRWywJcLfmNSscYQpVOwEF2eelI@18.202.166.166","appKey":"flashStreamingApp","sessionId":"/34.240.220.56:34656/172.2
0.1.180:1935","mediaSessionId":"4ce86894-314f-4cf2-810f-ac2bdc56c7291/34.240.220.56:34656/172.20.1.180:1935","name":"4ce86894-314f-4cf2-810f-ac2bdc56c729","published":false,"hasVideo":true,"hasAudio":true,"st
atus":"FAILED","info":"Session does not exist","record":false,"width":0,"height":0,"bitrate":0,"minBitrate":0,"maxBitrate":0,"quality":0,"history":false,"gop":0,"fps":0,"audioBitrate":0,"codecImpl":"","transp
ort":"UDP","cvoExtension":true,"mediaType":"play","mediaProvider":"Flash"}
13:54:29,990 INFO            RestClient - API-ASYNC-pool-13-thread-1 RECEIVED REST OBJECT <==
URL:http://localhost:8081/apps/EchoApp/StreamStatusEvent
OBJECT:
{
  "nodeId" : "iqD9EPRWywJcLfmNSscYQpVOwEF2eelI@18.202.166.166",
  "appKey" : "flashStreamingApp",
  "sessionId" : "/34.240.220.56:34656/172.20.1.180:1935",
  "mediaSessionId" : "4ce86894-314f-4cf2-810f-ac2bdc56c7291/34.240.220.56:34656/172.20.1.180:1935",
  "name" : "4ce86894-314f-4cf2-810f-ac2bdc56c729",
  "published" : false,
  "hasVideo" : true,
  "hasAudio" : true,
  "status" : "FAILED",
  "info" : "Session does not exist",
  "record" : false,
  "width" : 0,
  "height" : 0,
  "bitrate" : 0,
  "minBitrate" : 0,
  "maxBitrate" : 0,
  "quality" : 0,
  "history" : false,
  "gop" : 0,
  "fps" : 0,
  "audioBitrate" : 0,
  "codecImpl" : "",
  "transport" : "UDP",
  "cvoExtension" : true,
  "mediaType" : "play",
  "mediaProvider" : "Flash"
}
 

Max

Administrator
Staff member
Добрый день.
Обращаем ваше внимание, что при микшировании включается транскодинг, поэтому требования к ресурсам сервера повышены. Минимальная рекомендуемая конфигурация в этом случае - c5.2xlarge.
mixer_idle_timeout=10000
Эта настройка определяет, как быстро микшер завершится, если у него нет потоков на входе.
По симптомам, которые Вы описываете, похоже, что публикация входящих потоков останавливается. Проверяете ли Вы в ходе теста, играются ли входящие потоки? По какой технологии потоки публикуются: WebRTC, RTMP?
Пожалуйста, воспроизведите проблему, соберите отчет, как описано здесь, и вышлите, используя эту форму. Если со сбором отчета возникают проблемы, предоставьте, пожалуйста, доступ к серверу с возможностью опубликовать и забрать потоки, мы проверим. Доступы необходимо выслать, используя эту форму. Подробнее об организации доступа здесь.
 
Добрый день! После небольшого перерыва возвращаемся к нашей проблеме )

Мы попробовали разные конфигурации инстансов EC2 вплоть до c5.2xlarge, но ситуация везде одинакова - максимум 30% загрузки процессорной мощности.

Путём тестирования обнаружили, что при использовании версии WCS 5.2.780-fcc56854fc17318b93cc9d4fd7d712f791520d6b всё работает хорошо. Никаких разрывов, зависаний или фризов. Даже на более слабых конфигурациях. При обновлении до версии 5.2.873-5d7b26170000f51dd049f4e5304a426f66b83934 в логах появляется такая ошибка:

Code:
14:35:37,701 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL
14:35:38,207 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL
14:35:41,962 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL
Вместе с ошибкой, в трансляции появляются зависания или прерывания. Результат одинаков и на менее мощных инстансах и на c5.2xlarge. Кажется, что ошибка появляется при попытке чтения исходящего RTMP потока.

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

Были включены следующие настройки сервера:

Code:
echo rest_max_connections=20 >> /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties
echo webrtc_cc2_twcc=false >> /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties
echo streaming_video_decoder_fast_start=true >> /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties
echo wcs_agent_session_timeout=240000 >> /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties
echo mixer_idle_timeout=10000 >> /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties
Надеюсь на Вашу помощь
 

Max

Administrator
Staff member
Добрый день!

Провели тестирование по вашему кейсу.
Для WCS версии 5.2.873 на AWS c5.2xlarge при воспроизведении потока микшера в VLC плеере по RTMP подвисаний или артефактов не было. Поток микшера воспроизводился корректно.

Для дальнейшей диагностики, пожалуйста, предоставьте ssh доступ к вашему WCS серверу.
Доступы можно отправить с помощью приватной формы.
 
Здравствуйте!

Доступ предоставил. Отмечу, что на данном конкретном сервере проблема появляется не в ста процентах случаев. Иногда воспроизводится, иногда нет. Но всегда присутствует видимый рассинхрон видео и аудио. Кроме того, не знаю как лучше описать, аудио звучит так, будто на быстрой перемотке.

Кроме того, что означают эти ошибки неясно

Code:
14:35:37,701 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL
14:35:38,207 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL
14:35:41,962 ERROR 1a-b8eb-007a1183ef19 - MIXER-AGENT-mixer://mixer_59214252-d6be-4a1a-b8eb-007a1183ef19-17fa3355-b59c-47c1-863d-4f71fd2b7548 TRANSCODER RESULT NULL

Смотреть пробовали разными способами (не знаю на сколько это важно):
- через VLC
- рестримить по RTMP в Wowza Streaming Cloud и смотреть поток там
 

Max

Administrator
Staff member
Кроме того, не знаю как лучше описать, аудио звучит так, будто на быстрой перемотке.
Это известная проблема, работаем над ней в тикете WCS-2982. В качестве обхода можно включить MCU:
Code:
mixer_mcu_audio=true
mixer_mcu_video=true
Кроме того, что означают эти ошибки неясно
Эта ошибка означает, что очередной кадр не удалось закодировать. На работу микшера не влияет, можете ее игнорировать.
Смотреть пробовали разными способами (не знаю на сколько это важно):
- через VLC
- рестримить по RTMP в Wowza Streaming Cloud и смотреть поток там
Это важно, поскольку в первом случае WCS выступает как RTMP сервер, а во втором - как RTMP клиент, и работают разные участки кода. Спасибо, что уточнили кейс, это поможет в тестировании.
Пожалуйста, ожидайте результатов, мы сообщим здесь.
 

Max

Administrator
Staff member
Добрый день!

Провели тестирование вашего сервера.

По результатам тестирования проблему с разрушением микшера при ретрансляции на сторонний RTMP сервер воспроизвести не удалось.
Из 10 тестов успешно прошли 10.

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

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

Attachments

Добрый день! Спасибо

Наша методика тестирования в целом похожа, но отличается в некоторых моментах

1. Входящие потоки мы не публикуем через интерфейс админ панели. Вместо этого используем ваш WebSDK и поток с вебкамеры.
2. Мы явно не репаблишим поток микшера в Wowza Streaming Cloud. Вместо этого Wowza сам забирает поток, как и в случае с VLC. Однако проблемы наблюдаются в обоих случаях.
3. Сервера WCS не живут постоянно, как в этом случае. Мы поднимаем сервер, проводим трансляцию и тушим сервер. Для новой трансляции создается новый инстанс WCS.

Все REST API вызовы абсолютно идентичны Вашим.
 

Max

Administrator
Staff member
В таком случае, попробуйте протестировать по нашей методике, с публикацией потоков с помощью стандартного примера "Two Way Video Chat"

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

Форма для отправки
 
Добрый день!

Провел дополнительный ряд тестов и по Вашей методике в том числе. Не знаю в чём была проблема, но она решилась с обновлением до версии 5.2.878-0fa519866a01f772758d01a8bde7f31717e07b85

Итог такой, что в абсолютно идентичных окружениях (тип инстанса, настройки сети, публикация потоков, способ чтения исходящего потока микшера) сервер версии 5.2.873-5d7b26170000f51dd049f4e5304a426f66b83934 работает плохо (зависание потока, фризы и т.д), а новая версия WCS работает без каких-либо видимых проблем, как и должно.
 

Max

Administrator
Staff member
Добрый день!

Рады, что у вас все заработало!

Такое поведение микшера (зависание потока, фризы и незапланированное разрушение микшера) как правило, может быть вызвано проблемами с каналами публикации.
Микшер работает, пока все входящие в него потоки либо не завершатся, либо не будут удалены из микшера запросом /mixer/remove
Кроме того, микшер остановится, если прекратится медиатрафик во всех входящих потоках. При mixer_idle_timeout=10000 и при плохом канале такое вполне возможно. Публикация самого потока на сервере при этом останется, пока не истечет rtp_activity_timeout=60 (минута по умолчанию).

Проблемы в коде на стороне браузера могут привести к остановке публикации или к остановке медиатрафика в потоке, поэтому мы ранее запрашивали пример кода.
Фиксы в сборках между 5.2.873 и 5.2.878 не относятся к используемым вами возможностям микшера. В наших тестированиях обе сборки (5.2.873 на вашем сервере и 5.2.878 на нашем) показывали идентичные результаты.
 
Top