мобильная платформа с vfp на orange pi

Vooon

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

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

Dmitry__

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

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

Ti, как обычно, всех поимел...

=DeaD=

Dmitry__ писал(а):

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

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

Romikgy

pdk писал(а):

Цитата:

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

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

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

Dmitry__

=DeaD= писал(а):

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

Разве в твоем вопросе не кроется ответ?

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

=DeaD=

Dmitry__ писал(а):

Разве в твоем вопросе не кроется ответ?

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

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

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

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

Dmitry__

=DeaD= писал(а):

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

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

=DeaD= писал(а):

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

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

Я думал вы в курсе такой элементарщины

http://www.texinvest.ru/cctv2/cctv2007.10.09.htm

Цитата:

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

Angel71

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

Dmitry__

Angel71 писал(а):

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

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

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

Angel71

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

Dmitry__

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

Angel71

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

Dmitry__

Да я дал ссылку на обьяснялки. :shock:

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

=DeaD=

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

))

Angel71

Dmitry__, т.е. за меня уже решил, чем заниматься в ближайшее время.

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

roboforum.ru

мобильная платформа с vfp на orange pi

Кто сейчас на конференции