HLS broadcasting problem

[snark13]

Hi !

Возникла проблема с публикацией стримов через HLS.
Через какое-то время в HLS плейлисте начинают пропадать каждый второй сегмент
Вначале плейлист выглядит так -

#EXTM3U
#EXT-X-VERSION:8
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:30
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L31.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L32.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L33.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L34.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L35.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L36.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L37.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L38.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L39.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L40.ts

Нумерация сегментов идет последовательно
Через какое-то время нумерация начинает идти через сегмент (только четные номера), при проигрывании идет перескок по времени и периодически показывается спинер нехватки данных (video.js) -

#EXTM3U
#EXT-X-VERSION:8
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:184
#EXT-X-DISCONTINUITY-SEQUENCE:178
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L362.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L364.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L366.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L368.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L370.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L372.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L374.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L376.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L378.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.0,
Z14L380.ts

Этот же стрим по WebRTC показывается в это же время без замечаний.
Дополнительная информация - данный стрим получаем по RTSP. идет постоянная запись стрима (в TS сегменты длиной по 30 секунд).
Страница статистики сервера -
(вызывает вопрос накопившаяся ресинхронизация данного стрима - streams_synchronization=Z14L/-1925241001)

-----Connection Stats-----
connections=0
connections_rtmfp=0
connections_websocket=0
connections_hls=4
-----Port Stats-----
ports_media_free=493
ports_media_busy=6
ports_media_quarantine=0
ports_wcs_agents_free=998
ports_wcs_agents_busy=0
ports_wcs_agents_quarantine=0
-----Stream Stats-----
streams_webrtc_in=0
streams_webrtc_out=0
streams_websocket_out=0
streams_rtmfp_in=0
streams_rtmfp_out=0
streams_rtmp_in=0
streams_rtmp_out=0
streams_hls=1
streams_viewers=Z14L/1;Z14H/0
streams_synchronization=Z14L/-1925241001;Z14H/-100
stats_size=0
streams_rtsp_in=2
streams_rtsp_out=0
streams_rtmp_client_out=0
streams_play_rate=0
streams_stop_rate=0
-----Native Resources-----
native_resources=139623821980768,mpeg4-generic,-12204377;139624374597456,mpeg4-generic,-325079;139624376694400,RESAMPLER:8000/44100,896994;139623952580720,RESAMPLER:48000/8000,1049660;139623818142480,RESAMPLER:8000/48000,36613440
native_resources.audio_codecs=2
native_resources.audio_resamplers=3
native_resources.video_transcoders=0
native_resources.video_decoders=0
native_resources.video_encoders=0
native_resources.writers=0
-----Core Stats-----
core_heap_memory_used=835270168
core_java_committedMemory=3354308608
core_java_threads=85
core_java_freePhysicalMemorySize=96395264
core_java_arch=amd64
core_java_availableProcessors=2
core_java_freeSwapSpaceSize=1067241472
core_java_maxFileDescriptorCount=20000
core_java_open_file_descriptors=189
core_java_cpu_usage=16.92
core_java_totalPhysicalMemorySize=2044805120
core_java_totalSwapSpaceSize=2147479552
core_java_uptime=523640348
core_java_version=1.8.0_241
-----Call Stats-----
sip_processed_calls=0
sip_calls_state=established/0;trying/0;ringing/0;ring/0;ring_media/0;hold/0;busy/0;finish/0;session_progress/0;pending/0;failed/0
sip_calls=0
sip_calls_established=0
sip_calls_in=0
sip_calls_out=0
sip_calls_per_second=0.00
-----Sip Stats-----
sip_registered=0
-----Recording Stats-----
recording_sessions=1
-----System Stats-----
system_java_cpu_usage=25.00
system_java_load_average=0.41
-----Network Stats (Mbit/s)-----
global_bandwidth_in=0.000
global_bandwidth_out=0.000
-----Version info-----
wcs_version=5.2.637-0ecec53990d2b4617b889a6ee54c37b716bde9d7
wcs_client_version=0.5.28.2753-e0b72055c9fb5b2c4a9de71ba391e6a1ce78a29f
-----Errors info-----
java.lang.IndexOutOfBoundsException=113
javax.net.ssl.SSLException=96
javax.net.ssl.SSLHandshakeException=2
java.io.IOException=56
java.lang.NumberFormatException=5
java.lang.ArrayIndexOutOfBoundsException=7
java.lang.IllegalArgumentException=87
java.util.ConcurrentModificationException=2
java.lang.NullPointerException=2
java.lang.reflect.InvocationTargetException=76283
-----Degraded streams-----
degraded_streams=
degraded_streams_percent=0
-----Transcoding info-----
transcoding_video_decoding_resolutions=0x0/2
transcoding_video_decoding_average_time=0x0/-1.0
transcoding_video_decoding_max_time=0x0/-1
transcoding_video_decoding_average_queue_size=0x0/0.0
transcoding_video_decoding_max_queue_size=0x0/0
transcoding_video_decoding_load=0
transcoding_video_encoding_resolutions=0x0/2
transcoding_video_encoding_average_time=0x0/0.0
transcoding_video_encoding_max_time=0x0/0
transcoding_video_encoding_average_queue_size=0x0/0.0
transcoding_video_encoding_max_queue_size=0x0/0
transcoding_video_encoding_load=0

