может у кого то есть опыт или встречали информацию как можно сделать video streaming базируясь на стандартной офисной сети с latency меньше чем 75 ms
я эксперементирую с NDI меньше 120 ms у меня не получилось

есть вот такая обзорная статья на эту тему
https://www.elecard.com/ru/page/low_broadcast_latency_and_protocols_for_implementation_thereof

Вот с этой статьи можно и начинать. Есть она же, но на английском https://ottverse.com/low-latency-streaming-srt-webrtc-ll-hls-udp-tcp-rtmp/.

Вообще, задача стриминга с задержкой <100 мс весьма нетривиальная. По щелчку пальцев не решается, если не брать готовое решение. Тут может быть очень много подходов и нюансов на всех уровнях, начиная от настройки енкодера и заканчивая выбором протокола вещания. Сложно через форум подсказать. Тут скорее база знаний в компании, опыт и помощь коллег, а также набор утилит в компании могли бы помочь. Лучше к коллегам обратиться. Им будут доступны все нюансы и требования вашей задачи.

В качестве одного из возможных вариантов решения, чисто теоретически, надо посмотреть, какая у вас структура ГОПа. Можно попробовать с ней поиграться. Например, для начала выставить только I-фреймы, и посмотреть, что получится. Ну или просто выставить ее в минимальную длину. Потому как если у вас стандартный пирамидальный ГОП в 10-12 фреймов, то у вас элементарно енкодер будет своим буфером вносить задержку в 4-6 фреймов:


Учитывая ваш делей в 120 миликов, можно предположить, что она как раз берется из стандартных 4х фреймов@25fps плюс на сеть+енкодинг+декодирование+показ

Здравствуйте, sergey2b, Вы писали:

S>может у кого то есть опыт или встречали информацию как можно сделать video streaming базируясь на стандартной офисной сети с latency меньше чем 75 ms
S>я эксперементирую с NDI меньше 120 ms у меня не получилось

Ну, про ГОПы тебе уже рассказали.

В общем и целом, при потере пакетов тебе надо уметь пропускать фреймы. Поэтому TCP тебе совсем не подходит, в основе должен быть UDP. И твой декодер тоже должен уметь пропускать потерянные пакеты в потоке, с разумными последствиями для картинки (т.е., когда картинка замирает до следущего I-frame, это OK, а когда все рассыпается ораньжевыми квадратиками, это не OK).

Будет это самодельный протокол на основе UDP, или какой-нибудь условный WebRTC, вопрос не очень принципиальный.

Я бы взял какой-то Fountain code, лил бы с некоторой избыточностью (степень избыточности — немного выше, чем статистика потерь), организовал бы обратную связь от получателя с целью оценить процент потерь, и при невосстановимых потерях пакетов двигался бы дальше, без перепосылок, ценой дерганья картинки.

Хорошо бы еще сделать динамический битрейт на случай, если сеть очень забита. Но это важнее скорей для медленных сетей, если у тебя проводной гигабит, об этом можно особо не заморачиваться.