Expected fps camera capture about grafika HOT 6 CLOSED

Which device? Does it get slower with the filters enabled?

The only thing I've seen that had a big impact on frame rates was Camera.Parameters.setRecordingHint(true), but that should be set now (5377834).

from grafika.

I am not supposed to disclose too much about what I am working on suffice to say it's an omap 4430 based head mounted device who's name is probably familiar to you.

I have disabled the filters, while cool they are not important for this project. Should I enable them for debugging? I have also locked the camera rate to 30000 and made sure the recording hint was set to true.

Thanks,
-mark

On Nov 5, 2014, at 8:00 PM, Andy McFadden [email protected] wrote:

Which device? Does it get slower with the filters enabled?

The only thing I've seen that had a big impact on frame rates was Camera.Parameters.setRecordingHint(true), but that should be set now (5377834).

—
Reply to this email directly or view it on GitHub.

from grafika.

My concern is that you're running up against a bandwidth limitation routing the camera preview through GLES. When feeding the camera to MediaRecorder the frames will stay in their native YUV format, but GLES will do a YUV-to-RGB conversion when rendering it (and back to YUV if you feed the frames into a MediaCodec encoder).

With the filters enabled the GPU has to do even more work, so if you're GPU-limited then things should get even slower. If it has no effect then the limitation is elsewhere.

If systrace is enabled in the kernel it would be worth getting a trace to see if there's something unexpectedly chewing up CPU or going out to lunch. With the "sched" and "gfx" tags you should be able to see all of the userspace activity, SurfaceFlinger calls, etc. "freq" will let you see if the various clocks are maxed out.

I suspect you're running up against hardware limitations, but it's worth poking at it a bit.

from grafika.

I see what you are saying about the YUV>RGB>YUV conversion. I seem to have found the issue. The TextureMovieEncoder >handleFrameAvailable method was too slow (> 42 ms). I moved the EncoderDraining to its own thread (looping without interruption) and that brought the FPS up to >29. I am new to Java so I am not really sure the implications of that, but it seems to work in my limited testing this evening.

from grafika.

That sounds promising. drainEncoder() will be doing the muxing and file I/O on the CPU, so if the I/O is bursty or laggy it would be useful to get it onto a different thread. The MediaCodec docs are typically silent on the question of access from multiple threads, so if I/O is the real culprit then it might be safer to pull data from the encoder on the same thread that's feeding it, and do the I/O on another.

How does "continuous capture" compare, frame-rate wise? It captures everything into a circular buffer in memory, and does no muxing or file I/O until you hit "capture".

If you'd like to learn more about the Java memory model on Android devices, I can offer you another lovely document at http://developer.android.com/training/articles/smp.html . :-)

from grafika.

I can check the continuous capture sample, but I disabled muxing early in the project because I didn't need it (and to see if that was the culprit on the low perf). It looked to me like the combination of the MediaCodec drain and the other stuff in the handleFrameAvailable method. It seemed like it was just doing too much and backing up the message queue.

Also, I am actually sending the NALs out on the network and not writing with the muxer (although I did write them to a temp file for debugging using regular file ops and it seemed to perform well). My CPU usage at full load is about 78% (including writing to temp file). I am going to run longer tests today to check for the stability over a longer time . Thanks for all your help.

from grafika.