MediaMuxer.nativeWriteSampleData always peroidically blocks for about one second during video recording

Question

I am doing android video recording using mediacodec + mediamuxer, and now I can record video and generate mp4 file which can be played. The problem is that I find the recorded video will seize for about one second some time. So I launched traceview and I find MediaMuxer.nativeWriteSampleData() cause the problem. Sometimes this function is very fast and returns within several micro-seconds, but sometimes this function is very slow and will consume about one second or so, and the video blocks at that time. I do not know why this function will perform so varying from time to time. The recording target file is located at external SDCard or internal storage, and the problem exist on both media.

Neo

Answer 1

This is a problem that occurs mostly on devices with lower writing flash speeds or if you try to write to the SD card. The solution is to copy the encoded data to a temporary ByteBuffer, release the data back to MediaCodec and call writeSampleData asynchronously on a dedicated thread.

So, assuming that you have a thread for draining MediaCodec's ouput and one for feeding MediaMuxer, this is a possible solution:

// this runs on the MediaCodec's draining thread
public void writeSampleData(final MediaCodec mediaCodec, final int trackIndex, final int bufferIndex, final ByteBuffer encodedData, final MediaCodec.BufferInfo bufferInfo) {
    final ByteBuffer data = ByteBuffer.allocateDirect(bufferInfo.size); // allocate a temp ByteBuffer
    data.put(encodedData);  // copy the data over
    mediaCodec.releaseOutputBuffer(bufferIndex, false); // return the packet to MediaCodec

    mWriterHandler.post(new Runnable() {
        // this runs on the Muxer's writing thread
        @Override
        public void run() {
            mMuxer.writeSampleData(trackIndex, data, bufferInfo); // feed the packet to MediaMuxer
        });
}

The problem with this approach is that we allocate a new ByteBuffer for every incoming packet. It would be better if we could re-use a big circular buffer to enqueue and deque the new data. I have written a post about this matter and also propose a solution which is rather lengthy to explain here. You can read it here.