Zugriff auf die native Android-Kamera: startPreview () vs startRecording ()

8

Der Versuch, die Kamera mit nativem Code in Android ICS zu arbeiten: Die meisten Handbücher beziehen sich auf die Methode startPreview () . Aber beim Durchsuchen des AOSP-Codes habe ich auch die ' startRecording () Methode in <Camera.h> gefunden. Hier heißt es, dass es von der Schnittstelle ICameraRecordingProxy stammt ", damit der Recorder während der Aufnahme Videobilder empfangen kann "

Die Frage ist also - in Bezug auf die Leistung ist der 'startRecording' Ansatz effizienter als 'startPreview'?

Das einzige Ziel, in nativen Code zu gehen, ist Performance, Java 'Camera' ist zu langsam und OpenCV bietet nicht die erforderliche Ebene von FPS.

BEARBEITEN: Zielplattform ist: API Level = 17, Gerät Allwinner A31 Entwicklungsboard, 1280x720x30FPS. Die Aufgabe besteht darin, Bilder von der Kamera aufzunehmen, zu modifizieren, zu kodieren (H264) und auf SD-Karte zu speichern. Pure Java MediaRecorder schreiben MP4-Datei mit 1280x720x30. Show live Vorschau auf dem Bildschirm ist nicht erforderlich.

OpenCV-demo1 im nativen Modus ergibt 1920x1080x2 (dasselbe im Java-Modus). Simple Java-Ansatz mit leeren PreviewCallback maximale FPS ist 15.

Vielen Dank im Voraus ..

    
user2199593 17.02.2014, 10:22
quelle

3 Antworten

1

zum Schließen des Themas: Ich konnte 1280x720 mit FPS = 30 erreichen, indem ich nativen Zugang zur Kamera benutze und Hardware-H264-Kodierer benutze. Kann auch (Wasserzeichen) Daten on-the-fly ändern und FPS hoch halten. Keiner der anderen Ansätze - irgendeine JAVA oder OpenCV könnte mehr als 15 FPS geben (vielleicht habe ich mich nicht bemüht.)

startRecording () funktioniert perfekt

danke für Kommentare

    
user2199593 21.02.2014, 12:29
quelle
1

In Bezug auf die Leistung gibt es keinen Gewinn für die native Kamera. Verwenden Sie Camera.setPreviewCallbackWithBuffer () in Java ( off-UI-Thread ) gibt so viele Bilder pro Sekunde wie jeder native Alternative. Aber auf einigen SOCs, z.B. Samsung, Kamera-Ausgang kann direkt (0-Kopie) mit HW h264-Encoder verdrahtet werden, was natürlich einen ausgezeichneten Durchsatz ergibt. Dies ist der & lt; quote & gt; reine Java MediaRecorder & lt; / quote & gt; tut unter der Haube. Sie können dasselbe nicht erreichen, wenn irgendeine Manipulation des Puffers beteiligt sein sollte.

    
Alex Cohn 17.02.2014 21:26
quelle
0
%Vor%

wenn

%Vor%

gibt Daten in interner Form an. Es sind keine reinen yuv-Rahmendaten garantiert. Zum Beispiel kann data.get()->size() größer als yuv frame size sein oder kann eine 20-Byte-große Datenstruktur für einen echten (?) Framebuffer haben, der irgendwo in der Kamerapufferliste steht.

Also, dieses Thema ist noch nicht vollständig. :)

    
Gost 04.03.2015 14:05
quelle

Tags und Links