2013-11-14 1 views
0

После некоторых проблем мне наконец-то удалось получить видеозапись, работающую в моем приложении, используя MediaRecorder.Тупик в Android-рекордере Android при использовании PreviewCallback во время видеозаписи

Теперь я хочу обработать как можно больше кадров предварительного просмотра во время записи. То есть Я хочу захватить рамку предварительного просмотра, обработать ее и игнорировать любые кадры предварительного просмотра во время обработки этого. После завершения обработки его я хочу идти с следующий один идет в

Для этого я попробовал два различных подхода:.

  1. Добавить два буфера через Camera.addCallbackBuffer() и есть поток работы над один из них, в то время как PreviewCallback мгновенно повторно добавляет текущий «неиспользуемый» буфер всякий раз, когда кадр поступает.

  2. Используйте setOneShotPreviewCallback(), обработайте кадр в методе обратного вызова и снова запустите setOneShotPreviewCallback().

Обработка одного кадра занимает около 500 мс.

С обоих подходов я получаю две проблемы:

  1. В окне предварительного просмотра кадров (на TextureView) уменьшается много
  2. Главный вопрос: В большинстве случаев я получаю какой-то мертвой блокировки во время записи или конец записи.

Вот что я делаю (с помощью setOneShotPreviewCallback() - подход):

MediaRecorder mr = new MediaRecorder(); 
(prepare Recorder...) 

mr.start(); 
cam.setOneShotPreviewCallback(myCallbackObject); 

И потом, из другого потока я останавливаю запись:

mr.stop(); 
cam.setPreviewCallback(null); 
... 

Вот что делает метод обратного вызова :

(do something with the data buffer) 
cam.setOneShotPreviewCallback(this); 

В большинстве случаев мой код получает застрял на

mr.stop(); 

, но иногда и на

cam.setOneShotPreviewCallback(this); 

внутри обратного вызова.

Большое спасибо за любой совет!

ответ

0

Обработка одного кадра занимает достаточно много времени, чтобы оправдать a) запуск его в AsyncTask и b) копирование кадра предварительного просмотра в другой байт [].

setOneShotPreviewCallback() кажется хорошим выбором, но скопируйте пиксели в предварительно выделенный массив и вернитесь из onPreviewFrame() как можно быстрее.

+0

Спасибо за ваш ответ! Я попробовал это. Копирование буфера в методе onPreviewFrame и запуск нового потока, который обрабатывает скопированные данные. Все-таки такое же поведение. – Robert

+0

А, ок! Я думаю, что избавился от проблемы «тупика». Теперь я вызываю mr.stop() из потока пользовательского интерфейса, и кажется, что это больше не будет блокироваться. Но одна вещь все еще есть проблема: падение кадров. Я вижу это на экране предварительного просмотра И в полученном видео также (что еще хуже!). Почему это так или иначе происходит? Является ли это слишком много работы для моего тестового устройства (SGSII)? Единственное, что я делаю в потоке, который вызывает PreviewCallback, - это копирование буфера и запуск рабочего потока. – Robert

+0

Хм .. Вы видите такое же замедление, если не запускаете рабочий поток (без обработки изображений)? –