Управление через интернет
- Попробуйте чорно белую картинку
Уже пробовали сравнивая объем сжатого статичного файла. Разница не больше 20%.
Вообще на приземлении каждый процент будет на счету, можно и в ч/б режим перейти. Не стоит разбрасываться драгоценными процентами, тут 20% плюс там 30%, глядишь а это уже в 2 раза 😃
Вот смотрите:
- Делаем ресайз картинки (вертикальная+горизонтальная черезстрочка) - где-нибудь раза в 4 объем уменьшим;
- Отрезаем сверху и снизу по куску изображения, получается 16:9 - еще где-то в 1.5 раза уменьшаем;
- Делаем ч/б (будет кнопка вкл/выкл) - еще процентов на 20 а может на треть.
Итого выходит - неплохо 😃
Идея с черезстройчкой, как вы ее видите ИМХО не годится. Смысл горизонтальной черезстрочки в ТВ уменьшить необходимую полосу пропускания при этом не ухудшив видимость, а заодно увеличив плавность картинки. На аналоговом ТВ нет гребенки, т.к. он показывает сначала 1-е полуполе, а потом 2-е. При этом изображение “суммируется” в глазу. Смысла делать интерлайс в цифре я не вижу. Вы этим поток не уменьшите. Особенно если речь идет о нарезке картинки на несколько блоков по горизонтали и вертикали. Если блок не пришел, то читаемость картинки безвозвратно ухудшается. Если уж на то пошло, то можно сделать картинку типа 240*180 (В*Ш), а пиксель прямоугольный, а не квадратный. Посмотрите с каким разрешением записаны пиратские ДВД 10 в 1. Там именно так.
Относительно 16/9, так никто не мешает и в полете такую картинку юзать. Что там особо рассматривать в воздухе. Да и камеру можно просто крутить микромашинками, если хочется посмотреть вверх/вниз.
По ч/б мне кажется идея не годится. Резко падает различимость предметов. Вкупе с невысоким динамическим диапазоном картинки мы получим резкие тени и будет сложно понять высоту неровностей и т.п. Почитайте воспоминания водителей луноходов. Они отмечали этот недостаток. Правда у них было всего кажется 8 градаций серого в картинке.
Уже пробовали сравнивая объем сжатого статичного файла. Разница не больше 20%.
У меня при использовании серого от 30% до 50% размер уменьшается. Так что смысл имеет.
Смысл горизонтальной черезстрочки в ТВ уменьшить необходимую полосу пропускания при этом не ухудшив видимость, а заодно увеличив плавность картинки. На аналоговом ТВ нет гребенки, т.к. он показывает сначала 1-е полуполе, а потом 2-е. При этом изображение “суммируется” в глазу. Смысла делать интерлайс в цифре я не вижу. Вы этим поток не уменьшите.
Можно снизить разрешение передаваемой с борта картинки до 160х120 с последующим увеличением на базе до 320х240, можно попробовать смешивать через строку/столбец с предыдущим кадром, и смотреть что лучше. В каждый момент времени на базе будет выводится полный кадр. При этом трафик совершенно точно снизится. Качество тоже потеряется, нужно смотреть на сколько.
Напомню: задача увеличить FPS, возможно за счет снижения качества картинки.
У меня при использовании серого от 30% до 50% размер уменьшается
Видимо зависит от картинки. Я сравнивал объемы файлов после сжатия в Фотошоп. К-во ЖПЕГ ставил на 3. Конвертировал в ЧБ тоже ФШ. В зависимости от кадра получалось от 20 до 25% в зависимости от исходника.
Можно снизить разрешение передаваемой с борта картинки до 160х120 с последующим увеличением на базе до 320х240
Не вижу смысла. Вы этим к-во не улучшите. Если уж передается мелкий кадр, то лучше так его и отображать. Попробуйте вариант прямоугольного пикселя. Так и разрешение снизится и к-во упадет не так сильно. Просто для глаза не одинаково важно горизонтальное и вертикальное разрешение.
можно попробовать смешивать через строку/столбец с предыдущим кадром, и смотреть что лучше
Зачем эти эксперименты. Есть стандартные способы сжатия видеопотока. Все уже опробовано солидными НИИ при разработке цифрового ТВ. Можно не тратить время, а использовать готовое.
Объясню почему не вижу смысла использовать т.н. интерлайс (разложение по строкам), как в аналоговом ТВ. Допустим вы передаете 10 к|c разрешением 320*240 и каждый кадр весит 10 кб. Т.е. поток составит 100 кб/с.
Если использовать интерлайс, то вам надо передать не 10 полных кадров за сек., а 20 полукадров размером соотв. 320*120. Каждый кадр будет весить примерно половину исходного, т.е. 5 кб. В итоге потребный поток 20*5=100 кб/с. Кроме того интерлайсное отображение работает только на скоростях от 24 к/с и выше, т.к. иначе полукадры не будут складываться в глазе.
Напомню: задача увеличить FPS, возможно за счет снижения качества картинки.
А смысл? Ну получите вы плавное изображение, но полную мазню по к-ву. Для управления машинкой возможно так и лучше, т.к. до препятсвий близко, но для ЛА не вижу смысла. Основное управление делает АП. Относительно возможности “штурвальной” посадки данного ЛА вы уже мое мнение слышали.
З.Ы. Как идет процесс снюхивания с ЖПС?
P.S.S. Надо учитывать, что в поле как приемная таки передающая станции будут работать через мобильный инет, т.е. к-во связи будет хуже. Дома то у Вас 1 комп подключен к выделенке.
Как идет процесс снюхивания с ЖПС?
Еще пока никак не идет 😃 немного ознакомился с этим вопросом, исходники нагуглить можно, еще надо подобрать сам GPS приемник.
Можно снизить разрешение передаваемой с борта картинки до 160х120 с последующим увеличением на базе до 320х240
Не вижу смысла. Вы этим к-во не улучшите. Если уж передается мелкий кадр, то лучше так его и отображать.
Да, в этом смысла нет. Возможно “смешиванием” с предыдущим кадром, получится несколько снизить потерю качества.
Меня все время не отпускает мысль, что мы не первые думаем над этой проблемой, и скорее всего до нас были и те кто разбирается в вопросе лучше нас. Может поискать в интернете готовые методы снижения битрейта видеопотока без межкадровой компрессии?
Насколько помню, в большинстве кодеков есть возможность задавать макс. период ключевого кадра. Но непосредствено увеличение этого времени не должно влиять на задержку. Задержка будет до ближайшего ключевого кадра только если при передачи начнут теряться дельта-кадры.
Зачем эти эксперименты. Есть стандартные способы сжатия видеопотока. Все уже опробовано солидными НИИ при разработке цифрового ТВ. Можно не тратить время, а использовать готовое.
Меня все время не отпускает мысль, что мы не первые думаем над этой проблемой, и скорее всего до нас были и те кто разбирается в вопросе лучше нас.
+1. Все кодеки ( а над ними работали серьезные инженеры, математики, программеры) в принципе заточены под ту же задачу -максимально уменьшить битрейт при наилучшем психофизиологическом восприятии картинки. Не всегда правда они заточены под реал-тайм видеопоток, но наверняка можно найти что-то подходящее. Тоже советую не тратить время на изобретение своего кодека (слишком мала вероятность получить что-то “конкурентоспособное”), а поизучать возможности того, что уже есть.
ЗЫ Помню свой опыт по разработке мп3-подобного кодека (занимался так… от скуки…) Преселекция, БПФ, издевательство над спектром, обратный БПФ, жуткий геморрой по состыковке фреймов покалеченных после изменения исходного спектра, обратная преселекция. В итоге вот он чистенький звук… Но после сравнения с мп3, понял что получилась полная фигня…
Так выше уже писали, что какая-то из команд учавствующих в Лунар Х-прайз от гугл будет использовать МЖПЕГ.
какая-то из команд учавствующих в Лунар Х-прайз от гугл будет использовать МЖПЕГ
Интересно почему они выбрали MJPEG, а не просто JPEG…
Я сейчас почитал по тем ссылкам. раньше я не читал. Там вообще вроде ЖПЕГ 2000 будет. Он лучше жмет, чем обычный и меньше квадратит. типа как мр4 и Н.264 разница.
Надо спеки на МЖПЕГ поискать. Может прояснится.
Интересно почему они выбрали MJPEG, а не просто JPEG…
Вполне стандартный и примитивный видео кодер. Хотя, слово примитивный я бы не стал относить к JPEG 😃
MJPEG - всего навсего еще один формат для потоковой передачи видео (Motion JPEG).
ЗЫ: Меня что то тоже тема зацепила, интереса ради попробовал собрать библиотеку mediastreamer2 с поддержкой видео. Под Win32 собрать эту штуку - реальный секас 😃 зато, в совокупности с библиотекой ffmpeg можно воспользоваться практически любым кодеком для кодирования/декодирования видео и передачи его по RTP.
Хотелось бы еще заметить, что задача передачи потоковой информации в режиме, максимально приближенному к realtime’у, не столь проста как кажется и передачей голых UDP пакетов с данными тут не обойдешься. Сеть и протокол UDP не дает никакой гарантии доставки пакетов до конечной точки, также не гарантируется доставка UDP пакетов в том порядке в котором они были посланы, временные задержки между пакетами могут плавать и разительно отличаться от той частоты с которой они были посланы. Именно по этому был разработан протокол RTP который исправляет все “недостатки” передачи UDP пакетов по сети, разумеется кроме гарантии доставки до конечной точки.
Использование временных меток в протоколе позволяет корректно обрабатывать их принимающей стороной, отбрасывать слишком старые, буферизировать новые и выдавать пользователю информацию в режиме реального времени.
Доделал собственный захват картинки с вебки через v4l2 драйвер, и сжатие ее в памяти при помощи libjpeg сегодня попробую сделать отправку через UDP.
Очередной велосипед 😃 ну не понимаю я зачем писать что то свое, когда можно изучить то, что уже есть и прекрасно работает.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
Если кому интересно как завести mediastreamer2 под win - могу написать туториал.
Интересно! Но не обещаю что сразу начну разбираться с mediastreamer2, сейчас вечерами разбираюсь с GoogleEarth 😃
Кстати что думаете на счет использования GoogleEarth для этого проекта? Тогда для работы программы будет необходима установка GoogleEarth.
Кстати что думаете на счет использования GoogleEarth для этого проекта? Тогда для работы программы будет необходима установка GoogleEarth.
Честно говоря, я ни бум бум в этом Earth. А каким местом его хотите прикрутить, как использовать ?
Вобщем, поскольку работа у меня немного связана с VoIP, по большей части с voice, но видео тоже захотелось попробовать. Вобщем, сляпал на скорую руку peer2peer прогу для передачи видео на основе исходов и примеров mediastreamer’a. Используемый кодек H.263, библиотеку mediastreamer собрал без поддержки directshow и directsound, так что вся отрисовка - софтварная посему и тормоза.
Весь релиз выкладывать не буду, слишком много мегабутесов кодеки весят.
Сами кодеки (dll) можете скачать тут.
Распаковываете скачанный 7z архив, из директории bin копируете все dll файлы в папочку где находится ‘rtpvideo’.
Релиз сборка rtpvideo прилагается. Как пользоваться - читаем readme.txt.
А каким местом его хотите прикрутить, как использовать ?
GoogleEarth можно использовать в своих приложениях для отображения текущего местоположения по GPS координатам и создания путевых точек.
Релиз сборка rtpvideo прилагается.
Ок, попробую.
GoogleEarth имхо требуется онлайн, и приличный трафик. Там конечно что-то как-то кэшируется, не разбирался. Но для своей рабочей станции использую jpeg-и из этой проги с координатной привязкой и свой движок изобретаю помаленьку. А то ведь фиг его знает- чужая прога потемки… а мне ведь надо еще и гарантировано видео успевать писать без дропов. И все на слабеньком ноуте…
Интересная тема. Но все-таки не очень понятно, зачем управлять по видео(и мучиться с его передачей в реалтайм), если это можно делать по телеметрии, а видео транслировать уже просто для интереса/дополнительного контроля.
Насчет проги гугла - там есть 3д режим “полетов”, если научиться передавать в него данные с телеметрии, можно “летать” по 3д карте, а не по видео. При этом важно, что в самой программе можно будет дорисовать полигонами ключевые объекты и сложные места полета, которых нет на изображении или нет в 3д(деревья/здания/линии ЛЭП), в идеале создав полную функциональную копию места полетов в 3д.
Нужно только будет решить вопрос с максимально точным определением высоты модели для нормального взлета/посадки/облета препятствий.
Но все-таки не очень понятно, зачем управлять по видео
Мне интересней иметь возможность управления и наблюдения с борта реалтайм, чем просто смотреть на точку на экране и льющийся поток цифр.
В Гугл Земля, насколько я понял можно еще получать высоту точки над уровнем моря, что тоже может быть интересным, вот только вопрос как надежно определить высоту, на которой летит модель… (P.S. про холмы, постройки, кусты - это я все понимаю 😃)
вот только вопрос как надежно определить высоту, на которой летит модель…
Бародатчик + ультразвуковой дальномер
Высота в Гугл Ирф весьма примерна. Я бына нее не расчитывал. Определение высоты эхолокацией не годится. Во первых я сомневаюсь, что этот метод приемлим для расстояний больше 5-10м, а во вторых звук распространяется относительно медленно, а модель летит быстро. Пока посланный к земеле импульс вернется обратно модель может улетет от этой точки. Это если даже есть эхолотные дальномеры на большое расстояние (50-100м). Тут надо мерить радтовысотомером. Ну может лазерный пойдет.
Насколько я знаю, для моделей кроме бародатчика и/или GPS, других способов измерения высоты пока не придумали.
Может что-то еще и есть, но или небюджетно, или некомпактно. “Малогабаритный авиационный радиовысотомер” судя по Гуглу, весит килограмм.