Управление через интернет
Когда-то баловался передачей видео по сети DirectShow+UDP. Тестовая программулька где-то осталась в BCB, если хотите (ну там кодеками поиграться…) могу поискать, скинуть с исходниками.
Когда-то баловался передачей видео по сети DirectShow+UDP.
Какие у вас были результаты? Какого FPS удалось добиться, при каком разрешении? Какая задержка была, насколько пригодно для FPV в реальном времени?
DirectShow+UDP
Я сейчас тоже использую эту связку и приятно удивлен скоростью, если с VLC при передаче видео с компа на самого себя уже возникала задержка около секунды, то тут ее практически нет.
Проект начинался для видеоконференции в локалке, но умер не родившись по независившим от меня причинам… В приципе комп-комп все работало дуплексом без проблем в 100мб-сетке (ну еще бы… 😃). От разрешения и выбранного кодека изменялась только загрузка сети. Задержки в большей степени зависили от кодека и его настроек… У Вас несравнимо более сложная задача и по требованиям к задержке, и по ширине да еще и нестабильности канала…
От разрешения и выбранного кодека изменялась только загрузка сети
Я так понял с кодеками для этой задачи связываться вообще не стоит.
сложная задача и по требованиям к задержке, и по ширине да еще и нестабильности канала
Вчера поигрался с качеством JPEG, погонял видео с вэбкамеры через Yotу, в общем есть неплохие шансы на более-менее успешное завершение проекта.
Я так понял с кодеками для этой задачи связываться вообще не стоит.
почему же не стоит? ведь есть всякие интернет телефоны, тот же 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 секунду.