Получить данные о просмотре трансляции

[inpost]

Здравствуйте.
Последнее время стал получать жалобу следующего характера, что стример запустил поток и у него транслируется корректно. Клиент запускает видео, ждёт Х времени, а у него черный экран, он выключает и пишет жалобу, что у него ничего не идёт. При этом по логам я точно вижу, что событие STREAM_STATUS.PLAYING, то есть он воспроизводится. С моей стороны я провёл тесты и получил похожую картину (в прикреплённых), то есть событие срабатывает значительно раньше до того, как воспроизведение само появится. Выглядит это примерно следующим образом:
1. Область трансляции большая, статус PENDING
2. Статус PLAYING, область трансляции становится очень маленькой (как на скрин-шоте)
3. Жду Х секунд в зависимости от интернета (на быстром это менее секунды, на медленных я видел и 5-10 секунд лично)
4. Блок становится большим и появляются первые кадры трансляции.

Исходя из этого, хотелось бы понять следующее:
1. Возможно ли получить статус фактического воспроизведения трансляции, что отображаются кадры, а не начала получения кадров, где первый старт может достигать некоторого времени? Так как данный статус не подходит.
2. Могу ли я убедиться как-нибудь, что у пользователя действительно черный блок, без изображения трансляции?
3. Может есть какой-то идентификатор количества полученных кадров в секунду полноценных, или ещё что?

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

 

[Max]

Добрый день.

1. Область трансляции большая, статус PENDING
2. Статус PLAYING, область трансляции становится очень маленькой (как на скрин-шоте)
3. Жду Х секунд в зависимости от интернета (на быстром это менее секунды, на медленных я видел и 5-10 секунд лично)
4. Блок становится большим и появляются первые кадры трансляции.

Статус PLAYING выставляется потоку, когда установлено WebRTC соединение и поднята медиасессия для этого подписчика. При этом видео начнет играть на клиенте не раньше, чем будет получен первый ключевой кадр, содержащий основную информацию о видео на данный момент времени (последующие кадры содержат только изменения относительно последнего ключевого кадра).
В свою очередь, ключевые кадры высылает только публикующий клиент. Поэтому Вам необходимо обеспечить регулярное поступление ключевых кадров от паблишера.
Для WebRTC публикаций или потоков, захваченных по RTSP, это делается при помощи настроек сервера

periodic_fir_request=true
periodic_fir_request_interval=2000

В этом случае сервер будет запрашивать у браузера или RTSP-источника высылку ключевых кадров каждые 2 секунды.
Для потоков, опубликованных при помощи RTMP кодировщика, интервал отсылки ключевых кадров устанавливается настройками кодировщика. Например, для OBS это будет выглядеть так

Другая проблема может быть в канале пользователя: чем хуже канал и чем выше параметры потока (разрешение/битрейт), тем дольше поток будет начинать проигрывание, т.к. ключевые кадры могут не влезать в канал по своему объему и, как следствие, теряться. В этом случае, для того, чтобы компенсировать потери, используйте TCP в качестве WebRTC-транспорта

session.createStream({
    name: streamName,
    display: remoteVideo,
    transport: "TCP"
}).on(STREAM_STATUS.PENDING, function (stream) {
...
}).play();

Также может помочь транскодинг к более низкому разрешению/битрейту, но это создаст нагрузку на CPU сервера

session.createStream({
     name:"stream1",
     constraints: {
           audio: true,
           video: {
                 width: 640,
                 height: 360,
                 bitrate: 500
           }
     }
     ...
}).play();

Подробнее о транскодинге можно прочитать здесь.

 

[inpost]

Транскодинг совершается до bitrate: 1000, ещё ниже вообще не хочется. А проверять публишера не вариант, так как там трансляция работает стабильно, проблемы только у тех, кто подключается к трансляции. У них происходит чёрный экран и всё.

То есть нет никакой возможности убедиться, что у клиента не чёрный квадрат, а какое-то содержание?

 

[inpost]

