Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.
Once it's working I will be happy to show what I have and share if anybody is interested.
We're also working on this, in fact pretty much all our effort now is devoted to getting Ethernet remote control and video download working. It's a very nontrivial task to just get the video into a RAM buffer, which is one of the reasons why it's taking so long.
The video system is built on a framework called OpenMax (OMX). Most of OMX is run internally by a separate M3 core in the CPU. This runs a binary blob provided by TI, the source is available from TI under an NDA, ask for the "DM8148 EZSDK Overlay Package". This handles pretty much everything related to video input, processing, and output to the display. There's another M3 running a different binary blob which operates the H264 encoder. We've modified the former M3 code somewhat to add features like the video save throttling.
In the camApp, OMX is used directly for live display, and saving is done using gstreamer. Internally, gstreamer uses OMX as OMX is the only way to do anything with the hardware accelerated video pipeline. There is currently a problem with the gstreamer component that allows you to get frames into a RAM buffer, foobar or Loial could comment further, but we believe that the component that provides RAM buffers doesn't properly handle shutting down the pipeline, which crashes the M3. This issue needs to be solved before we can get RAW saving over Etherent working.
gstreamer currently supports streaming compressed video via RTSP, if you just want live display that should be significantly easier than getting RAW.
Take a look at videoRecord.c to see how the gstreamer pipeline is set up. There's also a way to run gstreamer pipelines from the command line, Loial has some examples of doing this.