roboforum.ru

Да на любом сжатии, кроме mjpeg, будет задержка в 0.2 сек., т.к. для сжатия используются до 10-ти послед. кадров. 1 кадр = 20мс., 10 кадров, соотв. 200мс. Только mjpeg спасает вас, ибо там сжатие делается покадрово...

Добавлено спустя 2 минуты 44 секунды:
А про виртурилку уже и сами разработчики забыли, т.к. это был трэш, угар и содомия
Ti, как обычно, всех поимел...

pdk писал(а):

хотелось бы уберечься от граблей перед покупкой.

тогда не связывайтесь с дешевыми ARM, у Вас же не серия где стоимость критична. Лучше взять что-то с большим сообществом, пускай и дороже ( RP, Odroid,Beagleboard). Либо, еще удобнее, донгл на Atom, а переферию через 5$ maple mini прикрутить.

имхо, orangepi на уровне (по тех характеристикам) с RP, Odroid,Beagleboard ... только дешевле....
а софт - выбор не велик но он , есть и как правило это полноценный линух! со всеми вкусностями! (как и на всех планках более дорогих устройств)

Dmitry__ писал(а):Разве в твоем вопросе не кроется ответ? Да так, чтоб выдать один кадр, надо получить 9 прошлых кадров. Вот и задержка в 0.2 сек.

Так они раньше уже были получены, как в отправителе, так и в получателе, зачем их еще раз получать?

Вот смотри, начинаем работу, первые 9 кадров в отправителе пустые и получатель тоже начинает считая, что первые 9 кадров пустые, теперь берем текущий кадр из предыдущих 9 и нового кадра строим сжатый фрагмент и передаём его в получатель, там по 9 предыдущим пустым кадрам и сжатому фрагменту строим изображение и выдаём.

Следующий кадр строим на 8 пустых, 1 предыдущем и текущем кадре, и так далее.

текущий кадр ему несколько раз дать, будет "близкие по виду"

мы говорим о синхронизации времени воспроизведения кадров для задачи уменьшения задержки. на сколько так её можно уменьшить, уже другой момент.

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

Dmitry__ писал(а):Ню-ню, сжатие видео так не работает. Когда нет близких по виду кадров, сжатие перестает опираться на прошлые кадры.

Прочитал я про MPEG-x / H.26x. Есть такая штука, как GoP ( https://en.wikipedia.org/wiki/Group_of_pictures ), которая определяет порядок работы декодера - все кадры бьются на группы размером в этот GOP, каждый GOP всегда начинается с I-кадра - это стартовый кадр, закодированный независимо от предыдущих. Далее идёт последовательность P-кадров в некотором порядке, каждый из которых может опираться на 1-32 (зависит от стандарта) предыдущих кадров.

Итого - о каких вдруг 10 предыдущих кадрах речь, когда кадры кодируются/декодируются последовательно с опорой только на предыдущие и всегда начинаются с независимого I-кадра?

Dmitry__ писал(а):Я думал вы в курсе такой элементарщины
http://www.texinvest.ru/cctv2/cctv2007.10.09.htm

Статье скоро 10 лет, и написала её какая-то контора, которая видеонаблюдением занимается.
Я уж не говорю, что на этом сайте рекламируется assenizator-v-spb.ru, что тоже не добавляет источнику авторитета

PS: ТС куда-то пропал ))