Дополнительная информация.
1. У одного из членов команды удалось добиться этой проблемы.
2. TCP не помогло
3. Трансляция не запускалась более 10 минут.
4. При FullScreen мы получаем 0 сек, то есть ни одного кадра так и не прилетает.
5. Попробовал с другого компа, там запускается стабильно, с первого - попыток 20, не получается, ни TCP, ни версия последняя.

Может быть Вам показать с демонстрацией экрана? То есть доступ к браузеру есть, Mac, последняя версия Хрома, WebRTC, кодек OPUS.

Выходит, один клиент видит трансляцию, а второй не видит. При этом вне зависимости от того, кто первый или сколько соединений.

 

[inpost]

После того, как публикующий сделал стоп-старт, то трансляция заработала у всех.
В качестве эксперимента, в конфигах прописал h264 кодек в самое начало:
codecs = h264,opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,flv,mpv
, но это не помогло, при подключении всё равно определяется кодек как opus:

 

[inpost]

Ещё одно дополнение, стал массово получать жалобы за последнюю неделю.

 

[inpost]

Вот первый лог:
Тут видны 2 трансляции, одна ВКЛЮЧАЕТСЯ, вторая - НЕТ.
Во второй видно, что пакеты идут, не теряются, интернет-соединение стабильное, но мы имеем ситуацию, что не кодируются, и почему-то кодирование прилетает из ffmpeg.

 

[inpost]

Конфиг сервера:

# cat server.properties
#webrtc ports range
media_port_from  =31001
media_port_to   =32000
codecs     = h264,opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,flv,mpv
codecs_exclude_sip  =mpeg4-generic,flv,mpv
codecs_exclude_streaming =flv,telephone-event
codecs_exclude_sip_rtmp =opus,g729,g722,mpeg4-generic,vp8,mpv
webrtc_cc_min_bitrate = 500000
webrtc_cc_max_bitrate = 15000000
suppress_audio   =true
disable_rest_requests=true
#rest_request_timeout=5
#encoder_priority=OPENH264
#decoder_priority=OPENH264
enable_extended_logging=false
stream_record_policy_template={streamName}-{mediaSessionId}
#Config
ws.port         =8080
wss.port        =8443
#File will be located in conf directory
wss.keystore.file    =wss.jks
wss.keystore.password  =password
wss.cert.password    =password
rtmp.port        =1935
rtmfp.port            =1935
#keep_alive_algorithm may be INTERNAL, NONE, HIGH_LEVEL
keep_alive.algorithm    =HIGH_LEVEL
keep_alive.peer_interval  =2000
keep_alive.server_interval =5000
keep_alive.probes     =10
#Reliability: on, partial, off
video_reliable     =partial
audio_reliable     =partial
audio_frames_per_packet =6
burst_avoidance_count  =100
flush_audio_interval  =80
flush_video_interval  =0

 

[Max]

После того, как публикующий сделал стоп-старт, то трансляция заработала у всех.

Уточните, пожалуйста: при каком количестве подписчиков начинаются проблемы?
Если на одном потоке было много подписчиков, и у части из них воспроизводилась эта проблема при подключении, а при массовом переподключении не воспроизвелась, похоже, что требуется оптимизация раздачи потока подписчикам. Посмотрите также рекомендации по тюнингу в этой статье.
При этом WCS рекомендуем обновить до сборки 5.2.971 (как на нашем демо сервере), чтобы настройки, указанные по ссылке, работали.

В качестве эксперимента, в конфигах прописал h264 кодек в самое начало:
codecs = h264,opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,flv,mpv
, но это не помогло, при подключении всё равно определяется кодек как opus:

H264 - видео кодек, Opus - аудио кодек. При публикации WebRTC из браузера используются оба этих кодека для одного стрима, если стрим содержит аудио и видео.

То есть нет никакой возможности убедиться, что у клиента не чёрный квадрат, а какое-то содержание?

На стороне клиента можно получать данные WebRTC статистики: кодеки, разрешение, битрейт, количество полученных байтов, и на этом основании делать вывод, например, при низком битрейте видео (что характерно для случая, когда клиент видит черный экран) отключать подписчика.
Также можно контролировать качество канала на стороне подписчика и отключать его при снижении качества канала.