[vlc-devel] [PATCH] display RV32/RGBA instead of RV16
xilasz at gmail.com
Thu May 19 23:40:08 CEST 2011
I did a lot of googling about hardware scaling, here's what i learned :
In android, a SurfaceView(java) use a SurfaceComposerClient(native) to
manage the low level surface (the input buffer), and this
SurfaceComposerClient communicate with the SurfaceFlinger Service, which
display/scale using hardware if available.
Right now vlc-android native code has only the input buffer, with the same
size as the SurfaceView.
So we need the SurfaceComposerClient to do something. I though we don't have
it, but i was wrong. it is in fact the SurfaceHolder in java.
>From there, it's easy : holder.setFixedSize(320, 176) in java code will fix
the input buffer size. When the time comes for android to display it,
SurfaceComposerClient/SurfaceFlingerService, seeing that the buffer size
don't match the SurfaceView size, decide to do what he can => hardware
- send the SurfaceComposerClient hidden inside SurfaceHolder into our native
code (similar to the Surface)
- set the buffer size to the video size
- remove pixman and all scaling stuff
- handle AR stuff in java, by setting the SurfaceView size
I'll work on it soon.
On Thu, May 19, 2011 at 11:34 AM, XilasZ <xilasz at gmail.com> wrote:
> True, it can be handle on java side if libvlc can provide the original
> video size.
> I already wrote a piece of code for my own player which compute the correct
> surface size, based on video size and screen size/orientation. it works like
> a charm.
> On Thu, May 19, 2011 at 11:20 AM, Ludovic Fauvet <etix at l0cal.com> wrote:
>> On Thu, May 19, 2011 at 11:09 AM, XilasZ <xilasz at gmail.com> wrote:
>> > There's a sample on android source code which does just that :
>> Interesting, but you will probably lose the aspect ratio then.
>> Ludovic Fauvet (etix)
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel