...

До сборки 5.2.1760 RTSP потоки могли долго начинать играть у первого подписчика. Это было вызвано тем, что процесс подписчика стартовал позде процесса публикации, и мог пропускать первые ключевые кадры. В сборке 5.2.1760 это поведение изменено: процесс публикации стартует после процесса подписчика. При необходимости, можно вернуться к старому варинату варианту при помощи настройки

agent_use_subscriber_listener=false_subscriber_listener=false

Исправление временных меток в потоке

В некоторых RTSP потоках временные метки могут идти не в нужном порядке, например, у двух кадров подряд может быть одинаковая метка. При проигрывании такого потока по WebRTC поток может долго не отображаться, и периодически давать серый фон. Для исправления таких временных меток, в сборке 5.2.1794 добавлена настройка

jitter_buffer_attempt_to_correct_broken_timestamp=true

В этом случае в клиентском логе будут сообщения

Non-monotonous timestamp in input stream; previous: 453424, current: 453424; changing to 453425. This may result in incorrect timestamps in the output

и проблемный поток будет играть нормально.

Известные проблемы

...

streams_synchronization=camera1/-21800;camera2/2079600704

Решение:  в сборках до 5.2.1775 увеличить буфер синхронизации для аудио и видео

audio_incoming_buffer_size=100
video_incoming_buffer_size=100

начиная со сборки 5.2.1775 увеличить интервал принудительной синхронизации для аудио и видео

video_force_sync_timeout=1000
audio_force_sync_timeout=1000