Так же в логи сервера начинают писаться в большом количестве записи такого вида -

01:39:30,294 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358108106:-1
01:39:30,297 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358108083:-1
01:39:30,300 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358108060:-1
01:39:30,304 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358108037:-1
01:39:30,307 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358108014:-1
01:39:30,361 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358107990:-1
01:39:30,369 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358107967:-1
01:39:30,373 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -1595358107944:-1
...

до этого писалось примерно так (очень изредка)

01:35:24,106 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -17:-1
...
01:38:02,184 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -40:-1
...
01:38:02,188 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -17:-1
...
01:39:06,147 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -40:-1
...
01:39:06,151 WARN  tputWriterTimeHelper - CommonFileRecorderThread Non monotonic audio time -17:-1
...

 

[Max]

Добрый день.
Статистика и логи указывают на проблему в самом стриме.
Уточните, пожалуйста, какая версия WCS используется?
В последних сборках было несколько фиксов по RTSP потокам, но рекомендовать обновление прямо сейчас мы не можем, т.к. в последних сборках RTSP потоки не проигрываются по HLS, заведен тикет WCS-2811.
Пожалуйста, предоставьте круглосуточный доступ к RTSP потоку по этой ссылке, либо, если это невозможно по какой-то причине, соберите отчет, как описано здесь, включая клиентские дебаговые логи и дамп трафика, снятый на стороне сервера. Дамп трафика нужно начинать снимать до публикации RTSP потока, чтобы в дамп попала установка RTSP соединения. Отчет и дамп необходимо отправить, используя эту ссылку (если размер архива не превышает 30 Мб, отправить его непосредственно, если превышает, выложить на файловый хостинг и отправить ссылку).

 

[snark13]

Сервер 5.2.637
Адрес RTSP стрима был послан.
Со стримом работают два WCS сервера (одинаковой версии), проблемы возникают в различное время (на одном может возникнуть, на другом нет, но рано или поздно возникают и там и там). Времени до возникновения проблемы может пройти от получаса до суток и более.

 

[Max]

В потоке с камеры в аудиосоставляющей тишина, есть потери аудиопакетов (видео при этом идет нормально). У нас были фиксы в части захвата RTSP, но рекомендовать обновление не можем до фикса по тикету WCS-2811.
Если есть возможность изменить настройки камеры, попробуйте исключить аудиосоставляющую, чтобы камера отдавала только видео.

 

[snark13]

Когда примерно можно ожидать билд с фиксом по тикету WCS-2811 ?
Есть ли возможность отключать звук в конфигурации сервера глобально для всех HLS потоков (даже если звук есть у источников, звук с камер получать нам надо обязательно, но для клиентов получающих видео по HLS можно звук не передавать, только для WebRTC) ?

 

[Max]

Когда примерно можно ожидать билд с фиксом по тикету WCS-2811 ?

Мы подняли приоритет данного тикета и сообщим здесь о результатах.

Есть ли возможность отключать звук в конфигурации сервера глобально для всех HLS потоков (даже если звук есть у источников, звук с камер получать нам надо обязательно, но для клиентов получающих видео по HLS можно звук не передавать, только для WebRTC) ?

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

 

