Activity

если Йота дает 300 кб/с, то делать видео больше 320х240х15 fps нет смысла изначально.

да, примерно так. но я всё равно верую в светлое будущее мобильного интернета. вдруг ёта лте в Маскве подымит - вот тогда будет счастье
а начинать делать систему управления самолётиком через инет можно сейчас - как раз к тому времени будет готово :)

Если я все правильно понял - при улучшении качества связи - увеличиваем задержку видео?

да не, зачем увеличивать задержку. не вдаваясь в подробности - просто крутим параметры кодека, так чтобы при ухудшении связи терялось качество картинки, при улучшении соответственно улучшалось :) а задержку стараться соблюдать минимальную. есть такое слово rtcp - используется совместно с rtp. чует качество связи, там кол-во потереных пакетов, ждитеры, и всё такое - с его помощью, можно информировать источник о том что надо поменять параметры кодирования. но это уже детали. можно вообще без всякого rtcp делать - просто задать минимально приемлемое качество изображения для кодека, с заведомо подходящим битрейтом и всё

С кодеками - 1% потерь и вы не увидите изображения, пока не придет следующий блок, и опять картинка будет видна пока не потеряется пакет. UDP+Yota=потери, такая формула получена эмпирическим путем 😃
C jpeg каждый кадр идет одним куском, при сбое теряем только один кадр, если в секунду один кадр из 20 или 15 будет теряться мы этого даже не заметим.
Парируйте! 😃

jpeg не идёт одним куском, если он больше mtu, (обычно 1500 байт) 😃

а при сжатии видео 263 кодком, если пропадёт пакет из ключевого кадра то на экране будет небольшой артефакт размером с макроблок, в котором лежал пропавший пакет, длительностью gop_size*frame_duration. а так как ключевые кадры редки, то вероятность этого небольшая. если пропадёт пакет из b-frame или p-frame то артефакта вообще не заметите, его длительность будет frame_duration. в вашем случае неудачный результат скорее всего был связан не с невозможностью передачи сжатого видео через udp, а скорее, не в обиду будет сказано, с неумением это делать. возможно там не всё так просто как может показаться на первый взгляд, но совершенно не означает что невозможно. я видел как такое работает у других с минимальными задержками и без разрушения картинки. значит это возможно 😃

Будет хорошо, если Вы реализуете небольшую программу передающую видео в “реальном” времени с вэбкамеры через интернет с использованием кодека.

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

мабуть начну в следующие выходные. я уже примерно себе представляю как это должно работать. делать планирую на qt, изначально под линупс, но кросплатформено. винды у меня нет. беден. так что если появятся обладатели маков и компов с виндой, желающих присоединиться - велком

Было бы интересно узнать какие кодеки они используют.

скайп испллььзует вроде как 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, там где, полсекунды играют критическую роль, мне кажется, не самое грамотное решение. другое дело поставить это на большой самолётик, с автопилотом, летающим по вейпоинтам, а видио использовать для контроля полёта.

Я так понял с кодеками для этой задачи связываться вообще не стоит.

почему же не стоит? ведь есть всякие интернет телефоны, тот же googletalk и skype. они довольно быстро передают видео по узким каналам. а jpeg-и слать с каждым кадром - слишком хороший канал нужен для приличного качества