How about buffer communications between Camera service and PV Author?

by Dave Sparks » Tue, 10 Mar 2009 17:21:09 GMT


Sponsored Links
 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.



--~--~---------~--~----~------------~-------~--~----~



How about buffer communications between Camera service and PV Author?

by Jia Meng » Wed, 11 Mar 2009 01:53:21 GMT


 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.





--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


How about buffer communications between Camera service and PV Author?

by Dave Sparks » Wed, 11 Mar 2009 06:01:54 GMT


 urfaceFlinger 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 <dspm...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



How about buffer communications between Camera service and PV Author?

by Jia Meng » Wed, 11 Mar 2009 07:42:14 GMT


 oes 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:01pm, Dave Sparks <davidspa...@android.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



How about buffer communications between Camera service and PV Author?

by Dianne Hackborn » Wed, 11 Mar 2009 19:16:57 GMT


 




You really want to have surface flinger using hardware acceleration.
Mathias is working on making it easier to implement hardware acceleration
for it with things besides the G1 hardware.

Also keep in mind that QVGA is not supported in cupcake, so your product
will need to be using some post-cupcake version of the platform.

-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support.  All such questions should be posted on public
forums, where I and others can see and answer them.

--~--~---------~--~----~------------~-------~--~----~



How about buffer communications between Camera service and PV Author?

by Dave Sparks » Thu, 12 Mar 2009 00:19:04 GMT


 ostBuffer() 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 <dspm...@gmail.com> wrote:
--~--~---------~--~----~------------~-------~--~----~



How about buffer communications between Camera service and PV Author?

by Jia Meng » Thu, 12 Mar 2009 02:23:39 GMT


 Indeed, I'm going to use overlay for video recording. Dave once
commented on overlay interface (https://groups.google.com/group/
android-framework/browse_thread/thread/ffe7dacf83567b7b/
91f38f50fc17e036?lnk=gst&q=overlay+hardware
+interface#91f38f50fc17e036). It sounds that overlay and
SurfaceFlinger become two separated interfaces, so I will no longer
call postBuffer() if overlay is used. Right? If so, who will be
responsible for mixing overlay display and surface display? For
example, we got to display both buttons and preview frames during
video recording.

Has Cupcake already supported overlay yet?

Cupcake doesn't support QVGA or VGA? Basically, this limitation comes
from...?

Thanks





--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Seeking for approved developers in Sweden and England

Hi!

Are you an approved developer and have submitted at least one
application to Android Market, living in Sweden or England? Then this
is something for you!

The Technical University of Lule, Sweden, together with the
University of Manchester, UK, is about start a study on Android
developer experience.
They are looking for Android developers that would share their
experience of developing but also publishing their application(s).
The research process includes face-to-face and online sessions.

The Swedish face-to-face interview will take place, in Stockholm,
already next week (w.18) and the English will be in London in
approximatly three weeks. You will of course be compensated with a
gift and get the travel fees paid.

If you think you can participate in one of the session, that would
take a maximum of 2 hours of your time, please contact us at:
mel...@prontocommunication.se

Best regards
Melina, Pronto Communication

--~--~---------~--~----~------------~-------~--~----~

2. Surfaceflinger not clearing application controls with video overlay ( hardware )

Hi

Play a full screen video using gallery applications or any , the
graphics controls appear ( progress bar ) on top of video.
After a few seconds the application controls is expected to disappear
but it does not. It remains sticky on the video overlayed region.
The same is true with any application controls ( graphics plane )
overlayed on top of video

Environment :
The video and the graphics plane ( application controls ) get
overlayed in the hardware unlike the default software implementation
We use a transparency color key value of 0 . So if the graphics buffer
has anything 0 ( black ) it will not be displayed on top of video
Rest of the colors will be displayed on top of video

I have validated that overlay functions work fine using standalone
utilities.

Guess:
The surface flinger is not clearing the last buffer ( or the relevant
graphics controls ) to 0.
I feel the surface flinger compositor sees the video being played and
does not clear the areas on top of video when it is supposed to happen
I am looking at the threadloop()

Questions :
1. How can identify where I must modify to surfaceflinger code to set
0?
2. Can someone explain what is meant by opaque region,translucent and
transparent regions in surface flinger.cpp ?
3. What could be the problem ?

Appreciate your help

thanks
Venky

--~--~---------~--~----~------------~-------~--~----~

3. How can I add birthday date to a contact?

4. joining into chat

5. FingerPaint demo and erase functionality

6. not able to see the link

7. broken file, here is a good one