[Max]

Если Вы используете REST API для захвата потока по RTSP и указываете имя, под которым играете его по HLS, например

curl -H "Content-Type: application/json" -X POST http://localhost:8081/rest-api/rtsp/startup -d '{"uri":"rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov","toStream":"stream1"}'

то проблема в тикете WCS-2811, скорее всего, Вас не затрагивает. Можете попытаться обновиться до последней сборки WCS c этой страницы и проверить, как будет играть проблемный RTSP поток.

 

[snark13]

Да. Мы используем REST API. Тестовый сервер проапдейтили (через ./webcallserver update - получили 708-ой билд) - HLS стримы воспроизводятся. Наблюдаем за поведением стримов.

Могут ли влиять на поведение воспроизведения проблемного потока параметры rtsp_fail_on_error_track и rtp_force_synchronization ? Они стояли в значениях -

rtsp_fail_on_error_track=false
rtp_force_synchronization=true

 

[Max]

rtsp_fail_on_error_track=false

Этот параметр заставляет сервер прекращать публикацию при явных ошибках в потоке. Попробуйте установить его в

rtsp_fail_on_error_track=true

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

rtp_force_synchronization=true

Эта настройка не актуальна и была удалена, ее можете убрать.

 

[snark13]

На новом билде (708)... Получаем ту же самую проблему и на другой камере (16)-

streams_synchronization=Z16H/-21800;Z15H/0;Z14L/-22257;Z16L/-100;Z14H/2079600704;Z15L/0

#EXTM3U
#EXT-X-VERSION:8
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:7452
#EXT-X-DISCONTINUITY-SEQUENCE:3270
#EXT-X-DISCONTINUITY
#EXTINF:4.0,
Z16H10722.ts
#EXT-X-DISCONTINUITY
#EXTINF:4.0,
Z16H10724.ts
#EXT-X-DISCONTINUITY
#EXTINF:4.0,
Z16H10726.ts
#EXT-X-DISCONTINUITY
#EXTINF:4.0,
Z16H10728.ts

Опция

rtsp_fail_on_error_track=true

не помогает - стрим не перезапускается по такой ошибке

 

[snark13]

Возможно будет полезна дополнительная информация - проблемный стрим у нас записывается в TS сегменты (длительностью по 30 секунд) для архива. Сегмент который писался в момент возникновения проблемы в стриме имеет интересную метаинформацию (длительность видео части - возможно проблема не с потерей звуковых пакетов а в некорректном видеопакете который убивает синхронизацию)
Это метоинформация стрима у которого streams_synchronization параметр был примерно таким - 2046043808 -

General
ID : 0 (0x0)
Complete name : Z14L-1595700189266-1595700203214.ts
Format : MPEG-TS
File size : 1.10 MiB
Duration : 13 h 24 min
Overall bit rate : 192 b/s

Video
ID : 481 (0x1E1)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=25
Codec ID : 27
Duration : 13 h 24 min
Width : 640 pixels
Height : 360 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 482 (0x1E2)
Menu ID : 1 (0x1)
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 2
Format profile : LC
Muxing mode : ADTS
Codec ID : 15
Duration : 13 s 885 ms
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Delay relative to video : 6 ms

В последующих сегментах звуковая дорожка уже отсутствует.

 

[Max]

не помогает - стрим не перезапускается по такой ошибке

это означает, что пакетов, испорченных с точки зрения протокола передачи, в потоке нет.

На новом билде (708)... Получаем ту же самую проблему и на другой камере (16)-

Это заставляет предположить, что проблема может быть в камерах. Проверьте, наблюдаются ли проблемы при проигрывании с этих же камер в VLC.
Также проверьте канал между сервером и камерами, например, при помощи iperf, как описано здесь.
Попробуйте выставить настройку

enable_sync_time_normalizer=true

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

 

[snark13]

это означает, что пакетов, испорченных с точки зрения протокола передачи, в потоке нет.

