Управление через интернет
Будет хорошо, если Вы реализуете небольшую программу передающую видео в “реальном” времени с вэбкамеры через интернет с использованием кодека.
как раз подумывал над этим. тоже хочу себе самолётик с интернетом 😃
жаль времени сейчас совсем нет 😦
ведь если всё делать по уму то не такая уж и небольшая, в плане объёма исходников, програмка получится.
мабуть начну в следующие выходные. я уже примерно себе представляю как это должно работать. делать планирую на qt, изначально под линупс, но кросплатформено. винды у меня нет. беден. так что если появятся обладатели маков и компов с виндой, желающих присоединиться - велком
если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд
то так дела не делаются - не слать же в bmp всё, раз канал позволяет
Тут получается дилемма - забить канал под завязку либо сэкономить немного времени. Делайте, а там посмотрим что лучше, выбор - это есть хорошо! В конце концов это может быть переключатель в финальном релизе.
Добавка:
С кодеками - 1% потерь и вы не увидите изображения, пока не придет следующий блок, и опять картинка будет видна пока не потеряется пакет. UDP+Yota=потери, такая формула получена эмпирическим путем 😃
C jpeg каждый кадр идет одним куском, при сбое теряем только один кадр, если в секунду один кадр из 20 или 15 будет теряться мы этого даже не заметим.
Парируйте! 😃
С кодеками - 1% потерь и вы не увидите изображения, пока не придет следующий блок, и опять картинка будет видна пока не потеряется пакет. UDP+Yota=потери, такая формула получена эмпирическим путем 😃
C jpeg каждый кадр идет одним куском, при сбое теряем только один кадр, если в секунду один кадр из 20 или 15 будет теряться мы этого даже не заметим.
Парируйте! 😃
jpeg не идёт одним куском, если он больше mtu, (обычно 1500 байт) 😃
а при сжатии видео 263 кодком, если пропадёт пакет из ключевого кадра то на экране будет небольшой артефакт размером с макроблок, в котором лежал пропавший пакет, длительностью gop_size*frame_duration. а так как ключевые кадры редки, то вероятность этого небольшая. если пропадёт пакет из b-frame или p-frame то артефакта вообще не заметите, его длительность будет frame_duration. в вашем случае неудачный результат скорее всего был связан не с невозможностью передачи сжатого видео через udp, а скорее, не в обиду будет сказано, с неумением это делать. возможно там не всё так просто как может показаться на первый взгляд, но совершенно не означает что невозможно. я видел как такое работает у других с минимальными задержками и без разрушения картинки. значит это возможно 😃
Ну так уже писали про это. Выигрываем в потоке (его минимизация), проигрываем в лаге и надежности. Проигрываем в потоке - уменьшаем лаг и надежность. 3-го не дано. Или надо использовать кодек с переменной длиной блока и постоянно контролировать линк. Тогда, пока линк хороший, удлиняем GOP, уменьшаем сжатие и улучшаем к-во. А как линк ухудшился, то укорачиваем GOP вплоть до перехода только к i-кадрам (кодек должен это поддерживать) и снижая к-во самого кадра добиваемся хоть какой-то видимости. Оперировать надо длиной GOP, частотой кадров и их разрешением. Примерно так, но а аналоге, работали с луноходом. Ну и мое ИМХО, если Йота дает 300 кб/с, то делать видео больше 320х240х15 fps нет смысла изначально.
пока линк хороший, удлиняем GOP, уменьшаем сжатие и улучшаем к-во. А как линк ухудшился, то укорачиваем GOP вплоть до перехода только к i-кадрам
Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео? А при ухудшении линка начинаем сокращать блоки вплоть до перехода к “JPEGам”. Если учесть, что Yota, а тем более 3G дает линк “критически малого уровня”, то мы и будем сидеть все время на тех самых JPEGах, но с минимальными задержками. При этом немножко увеличим трафик, за счет того что там еще прибавляет кодек к JPEGам.
если Йота дает 300 кб/с, то делать видео больше 320х240х15 fps нет смысла изначально.
да, примерно так. но я всё равно верую в светлое будущее мобильного интернета. вдруг ёта лте в Маскве подымит - вот тогда будет счастье
а начинать делать систему управления самолётиком через инет можно сейчас - как раз к тому времени будет готово :)
Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео?
да не, зачем увеличивать задержку. не вдаваясь в подробности - просто крутим параметры кодека, так чтобы при ухудшении связи терялось качество картинки, при улучшении соответственно улучшалось :) а задержку стараться соблюдать минимальную. есть такое слово rtcp - используется совместно с rtp. чует качество связи, там кол-во потереных пакетов, ждитеры, и всё такое - с его помощью, можно информировать источник о том что надо поменять параметры кодирования. но это уже детали. можно вообще без всякого rtcp делать - просто задать минимально приемлемое качество изображения для кодека, с заведомо подходящим битрейтом и всё
Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео?
Ну да, но улучшаем к-во. Может это и не лучшая идея. Я изначально исхожу из того, что объект управления довольно автономен (есть АП для самика, а если машинка, то она медленно едет). Все равно не идет речь о реальном управлении. Тут скорее некий командный режим. Почитайте как управляют всякими марсоходами и т.п.
Кстати, можно попробовать использовать ЖПЕГ 2000. Он лучше жмет. Ну и многопроходное кодирование. Тогда кадр будет вначале отображаться как-бы полосками, но уже что-то видно, а по мере поступления пакетов будет дополнятся до полной картинки.
На выходных удалось получить кое-какие результаты. Встроил передачу видео посредством JPEG в программу. Такого “ужаса” как с передачей MJPEG через VLC не наблюдается. 😃 Сделал крутилку для регулирования качества jpeg вручную, с базы значение передается на борт, и борт понижает качество изображения. Видео приближенного к реальному времени удается добиться при довольно низком качестве картинки. Не знаю возможно ли будет управлять самолетом в ручном режиме с таким изображением. Еще нужно сделать режим автоматического понижения/повышения качества.
Мне нравится идея с черезстрочным выводом. А что если черезстрочный вывод сделать и по горизонтали и по вертикали? Тогда по идее размер изображения должен уменьшиться в 4 раза?
PS
Чтобы вы получше представляли как это выглядит: дерево можно разглядеть и сказать что это дерево, предполагаю что можно будет разглядеть поле для посадки (изначальная задача), но вот понять какая высота травы - врядли. Впринципе можно сделать передачу качественного снимка местности по нажатию кнопки - присмотрел место для посадки, получил фотографию, оценил - не подходит место (трава высокая), полетел искать дальше.
Такой БПЛА надежнее садить на парашуте.
Такой БПЛА надежнее садить на парашуте.
Я понимаю, да, на парашюте проще всего реализовать, но не лежит душа к такому способу приземления 😃 “не красиво” это!
Еще вариант реализации посадочного режима: по нажатию кнопки открывается два окна - в одном показывается видео в реальном времени с низким разрешением, а во втором 1 раз в 2-3 секунды обновляется изображение 640х480 размером 50-60Кб. На время передачи “качественных” кадров, видео в реальном времени будет останавливаться, эксперименты показывают что на 1 секунду.
Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
Задача сложная, я не спорю, но все-таки это самолет без людей на борту, опасность он представляет для тех кто на земле находится, реально можно не заметить человека на поле. Думаю на таком ЛА не должно быть пропеллеров выступающих за корпус, и посадочная скорость должна быть минимальной в идеале вертикальное приземление.
Даже для большой авиации подбор плошадок с воздуха сложная задача. На это одельный допуск пилоту дается. А вы хотите это по видеокартинке сделать.
Ну посадка пассажирского ЛА и РУ модели это немного разные вещи. Думаю нет ничего невозможного.
Уважаемый топикстартер, можно видео с десктопа, хотелось хотя бы приблизительно оценить качество.
можно видео с десктопа, хотелось хотя бы приблизительно оценить качество.
Я обязательно сделаю видео того как это выглядит со стороны, но не раньше следующих выходных. В скриншоте нет смысла, надо смотреть как это выглядит в движении, так например человек при взгляде из окна с четвертого этажа дома на удалении 100 метров выглядит пятном, только в движении можно понять что это человек, марку автомобиля понять можно, я например разглядел что проехала машина соседа по улице. Еще пробовал подключать аналоговую камеру 540твл через ТВ-тюнер, картинка лучше чем с вэб-камеры Microsoft hd-5000, смазывание при движении меньше. Возможно имеет смысл купить самое дешевое USB устройство видеозахвата и подключить аналоговую камеру.
Извиняюсь, заметил что видео просили, в общем на след. выходных будет.
Возможно имеет смысл купить самое дешевое USB устройство видеозахвата и подключить аналоговую камеру
Думаю дешевле просто сменить объектив у вебкамеры, съэкономите в весе точно
Думаю дешевле просто сменить объектив у вебкамеры
неее, там дело в матрице, желе-эффект и смаз если ее резко двигать, хотя веб камера одна из лучших, но жить можно 😃
Еще кстати автофокус реально мешает, правда его отключить можно.
Поиграл сегодня с видео в Linux купил для этого дела самую дешевую USB 1.1 вэбку за 599 рублей.
Для передачи использовал motion в режиме 320х240 jpeg сжатого с качеством 20%. Передавал через HTTP поверх TCP.
Для отображения использовал браузер Crome постоянно перезагружающий картинку.
В целом результаты таковы.
в 320х240
при сжатии 20% передаваемый поток 85 кб/c задержка 0.3 сек (0,4 на соседнем компьютере)
при сжатии 50% передаваемый поток 120 кб/c задержка 0.3 сек (0,4 на соседнем компьютере)
В обоих случаях качество картинки довольно удовлетворительное. Похоже на обычный аналог переданный через эфир.
В принципе летать сложно но можно.
Думаю в сторону следующих улучшений.
Передача через UDP.
Своя программа для просмотра картинки с отрисовкой через OpenGL.
В целом результаты таковы. в 320х240 при сжатии 20% передаваемый поток 85 кб/c задержка 0.3 сек (0,4 на соседнем компьютере) при сжатии 50% передаваемый поток 120 кб/c задержка 0.3 сек (0,4 на соседнем компьютере)
Не плохо, и подход научный 😃
у меня все более на глазок
Я только не понял - видео передавалось по сети или на самого себя? Если на самого себя - 0.3 сек многовато. Попробуйте развернуть на полный экран, как оно, с точки зрения полетов? В маленьком окошке все кажется лучше чем оно есть 😃 В мобильном интернете скорость будет не постоянной, там нужно на лету менять параметры качества видео. Вчера вечером с этим поэксперементировал, в принципе получается, но надо еще тестировать/оптимизировать.
На фото передача на самого себя, через удаленный комп (пинг до которого ~12 мс) задержка больше на 0,1 сек. Но это используя HTTP и браузер в качестве клиента.
Если одна шабашка мимо пролетит и будет свободное время, попробую сварганить передачу на UDP с выводом программой через OpenGL. О результатах доложусь.
А вот со скростью похоже ошибочка сейчас пришел домой посмотрел на скрины, ну мало как то 85 кБ/с, это похоже скорость не в килобитах, а в килобайтах, соответсвенно это 680 кб/с? Приду на работу проверю точно. Просмотрел я это как то. (кстати я использовал 24 кадра в секунду).
Так что соответственно вопрос о чересстрочной развертке остается в силе. Кстати делать чересстрочку и по горизонтали и по вертикали не советую, получается что кадр полностью обновится только через 4 четвертькадра, при 20 четвертькадрах это 0,2 секунды многовато как то. Может лучше полукадрами но не чересстрочной разверткой а в шахматном порядке пиксели слать, это сразу сгладит расческу оставив полное обновление картинки за 2 полукадра.
Вопрос в том насколько увеличит время обработки такая выборка, стоит ли овчинка выделки в конце концов можем прийти к тому от чего пытаемся уйти - увеличим задержку =(
Вопрос в том насколько увеличит время обработки такая выборка, стоит ли овчинка выделки в конце концов можем прийти к тому от чего пытаемся уйти - увеличим задержку
Я думаю это будет происходить мгновенно - повыкидывать через один пиксель из битмэпа. Надо пробовать и смотреть что получится, если из битмэпа выкинуть пиксели, а затем то что получилось перегнать jpeg, и вывести вперемежку с предыдущим кадром.
Кстати если с такой системой резко перевести камеру с черного на белое, получится забавная сеточка. 😃
Сомневаюсь, что jpeg это простит… Во всяком случае исходное качество кадра из двух полукадров вряд ли получится… (правда и сожмет значительно больше чем в 2 раза). имхо.