Быстрее, более эффективное преобразование JPEG и сжатие на iPhone

Я захватываю кадры с камеры iPhone со скоростью 25 кадров в секунду с разрешением 192 x 144 и 420v, формат BGRA.Быстрее, более эффективное преобразование JPEG и сжатие на iPhone

Я преобразовываю CVImageBufferRef s в UIImage s, а затем вызывая UIImageJPEGRepresenation(image, compressionQuality), чтобы получить сжатую JPEG-версию изображения.

Использование Time Profiler в инструментах, я вижу, что 75% моего времени процессора тратится на получение изображения JPEG изображения, что замедляет работу с другими операциями, которые мне нужно выполнить в приложении.

Это немного колеблется, затрачивая меньше времени, если я установил сжатие в 1.0 (то есть без сжатия) и потратил больше, если я установил его на 0.0 (то есть полное сжатие).

Есть ли более эффективный способ получить JPEG-изображение изображения с камеры iPhone?

Могу ли я получить представление JPEG без преобразования CVImageBufferRef в UIImage (и, следовательно, вырезать довольно дорогую операцию рисования графической графики)?

источник

2010-10-14 Jasarien

Вам нужно сжать их? Что вы делаете с кадрами позже? –

Они отправляются через сеть к сверстнику. Сеть может варьироваться, 3G, Wifi, EDGE и т. Д. Без сжатия изображения (даже на 192 x 144) слишком велики. – Jasarien

Возможно, вам захочется проверить некоторые компрессоры низкой сложности, такие как JPEG-LS, чтобы узнать, соответствуют ли они вашим потребностям. Обычно JPEG-LS без потерь, но есть опция с почти без потерь, которая сжимается немного больше. – gusbro

Является ли беспокойство реакцией приложения или фактическим временем сжатия? Как насчет обертывания кода JPEG в блоке и помещения его в фоновый режим?

источник

2010-12-02 15:01:26 makdad

Хороший крик, но это больше о фактическом времени, которое требуется для преобразования. Работа выполняется отдельно к основному потоку уже (насколько это возможно, в любом случае), но я не могу отправить данные JPEG через сокет до его завершения ... – Jasarien

На самом деле - это может быть неверно? Это может быть чрезмерная архитектура проблемы, но вы можете начать кодирование в фоновом потоке, сохраняя пространство общей памяти для выходного буфера, а затем начинать отправку при кодировании. В большинстве случаев, не связанных с Wi-Fi, я считаю, что на передачу потребуется больше времени, чем для кодирования. Если в вашем буфере закончились данные - это должно быть хорошо, большинство HTTP-соединений (я полагаю, что вы отправляете данные) не теряют время в течение как минимум 30 секунд. Очевидно, что основной проблемой при таком подходе является необходимость проникновения в сеть CFNetwork для передачи данных для отправки. – makdad

К сожалению, это не по HTTP. Это прямое соединение UDP между сверстниками. TCP показала поражение производительности из-за накладных расходов. Потоковая передача JPEG-файлов по мере их кодирования может быть чем-то интересным, но это должно имитировать «видео» (или, возможно, MotionJPEG) вместо более подходящих API для потоковой передачи видео, которые недоступны на iPhone. Я боюсь, что потоковая передача JPEG будет недостаточной, так как «фрейм» будет отображаться только после того, как он будет полностью отправлен. – Jasarien

Быстрее, более эффективное преобразование JPEG и сжатие на iPhone

ответ

Смежные вопросы