Not so long ago, at the half way mark of the GSoc, I was optimistic that I was near to actually interpretting data from the camera in such a way as to produce images on screen. I was successfully grabbing payload data from the camera, the camera's in-use light was on, things were looking good. Since that point, progress has been repeatedly stalled by strange and difficult to debug behaviour.
The first problem which I encountered was that the vast majority of the data received from the camera consisted only of headers with very little actual image data ever attached. In a few seconds of contact with the camera as an example, only 6 out of 7714 packets (0.000778%) contained content. That was worrying. Furthermore the bit indicating an error was often set in the headers, although not perpetually. Investigation of that problem has revealed one of two possible scenarios.
1) Protected content -- This situation occurs if the data source device detects that the video or still-image data is protected and cannot be transmitted. In this case, empty packets containing only headers will be sent for the duration of the protected content.
2) Input buffer underrun -- If the data source device is not able to supply data at the requested rate, it will transmit empty packets containing only headers for the duration of the buffer underrun.
There are other possible error modes, but these are the only two described in the specification which indicate the empty packets with only headers behaviour. Both