Но каким образом тогда происходит слом передачи HLS потока ? И почему ?
Пусть в такой ситуации пропадет звук в потоке, но почему начинают выпадать каждый второй сегмент ? (при длительности сегментов в 4 секунды новый сегмент добавляется в плейлист раз в 8 секунд и по нумерации сегментов видно что промежуточные сегменты выпадают (нумерация идет только четными номерами, нечетные отсутствуют). То есть - поток явно становится проблемным и это видно на сервере. В такой ситуации для нас было бы хорошо что бы сервер переустановил коннект к камере (или хотя бы разорвал коннект к ней, а мы получив streamStatusEvent callback со статусом FAILED от сервера пошлем команду перезапустить поток заново)
Сейчас выставил опцию enable_sync_time_normalizer=true - буду смотреть за поведением.
Проблема в том что слом потока происходит с различной периодичностью - может через час-полтора от начала вещания, а может сутки-двое пройти без проблем (но чаще всего от 4 до 10 часов).

P.S. выставление опции не помогло.
streams_synchronization=Z15L/3;Z14L/1895414438;Z15H/-41;Z14H/-20
на вторую камеру (16) в данный момент ссылку выдать не могу, ссылка по первой камере (14) не менялась.

 

[Max]

Но каким образом тогда происходит слом передачи HLS потока ? И почему ?

Проблем с точки зрения самого RTSP протокола в потоке нет. Мы пытаемся воспроизводить проблему с Вашим потоком (поэтому просьба его не закрывать пока). Выглядит так, что в какой-то момент приходит видео пакет с меткой времени, сильно сдвинутой вперед относительно предыдущих, и потом этот сдвиг сохраняется. Это ломает синхронизацию. Мы пытаемся отловить этот момент и понять, в самом потоке проблема или в разборе содержимого пакета.
На HLS проблема проявляется сильнее, так же как и на записи, поскольку в обоих этих случаях есть транскодинг звука PCMA в AAC.
Попробуйте, кстати, для HLS, если Вы отключили транскодинг видео настройками

hls_player_width=0
hls_player_height=0

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

 

[Max]

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

audio_incoming_buffer_size=100

перезапустите сервер и пронаблюдайте, воспроизведется ли проблема снова.

 

[snark13]

Добрый день
поставил эти настройки - наблюдаю...
(включение перекодирования для hls эффекта не возымело - так же получали ситуацию с пропусками сегментов)
до какой величины имеет смысл увеличивать audio_incoming_buffer_size если 100 не поможет ?

 

[Max]

до какой величины имеет смысл увеличивать audio_incoming_buffer_size если 100 не поможет ?

если камера присылает по 100 пакетов видео без аудио, это означает уже проблемы с самой камерой, и, вероятно, надо отключать аудио либо на стороне камеры, либо сервера (мы работаем над фиксом WCS-2812)
в тестах с Вашей камерой мы видели задержку аудио на 30 пакетов относительно видео, так что буфер в 100 пакетов обеспечивает нужный запас.

 

[Max]

В сборке 5.2.714 мы исправили проблему с проигрыванием по HLS RTSP потоков, захваченных по REST API c указанием rtsp в имени потока (WCS-2811), например

curl -H "Content-Type: application/json" -X POST http://localhost:8081/rest-api/rtsp/startup -d '{"uri":"rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov","toStream":"rtspstream"}'

 

[snark13]

пока первая проблемная камера 14 (на которую давал стрим) работает без проблем (но надо понаблюдать дольше)
вторая камера (15) - у нее и с такой настройкой возникает проблема, правда для стримов от нее параметр streams_synchronization при возникновении проблемы принимает значение не 1-2-3 миллиарда а минус несколько десятков тысяч -
streams_synchronization=Z15H/10;Z14H/-20;Z15L/-34130;Z14L/-20

получил разрешение на передачу URL-а на стрим от этой камеры, послал через форму.

 

[snark13]

Проблема сохраняется...
Правда пока не замечал случаев с streams_synchronization=1895414438, но остается проблема (на обеих камерах) с рассинхроном в другую сторону -

streams_synchronization=S14L/-60;S15L/-29770;S15H/-29300;S14H/-20
streams_synchronization=Z14L/-15140;Z15H/-80;Z15L/20;Z14H/-100

Внешне это выглядит аналогично - в HLS пропадает звук и каждый второй сегмент.
Попробую увеличить и параметр video_incoming_buffer_size тоже до 100.