r
Это от физики работы зависит. Обычно так делают для согласования скоростей источника и приёмника, если источник "заткнуть" нельзя
Size: a a a
2021 January 13
ВЯ
если критично по скорости - два буфера, один передаем, в другой читаем, переключаемся и так до конца
r
В том-то и дело, tcp гарантирует доставку, но не ширину полосы
r
Это как usb bulk - то же подтверждение есть, а когда данные будут доставлены - неизвестно
ВЯ
ну изображения обычно слишком большие, и даже 200кб+128кб - мало будет, ..разве что маленькие...но я лично смысла не вижу в таких плясках
VB
Вопрос - нафига вам куча?
Та могу в статическую, могу в кучу. Для моей цели без разницы
VB
Василий Ярошенко
да, на лету
А не потеряю ли я байты изображения на лету?
ВЯ
нет, куда же они потеряются
ВЯ
для передачи - это будет выглядеть как сплошной поток данных
r
Ну вот со звуком (и прочими потоками) это не прокатывает
r
У камеры, возможно, есть своя память
r
А так - изволь буфер на (скорость потока*максимально допустимое время затыка сети)
r
А не потеряю ли я байты изображения на лету?
Потеряешь конечно
r
При определённых условиях
VB
Я не совсем понимаю, как это должно выглядеть
Ведь мне камера шлёт поток данных, остановить на время который я не могу
Ведь мне камера шлёт поток данных, остановить на время который я не могу
r
RTT большое - tcp окно маленькое в стеке - всё, приплыли
r
Т.е. в локалке с маленьким буфером будет работать, а в интернете - нет
VB
Хотя камера тактируется от МК. Возможно получится на время переставать тактировать, отправлять кусок данных по tcp и снова тактировать 🤔
r
Я не совсем понимаю, как это должно выглядеть
Ведь мне камера шлёт поток данных, остановить на время который я не могу
Ведь мне камера шлёт поток данных, остановить на время который я не могу
Ну тогда это типичный поток
r
Хотя камера тактируется от МК. Возможно получится на время переставать тактировать, отправлять кусок данных по tcp и снова тактировать 🤔
Перестал тактировать - перестала снимать, не?