Qt Multimedia status on Android
BogDan
bog_dan_ro at yahoo.com
Sun May 6 13:11:37 UTC 2012
Hi,
Nice article !
At least for android-14+ I think it is possible to use another approach, I wrote another mail about about it, any comments will be highly appreciate ! :)
Cheers,
BogDan.
P.S. Folks if you have solutions why don't you share them with us ?
>________________________________
> From: Michał Kowalczyk <mkk at ekk.pl>
>To: BogDan <bog_dan_ro at yahoo.com>
>Cc: George Tavares <tavares.george at gmail.com>; "necessitas-devel at kde.org" <necessitas-devel at kde.org>
>Sent: Friday, May 4, 2012 8:23 PM
>Subject: Re: Qt Multimedia status on Android
>
>
>Couple weeks ago I published solution which is similar to yours, George:
>http://mkk.ekk.pl/?wpis=4
>I use OpenGL only for acceleration of displaying frames (it takes lot of time, what is really strange). I provided decoding YUV into RGB, try to do some optimization and use all accessible CPU cores. Maybe it is possible to make it better. I hope it will be useful for you.
>
>Cheers,
>Michał
>
>
>
>2012/5/4 BogDan <bog_dan_ro at yahoo.com>
>
>Hello George,
>>
>>>________________________________
>>> From: George Tavares <tavares.george at gmail.com>
>>>To: necessitas-devel at kde.org
>>>Sent: Thursday, May 3, 2012 11:13 PM
>>>Subject: Re: Qt Multimedia status on Android
>>
>>>
>>>
>>>Hello BogDan
>>>
>>>I am making some work with android multimedia too, but in Camera support and I make some progress that I can share with you.
>>>
>>
>>Maybe we should join forces ?:)
>>
>>
>>
>>>
>>>I started with QtCamera.java/androidcamjni.cpp available in your sdk, and tried direct render the image previews received in androidcamjni.cpp to a QDeclarativeItem. The performance was not good.
>>>
>>>I look in QtCamera.java and saw that frames are encoded to jpeg , and later loaded to QImage, I decided elimate this step, sending the bytearrey of preview direct to CPP side and use a Method from Ketai project! (decodeYUV420SP) to decode frame. After running, it continue slow.
>>>
>>
>>:)
>>
>>
>>>
>>>However, I am running qt with opengl enabled, then I decided upload YUV frame like a texture and make de YUV decode in a shader. It now it is fast. I can't see differences in my camera support (800x600) and the camera from Android application.
>>>
>>>I have only one problem implementing the shader. the YUV format appears like that:
>>>YYYYYYYYY
>>>UVUV
>>>
>>>When I tried to load this like textures, I choose first load in two textures, one with Y component of type GL_LUMINANCE and other with UV component with a type GL_LUMINANCE_ALPHA . In fragment shader I tried load these components but the GL_LUMINANCE_ALPHA has some kind of bug that the components are not load correctly. Then I decided to unscramble the image in this format:
>>>YYYYYYYYY
>>>UUVV
>>>
>>>Then I load the U and V texture separately.
>>>
>>
>>Great, can you please share with us the shader sources ?
>>
>>As I sad I already have the texture, the problem is how to display it on a non-gl widget ...
>>Using OpenGL for rendering everything it can be a solution but sadly on android we
>>
>>are limited to a single windowsurface, so the UI is (extremely) limited to a single
>>
>>Top Level Widget, this means you can't use controls which needs another TLW
>>(e.g. dialog, combobox, etc.).
>>
>>Check http://code.google.com/p/android-lighthouse/issues/detail?id=4#c24 for
>>
>>more informations.
>>
>>
>>
>>Thanks,
>>
>>
>>Cheers,
>>BogDan.
>>
>>P.S. Please join the mailing list to https://mail.kde.org/mailman/listinfo/necessitas-devel
>>
>>_______________________________________________
>>Necessitas-devel mailing list
>>Necessitas-devel at kde.org
>>https://mail.kde.org/mailman/listinfo/necessitas-devel
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20120506/2fb2bcfc/attachment.html>
More information about the Necessitas-devel
mailing list