Комментарии 6
Интересно получилось, и довольно контринтуитивно. Кажется, что кодирование H264 аппаратно ускоряется, и проще его снимать и сразу стримить на серв, попутно впихивая в пакеты данных инфу с GPS и всяких акселерометров. Никогда бы не подумал, что сохранение фоток в jpeg будет оптимальнее. Но практика — критерий истины, как говорится.
Делал в своё время очень тяжелое ПО под реалтайм обработку видео, но на десктопе (кстати там есть возможность писать видео в PNG/JPG сиквенс). Работа с устройствами захвата видео/аудио всегда сопровождалась даже не танцами с бубном, а целым карнавалом. Особенно если это устройства из разных миров (какой‑нибудь SDI Blackmagic, вебкамера и 1394, и все, естественно, снимают в разных форматах — вообще туши свет).
И мне как‑то раньше казалось, что в мобильных ОС учли весь этот опыт, и там должно всё быть как‑то цивилизованнее. В конце концов, там камера является неотъемлемой частью системы.
Но прочитав статью, я понял, что там те же грабли, только потехнологичнее :)
О каком разрешении идет речь?
Лет 10 назад разработал небольшое приложение под Android, которое решает очень похожую задачу: забирает картинки с камеры и записывает их в JPEG-файлы (плюс их таймстемпы). Работало примерно так: один поток, принимая callback от камеры, копировал raw RGB-картинку (или YUV, не помню точно) в промежуточный буфер; другой поток параллельно забирал эти фреймы из буфера, кодировал их в JPEG и сохранял в файлы. Такое приложение на не самых мощных смартфонах тех времен (например на https://ru.wikipedia.org/wiki/HTC_One_Mini), работая с разрешением фреймов 640x480, выдавало от 20 до 30 кадров в секунду. Интересно, что FPS падал из-за низкого уровня освещения: в этом случае камера автоматически выставляла нужную экспозицию, увеличивая выдержку. Но и экспозицию в Android SDK можно зафиксировать, получая в итоге стабильные FPS.
Да, и сохранение в JPEG было сделано просто из-за лени, по идее нужно сжимать кадры в видео при помощи H264 (или H265, AV1), благо аппаратная поддержка кодирования видео встроена сейчас в каждый утюг: так вы получите гораздо более хорошее качество при гораздо меньшем объеме занимаемого места.
Спасибо за интересный комментарий!
Речь идёт о фреймах с разрешением не ниже 1080p - мы сознательно не снижали качество, потому что данные используются для анализа дорожной инфраструктуры (знаки, покрытия, дефекты), где детализация критически важна.
У нас сохранение кадров в JPEG - не из-за лени 😊, а из-за оптимизации под реальные условия эксплуатации. Телефон может работать до 8 часов подряд без интернета, записывая тысячи кадров.
Если снимать всё видео, то:
нагрузка на CPU/GPU резко возрастает - телефон перегревается и быстрее разряжается;
получаются гигабайтные файлы, которые потом проблематично отправлять с полевого устройства, особенно в регионах с нестабильной или отсутствующей связью;
стримить в таких условиях вообще невозможно;
а для анализа нужны отдельные кадры с точными таймстемпами, а не видеопоток.
Поэтому формат JPEG оказался оптимальным балансом между качеством, скоростью, надёжностью и возможностью постобработки в офлайн-режиме.
Я понимаю о чем вы говорите, но я имел ввиду не работать с входным видео-потоком от камеры (который конечно же будет с высоким fps), а просто вместо сохранения N кадров в N *.jpeg файлов сохранять их как единый пакет h264 вместе с метаданными (таймстепами например).
Вообще я согласен, если у вас 4 кадра в секунду, сжимать их при помощи h264 действительно не имеет особого смысла, но кмк начиная с fps 10 и выше использование аппаратного видео-энкодера может иметь преимущество.
Сообщение конечно не по теме топика. Но я даже уже не знаю куда обращаться, саппорт на 2gis (email) не работает, обратная связь по сайту 2gis не работает. Собственно, вопрос один - поддержка оффлайн-карт (баз городов) для ПК заброшена? Г. Москва уже заброшен с конца 2024го, поиск по нему не работает (заблокирован).
Когда важна каждая миллисекунда: оптимизация съёмки для CV и AR