Почему такая скорость передачи RTP?

Бедняга, ты всё ещё его пишешь?

Тебе надо начать с того, что принять с камеры пакеты и аккуратно в CSV сложить микросекунду прибытия пакета и его таймкод.

Задержка с обычной камеры наблюдения настолько стабильна, что легко можно посинкать губы с разных камер (но одинаковых). Кейфреймы сильно жирнее обычных, может быть в 1000 раз разница.

Когда время есть пишу, надо будет вот srtp пакеты делать из avpacket, соединение с браузером есть, dtls согласование прошло.

Дело не в камерах и кфреймах, не пойму почему av_write_frame в сеть может сначала сильно тормозить, а потом вдруг ускоряться на интервалах много больше размера gop, хотя это не точно, завтра сделаю замеры.

В целом вопрос даже не понимаю куда смотреть, так то работает, просто задержка гуляет, а на 10 потоках вижу как ничего не сыпется но видео начинает просто замедляться.

Просто вы кажется говорили что рстп/ртп сервер однопоточный разумный выбор, но похоже для вебртс буду делать отдельный поток на каждый стрим

Какое то профилирование надо сделать, но какое и где…

РКН на пути есть? Они UDP трафик поганят, тот же QUIC просто режут (хотя я даю гарантии что QUIC вытеснит всё остальное со временем вне чебурнета, где его режут даже в пределах одного города), а то что ты видишь похоже на задержки ТСПУ (он сейчас в разрыв стоит, а не в параллель как когда-то давным-давно) когда он пытается понять что через него идёт. А как поймёт, то резать прекращает или совсем режет.

Передача через 1 коммутатор с одноплатника выполняется, камера подцеплена к нему «локально» через вторую сетевку.

Сильно сомневаюсь.

Невнимательно прочитал. Тогда что-то с буферизацией. Либо на самой камере, либо, что более вероятно в коде (читать тоже можно по-разному и буферы есть даже у ОС и библиотек). Некоторые вполне могут быть, даже от того, как он этот лаг определяет. Если практикой, то сам ffplay может быть виновником, если всё-же в коде, то и с Pacing проблемы могут быть и опять с «ffserver» / libavformat у которых свой буфер и с планировщиком ОС.

буферы да… наблюдаю какой прикол - останавливаю чтение с камеры av_read_frame, но соединение не разрываю, делаю какие нибудь движения на камеру, начинаю снова читать гарантированно с нового места в своем кольце - наблюдаю 1-2 секунды видео которое я даже «не читал» )))

Ну так разберись с буферами. Без кода больше ничего сказать не выйдет. Можешь конечно gemeni помучать своим вопросом. Но для деталей код нужен уже. Чтоб смотреть что ты не так делаешь.

иногда мне нужно написать вопрос, чтобы понять что спрашивать ))

итак по сути к коду - нашел первое «тугое» место, вызов ffurl_write пакетами не более 1216 байт (нужно в vpn влазить без дополнительной фрагментации) обычно занимает 0.03 мс (иногда может 1.3мс), НО бывает что проваливается аж до 50мс, с учетом того что вызов этих дофега, то «кадры» писаться могут и 200мс, при этом кадры ЦЕЛИКОМ с камеры поступают НЕ РЕЖЕ чем через 50-60мс

ffurl_write

да кстати буфер указываю 64K, сейчас попробую другие

не ничего не меняется, вот к примеру ОДИН кфрейм отправляется (время вызова в мс / размер в байтах)

SEND UDP 41.282 / 1216
SEND UDP 0.042 / 1216
SEND UDP 0.040 / 1216
SEND UDP 0.031 / 1216
SEND UDP 0.032 / 1216
SEND UDP 0.023 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.031 / 1216
SEND UDP 0.028 / 1216
SEND UDP 0.029 / 1216
SEND UDP 0.028 / 1216
SEND UDP 0.027 / 1216
SEND UDP 0.031 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.024 / 1216
SEND UDP 0.038 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.026 / 1216
SEND UDP 0.026 / 1216
SEND UDP 0.026 / 1216
SEND UDP 0.027 / 1216
SEND UDP 43.748 / 1216
SEND UDP 0.024 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.029 / 1216
SEND UDP 0.030 / 1216
SEND UDP 0.027 / 1216
SEND UDP 0.028 / 1216
SEND UDP 0.028 / 1216
SEND UDP 0.029 / 1216
SEND UDP 0.028 / 1216
SEND UDP 0.026 / 1216
SEND UDP 0.026 / 802

попробовать setsockopt SO_SNDBUF задать, а не буфер ффмпега…

да нет, все правильно rtp://х.х.х.х:52192?pkt_size=1216&buffer_size=524288 задается буфер сокета судя по документации и libavformat/udp.c

решил посмотреть а что же у меня происходит с av_read_frame - так вот если почитать, потом остановиться, подождать любое время и снова начать читать, то ВСЕГДА мне прилетает в начале со скоростью вызова ~0.5мс несколько десятков кадров общим объемом ~1.8Мб, таких буферов я нигде не задаю и в ядре нет.

после прилета этого мусора, чтение дальше происходит штатно со скоростью ~50мс

решило проблему перед началом воспроизведения после паузы av_seek_frame(pFmtCtxInp, 0, INT64_MAX, AVSEEK_FLAG_ANY), ругань libav только в начале чтения каждый раз )

потрать 10 баксов на Opus 4.8, он тебе подскажет и поможет.

У вас есть доступ? Если не сильно нагло с моей стороны и оплата не за каждый запрос можете помочь оценить способна ли она написать код для получения srtp пакетов из avpacket с помощью libav? )

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

Про РКН и udp - давеча на РТК в Самаре столкнулся с удивительными специалистами в их техподдержке - заметил что на моем оборудовании режется вообще весть udp, не замедляется, его просто нет, ни sip, ни stun и тем более vpn Но при этом иногда все работает - оказывается случайным образом сессия может получить белый адрес на конечную железку, а иногда серый - в последнем случае удп нет никакого вообще.

2 недели мне голову морочили на просьбу пробросить трафик мимо ихнего ТСПУ, то к провайдеру ЦОДа в Питере Селектел отправляли с номером какого то ТСПУ, то объясняли что я не понимаю что такое удп, то предлагали на несколько сотен железок купить белые адреса, то в РКН предлагали обращаться чтобы в белый список попасть - в итоге САМИ внесли исправления в правила фильтрации! )))

Гугл аккаунт есть? Если да, то поспрашивай бесплатную версию gemeni. Оно хорошо как раз для того чтоб про что-то узнать или придумать.

Спасибо, попробую

Ну это уже даже не смешно. У тебя проблема твоя собственная, локальная. Как тебе можно помочь с другого окружения?

Именно проблему я уже решил, в целом пока вопрос закрыт, это уже следующее направление - прямая распределённая трансляция без серверов и туннелей.

Давно уже интересно даст ли тот же РТК/ТСПУ (тем более в современных условиях) построить маршрут внутри сети, говорят мобильные операторы блокируют внутри сетевой трафик