postBuffer() does not memcpy, but the call will block if SurfaceFlinger is accessing the memory from the last buffer. In other words, when postBuffer() returns, you know it is safe to write again to the previous buffer that was posted.
On Mar 11, 12:42 am, Jia Meng <[email protected]> wrote: > Does that mean postBuffer() doesn't memcpy and SurfaceFlinger always > works on the same buffer passed in by camera service? It seems unsafe, > because I found software composition of SufaceFlinger consumes a lot > of MIPS on our platform with QVGA screen. For a larger resolution, say > VGA, SurfaceFlinger probably can't achieve 60 fps. > > On Mar 11, 2:01 pm, Dave Sparks <[email protected]> wrote: > > > SurfaceFlinger always posts the last frame it receives. It refreshes > > at 60 fps on the G1, so this should not be an issue. > > > If your display is refreshing at less than 30 fps, you are going to > > have complaints about the UI. > > > On Mar 10, 6:53 pm, Jia Meng <[email protected]> wrote: > > > > I have the same question about SurfaceFlinger. When previewing, camera > > > service keeps posting frame buffers (from a circular queue) to > > > SurfaceFlinger using postBuffer(). Will SurfaceFlinger copy the > > > received buffer out immediately? If not, it might fall behind of > > > camera input too. > > > > On Mar 11, 1:21 am, Dave Sparks <[email protected]> wrote: > > > > > There is a change in our internal tree to add a separate callback > > > > mechanism for encoder frames. When the encoder is done encoding the > > > > frame, it calls WriteComplete on the camera MIO, which in turn calls > > > > the camera hardware driver to release the frame. > > > > > I suspect the problem you are seeing is that the encoder can't keep up > > > > with the camera input. I've found that OpenCore usually asserts after > > > > this. On our internal tree, we have modified the OpenCore assert to de- > > > > reference a NULL pointer so we can get a stack trace. > > > > > On Mar 10, 2:14 am, Jia Meng <[email protected]> wrote: > > > > > > Hi, > > > > > > I'm trying video recording on Cupcake (hasn’t updated to OpenCore 2.1 > > > > > yet). I'm curious about the buffer communications between Camera > > > > > service and PV Author. > > > > > > PV Author registers a callback to Camera service through > > > > > setFrameCallback(). After Camera service posted a buffer to PV Author > > > > > (without memcpy), how can it be notified when the buffer has been > > > > > consumed? If capture frame rate is faster than Author’s consuming > > > > > rate, could there be any problem? > > > > > > Also, when I tried Camera application under high quality recording > > > > > mode (352x288), it will hang with a binder failure followed by several > > > > > media services died. Below are some lines picked from PV log. I think > > > > > the 5th SendInputBufferToOMXComponent() shouldn’t happen before > > > > > EmptyBufferDoneProcessing, and PV log stops after > > > > > EmptyBufferDoneProcessing on the last line. How does PV Author handles > > > > > data congestion internally? > > > > > > Thanks, > > > > > Jia > > > > > > PVLOG:TID(0x20260):Time=7059:PVMFOMXEncNode- > > > > > Video_H263::SendInputBufferToOMXComponent() - Buffer 0x407e8000 of > > > > > size 202752, 1 frag out of tot. 1, TS=0 > > > > > PVLOG:TID(0x20260):Time=7120:PVMFOMXEncNode- > > > > > Video_H263::SendInputBufferToOMXComponent() - Buffer 0x40819800 of > > > > > size 202752, 1 frag out of tot. 1, TS=59 > > > > > PVLOG:TID(0x20260):Time=7149:PVMFOMXEncNode- > > > > > Video_H263::SendInputBufferToOMXComponent() - Buffer 0x4084b000 of > > > > > size 202752, 1 frag out of tot. 1, TS=79 > > > > > PVLOG:TID(0x20260):Time=7181:PVMFOMXEncNode- > > > > > Video_H263::SendInputBufferToOMXComponent() - Buffer 0x4087c800 of > > > > > size 202752, 1 frag out of tot. 1, TS=124 > > > > > PVLOG:TID(0x20260):Time=7212:PVMFOMXEncNode- > > > > > Video_H263::SendInputBufferToOMXComponent() - Buffer 0x407e8000 of > > > > > size 202752, 1 frag out of tot. 1, TS=154 > > > > > PVLOG:TID(0x20260):Time=8589:PVMFOMXEncNode- > > > > > Video_H263::EmptyBufferDoneProcessing: Release input buffer (with 0 > > > > > refcount remaining of input message) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
