I was able to implement a code which records video bases on CameraCaptureActivity from grafika. Now I can record myself counting from 1 to 10, but when I go to see the recorded video I am saying 1,3,8,9, that is I missed some frames to be recorded. The surface was configured:
private static int VIDEO_WIDTH = 720; // dimensions for 720p video
private static int VIDEO_HEIGHT = 1280;
private static int DESIRED_PREVIEW_FPS = 30;
and the encoder
format.SetInteger(MediaFormat.KeyColorFormat, (int)MediaCodecCapabilities.Formatsurface);
format.SetInteger(MediaFormat.KeyBitRate, 100000);
format.SetInteger(MediaFormat.KeyFrameRate, 30);
format.SetInteger(MediaFormat.KeyIFrameInterval, 5);
width: 310 and height: 310.
is my problem the BitRate? Which values should I set in order to receive every frame which I display to be recorded by the encoder? thanks.
I've seen MediaMuxer pause for 1+ seconds when writing data to disk, but generally not at lower bit rates -- the 1Mbps bit rate used by Grafika should be fine -- and they're usually several seconds apart. So I'm not sure if that's the problem you're facing.
There's a nice blog post about the MediaMuxer problem here: http://blog.horizon.camera/post/134263616000/optimizing-mediamuxers-writing-speed . In short, the MediaMuxer write stalls, so no frames are being pulled out of the MediaCodec encoder. Eventually MediaCodec runs out of buffers and can't take any more input, so the Camera starts discarding frames.
Wrapping the MediaMuxer calls with systrace tags will help narrow things down. The idea is to bracket all the "interesting" calls in your encoding setup with android.os.Trace beginSection() / endSection() calls, and collect systrace output with the --app tag (example here). Looking at the systrace output will show you how long each function takes, show you which threads each runs on, and help you identify areas where a call has blocked and is starving other threads.
It's entirely possible there's something else going on, but this is a good place to start.