Why doesn't the swap interface work for multiple buffers? Is there some nuance I'm missing?
On Dec 18, 6:06 am, Andrew Green <[email protected]> wrote: > It seems like it would be nice to maintain the postBuffer(offset) API of > ISurface even for hardware overlays because the overlay could have more than > two buffers. Overlays with only two buffers could still just do page flips. > If that API is kept then is IOverlay even needed? > > To expand on the need for multiple overlay buffers - in our system the > overlay driver needs to be the one to allocate video buffers. These buffers > can be handed to the OMX codecs to be filled with video pixels. After being > filled with video they can be handed back to the the overlay driver for > display. More than two output buffers are needed to keep this running > smoothly. > > Thanks, > Andrew > > > > > Date: Wed, 17 Dec 2008 21:34:33 -0800 > > Subject: Re: OMX source/sink and Tunnelling of processing components > > From: [email protected] > > To: [email protected] > > > Yes, PVPlayer still uses an ISurface. But instead of pushing instead > > of pushing frames into SurfaceFlinger, it just does a page flip on the > > IOverlay interface it gets from SurfaceFlinger. > > > On Dec 17, 7:25 pm, hanchao3c wrote: > >> Hi Sparks! > >> I will look at the cupcake code for it. > >> I this using hardware overlay is good solution. > > >> But do you mean PVPlayer neen't chang by using hardware overlay? > > >> Just using ISurface at its interface ? > > >> On Dec 18, 10:37 am, Dave Sparks wrote: > > >>> 1. If the MIO is active, then it controls its own sink using the > >>> timestamps on the frames. If the MIO is passive, the frames should be > >>> displayed as they arrive. > > >>> 2. I think you are talking about the case where the video is displayed > >>> by hardware overlay and not using the 2D engine (SurfaceFlinger). In > >>> this case, you need to use the new overlay abstraction as described in > >>> the other thread. PVPlayer does not get involved at all, it only needs > >>> to know the size of the video, not the window display size. Position, > >>> scaling, and rotation is handled either the SurfaceFlinger or by the > >>> overlay hardware. > > >>> 3. Color key is also in the hardware overlay abstraction. > > >>> On Dec 17, 6:06 pm, hanchao3c wrote: > > >>>> Hi Dave Sparks ! > >>>> Thank you very much. > >>>> I thought this solution is well, but then I found it is not perfect > >>>> I think the "control interface problem" are: > >>>> 1. By using it , Video will be render to output device directly. Who > >>>> can do the AV sync? > >>>> 2. If high level software want to change the video size or > >>>> orientation, How to control PVPlayer ? > >>>> 3. If we want to change to Color-key to control to layers. (Case: When > >>>> playing a video , other application is launched) > > >>>> On Dec 17, 10:08 pm, jasperr wrote: > > >>>>> I found it's the video decoder node that allocates buffers for its > >>>>> video decoder OMX component now. > >>>>> (in function "provideBuffersforcomponent") > > >>>>> If I want the video dec omx component to use buffers allocated by the > >>>>> video surface output. It seems I have to modify this code. > > >>>>> Is there a easy way for the video decoder node to find its peer, the > >>>>> video sink node? > >>>>> So the video sink node can let the surface ouput to allocate buffers. > > >>>>> Thanks > >>>>> Amanda > > _________________________________________________________________ > Send e-mail faster without improving your typing > skills.http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
