Управление через интернет
Парни, Максим, Александр. А может ну его JPEG? Картинка же маленькая, глубина тоже не большая. Нафига все это ужимать аццкой математикой да еще и с потерей качества, которого и так нет?
По моим подсчетам, если считать что Yota обеспечивает 400Кбит/сек на отправку, это получается 50КБайт/сек. При 20 кадрах в секунду, каждый кадр должен иметь размер не более 2.5КБ. Довольно сложно вписаться в такие жесткие ограничения. Вот если появится LTE у большой тройки операторов… У Yotы задержки pinga 200мс, плюс пока кадр закачается, отсюда и задержа от 0.5 сек. В общем видео на выходных сделаю, посмотрите, скажите можно ли с этим жить. Надо еще потестировать, отладить, баги поймать, и не плохо было бы начать изучать вопрос получения текущих GPS координат с какого-либо GPS модуля.
Уважаемый товарищ Легион, заканчивайте тролить и уйдите пожалуйста из темы, ваше мнение тут все поняли и приняли.
Здесь ОБСУЖДАЮТСЯ конкретные идеи, разработки и предложения, а Вам правило “критикуя - предлагай” похоже не знакомо.
Доделал собственный захват картинки с вебки через v4l2 драйвер, и сжатие ее в памяти при помощи libjpeg сегодня попробую сделать отправку через UDP. По идее обработка чуть шустрее должна получиться. Максим выложите пожалуйста формат команд для управления качеством картинки. Попробуем совместимым модуль сделать. =)
Попробуем совместимым модуль сделать.
Так я отправляю параметры видео на борт:
// jpeg quality
sendCommand(“25=” + trackBarVideoQual.Value.ToString());
// fps
sendCommand(“26=” + tbFPS.Text);
Так я получаю jpegи с борта:
Byte[] frame = udpClientVideo.Receive(ref VideoEndPoint);
Появился похожий проект (приз от гyглa 30М$) - передача картинки с луны.
Собираются передавать mjpeg2000, исходник кодера на С тут.
Появился похожий проект (приз от гyглa 30М$) - передача картинки с луны. Собираются передавать mjpeg2000, исходник кодера на С тут.
Я думаю, самое сложное там - ракета. 😃 Спасибо за ссылку.
PS
Всего то 500 метров там проехать надо и фотки на землю скинуть…
FPS колебалось в районе 5-6 кадров в секунду, задержка видео около 1 секунды.
В дальнейшем необходимо поработать над снижением размера кадров, сейчас размер кадра 6-10Кб, требуется снизить до 2.5 КБ.
Всего то 500 метров там проехать надо и фотки на землю скинуть…
Когда слетаете? Там ведь всего ничего делов )))
В дальнейшем необходимо поработать над снижением размера кадров, сейчас размер кадра 6-10Кб, требуется снизить до 2.5 КБ.
А какой размер передаваемого кадра? Мне кажется, что изображение сильно хорошего к-ва. Лучше хуже к-во, но более плавно и меньше лаг. Хотя лаг от этого не зависит.
И еще. Надо искать камеру с ССД матрицей. У этой жуткий желе-эффект.
А какой размер передаваемого кадра? Мне кажется, что изображение сильно хорошего к-ва. Лучше хуже к-во, но более плавно и меньше лаг. Хотя лаг от этого не зависит. И еще. Надо искать камеру с ССД матрицей. У этой жуткий желе-эффект.
Размер 320х240. На записи изображение выглядит несколько лучше, чем живьем, но если увеличить FPS будет вполне сносно 😃 Качество jpeg уменьшать не стоит, на видео качество 15%. Увеличить FPS до 15-20 - это реально, действия по увеличению FPS скорей всего приведут и к снижению лага, но я хочу заняться GPS, мне это сейчас интересней.
Камера у меня есть - аналоговая 540Твл, безкорпусная, такая как у многих здесь, картинка с нее НАМНОГО лучше если ее подключить через PCI ТВ тюнер, я хочу попробовать ее подключить через USB устройство захвата.
В дальнейшем необходимо поработать над снижением размера кадров, сейчас размер кадра 6-10Кб, требуется снизить до 2.5 КБ.
- Попробуйте чорно белую картинку
Уже пробовали сравнивая объем сжатого статичного файла. Разница не больше 20%.
- Попробуйте чорно белую картинку
Уже пробовали сравнивая объем сжатого статичного файла. Разница не больше 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 разница.
Надо спеки на МЖПЕГ поискать. Может прояснится.