I was taking a look at the BigFlake examples of video encoding, namely this one:
http://bigflake.com/mediacodec/EncodeAndMuxTest.java.txt
And I was wondering if this method is fundamentally faster than just using onPreviewFrame method from the CameraCallback object itself to retrieve the raw bytes of the image and feed them to the encoder.
If this is the case, then can anyone explain to me the reason why this is faster?
Both yes and no, depending on what you do.
If you get the raw bytes from the camera preview callback, the pixel data needs to be passed from the media server process into your app's process, and from your app back into the media server process into the encoder. The pixel data is kept in YUV format all the way, but your app might need to convert it from one YUV layout to another (encoders can accept pixel data in a few different formats, which aren't necessarily one of the same as what the camera provides in the public API).
If you pass the frames from the camera to the encoder via EGL/OpenGL, the actual pixel data never needs to pass into your process, but is kept in opaque surfaces, where all the format conversions are handled by the graphics hardware. This does on one hand involve converting the pixel data from YUV from the camera into RGB when passing through OpenGL, back into YUV when going to the encoder, but all of this is abstracted away.
So depending on the quality and amount of optimizations spent on the camera drivers and EGL/OpenGL drivers, that approach can probably be as fast or faster. Especially if you want to do some sort of processing on the image data, if it can be done in a GL shader. The camera preview callback approach might seem more straightforward, but it actually has quite a bit of inherent overhead in passing the data into your app's process.