Hello, I have a question about the preview frames that can be returned by Camera Services to the applications. There seems to be two different means of returning the frame, copied or not copied, ignoring the one shot case which is not important for this discussion. In both of these cases, the stride of the buffer does not seem to be taken into account. The application will need the stride in order to properly parse the buffer, unless the width of the frame data and the stride are equal.
If one were to use hardware or a software feature which pads the frame, the Surface Flinger would be able to properly parse the buffer, since it has the width stride, but I have not found any place where the application can get this key piece of data. This issue could be quickly solved for the cases where a copy of the preview buffer is requested by the application. In this case the copyFrameAndPostCopiedFrame() function would just need to copy the buffer with the knowledge of the stride. The stride could be stored off when the Surface Flinger is given the heap and then reused in this function to properly copy the preview data from the preview frame to the buffer that will be passed to the application. In the case of returning the actual preview memory, the issue gets more complicated. The application would need to be given (maybe in the callback) the actual frame stride. I'm not sure how the application could parse the preview frame without it. One feature that will tend to cause preview frames to be padded is image stabilization, but I can also imagine hardware limitation that may also cause padding. Thanks, Steve. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
