roboforum.ru

На виртурилке кадры с сенсора забирает видеоядро без участия ЦП.
Все что остается сделать процессору, это упаковать поток в RTP и выплюнуть через сеть.

Я пытался написать свою прошивку для модуля IP камеры на DM386.
Запустил openwrt, но застрял с dvsdk, а потом эти модули сняли с производства, так что проект умер.
Сейчас уже предлагают h265, но чипы от hisilicon меня отпугивают (да и огорожены).

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

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

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

Разве кодек не так работает, что просто при сжатии текущего кадра опирается на 10 предыдущих?

pdk писал(а):

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

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

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

=DeaD= писал(а):Разве кодек не так работает, что просто при сжатии текущего кадра опирается на 10 предыдущих?

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

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

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

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

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

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

Чтоб получить ранее полученный кадр, надо получить еще более ранние кадры

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

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

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

Т.е. проще говоря – стандарт Motion-JPEG обеспечивает наименьшую величину времени между реальными съемками и отображением оцифровки на мониторе.

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

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

Мы говорим про сжатие или про приколы нашего городка?

Любая фильтрация/сжатие построенная на прошлых данных имеет задержку, я сказал, хватит об этом

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

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

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

Да я дал ссылку на обьяснялки.
Хорошо, ждем реализацию кодека от Angel71 на "небольших квадратиках", сжатие как у современных кодеков, задержка как у mjpeg...

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: ТС куда-то пропал ))

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