Управление через интернет
Я так понял с кодеками для этой задачи связываться вообще не стоит.
почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
тот же googletalk и skype
Было бы интересно узнать какие кодеки они используют.
а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
По моим экспериментам качество изображения получается приемлемое для управления (на мой взгляд), я еще не весь потенциал оптимизации использовал 😃 Наслаждаться 1080p 60fps, конечно не выйдет, но оценить курс куда лететь/ехать/ползти/бежать и т.д. и т.п. 😃 можно. До начала практических работ c JPEGом, мне эта тема казалась вообще бесперспективной, но на практике все оказалось не так плохо. То “видео” из JPEGов, которое я вчера передавал, временами было очень близко к реальному времени, но с периодическими достаточно частыми подвисаниями на 1-2 секунды. Кстати не исключено что skype использует что-то такое.
почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества
-Stas- прав, здесь есть противоречие, для того чтобы добиться максимального качества при минимальном битрейте почти все кодеки (и скайп с гуглом тоже) используют межкадровую компрессию, сжимают не отдельные кадры, а блоки по 5-10 кадров. Для этого им необходим буфер из нескольких кадров, в результате задержка. В видеоконференции задаржка 0,5 - 0,7с ничего не значит. в FPV она критична.
Думаю действительно стоит отказаться от стандартных кодеков и пробовать сделать что то самому.
Было бы интересно узнать какие кодеки они используют.
скайп испллььзует вроде как vp7
гуглтолк h264 и h263, хотя оне с недавных пор 264 невзлюбили, перестают поддерживать и заменяют на vp8. скорее всего по политическим пичинам.
лучше всего использовать h263 - он разрабатывался специально для передачи по слабым каналам. 264 конечно лучше, но он проц сильно грузить будет при кодировании, а дял бортового компа это критично.
и ещё. видеопоток стоит предавать конечно по udp. для преодаления nat можно использовать протокол stun. но данные надо бы завернуть в какой нибудь предназначеный для этих целей протокльчек. по уму - в rtp. не будет проблем с неправильным порядком пришедших пакетов, и совместно с используемым вместе с ним протоколом контроля передачи можно будет регулировать параметры кодека - фреймрейт, размер гоп структуры, разрешение, чтобы видео при проседании канала не замирало, а просто ухудшало качество, и потом восстанавливалось при улучшении связи
да, и програмиовать бэкэнд, по крайней мере, лучше на каком нить другом языке. умные люди такое делают на си. ленивые на с++. а на языках с jit и garbage collector только смелые экспериментаторы 😃
это хорошо, конечно что канала у ёты для передачи jpeg-ов хватает, и возможно для эксперементов этого достаточно. но если смотреть на будующее, то так дела не делаются - не слать же в bmp всё, раз канал позволяет 😃 надо расчитывать что мобильный инет не такая надёжная штука, и не везе стабильно работает. и лучше стремиться к максимальному качеству изображения при доступной ширене канала
-Stas- прав, здесь есть противоречие, для того чтобы добиться максимального качества при минимальном битрейте почти все кодеки (и скайп с гуглом тоже) используют межкадровую компрессию, сжимают не отдельные кадры, а блоки по 5-10 кадров. Для этого им необходим буфер из нескольких кадров, в результате задержка. В видеоконференции задаржка 0,5 - 0,7с ничего не значит. в FPV она критична.
Думаю действительно стоит отказаться от стандартных кодеков и пробовать сделать что то самому.
дык любой кодек может использовать только i-фреймы 😃 если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд, а данные доступны для отправки раньше прихода следующего ключевого кадра. задержка не в этом. в цепочке передачи видео от камеры, через интернет, до монитора довольно много всяких буверов, в которых задержка накапривается, я в принципе представляю себе где там что и как, но, как мне кажется, слать жпеги - всё равно не лучший вариант
да. лаги в любом случае будут. и использовать инет для fvp, там где, полсекунды играют критическую роль, мне кажется, не самое грамотное решение. другое дело поставить это на большой самолётик, с автопилотом, летающим по вейпоинтам, а видио использовать для контроля полёта.
любой кодек может использовать только i-фреймы если даже гоп-структуру зделать размером 4 кадра всё равно будет ощутимый прирост в степени сжатия, и это всего 100 милисекунд, а данные доступны для отправки раньше прихода следующего ключевого кадра.
Будет хорошо, если Вы реализуете небольшую программу передающую видео в “реальном” времени с вэбкамеры через интернет с использованием кодека.
Так если Вы уже пользуете DirectShow стройте граф с любыми кодеками, установленными в системе… Даже проще чем самому в jpeg перегонять…
Так если Вы уже пользуете DirectShow стройте граф с любыми кодеками, установленными в системе… Даже проще чем самому в jpeg перегонять…
Возможно… Я в сторону использования кодеков там не смотрел, и если loigray в этом не плохо разбирается, я не против доверить это ему. А я пока посмотрю что там с jpeg может получиться.
Будет хорошо, если Вы реализуете небольшую программу передающую видео в “реальном” времени с вэбкамеры через интернет с использованием кодека.
как раз подумывал над этим. тоже хочу себе самолётик с интернетом 😃
жаль времени сейчас совсем нет 😦
ведь если всё делать по уму то не такая уж и небольшая, в плане объёма исходников, програмка получится.
мабуть начну в следующие выходные. я уже примерно себе представляю как это должно работать. делать планирую на 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 сек многовато. Попробуйте развернуть на полный экран, как оно, с точки зрения полетов? В маленьком окошке все кажется лучше чем оно есть 😃 В мобильном интернете скорость будет не постоянной, там нужно на лету менять параметры качества видео. Вчера вечером с этим поэксперементировал, в принципе получается, но надо еще тестировать/оптимизировать.