1080p video on Android

BogDan bog_dan_ro at yahoo.com
Sun May 6 19:13:52 UTC 2012


Hi Gabi,


>
>Hello,
>
>I just subscribed to this mailing list and I apologize for the fact that I haven't read everything. First I just want to say that you guys are awesome. I need to port a complex application developed using Qt and you made it all possible. The way you accomplished this is just brilliant. My employer, BroadSign, owns you a great deal. This is why I received the permission to contribute back to the community if it can be useful.
>

Many thanks for your kind words.


>One thing we do is multimedia. I have looked at the code in QtMediaPLayer.java and mediaPlayerJNI.cpp and found it extremely informative. Unfortunately, I came to the same conclusions as BogDan described in the thread "Qt Multimedia status on Android". Without knowing about your efforts, I went on to try to make video work on Android on my own. We have a proprietary video player that already uses FFmpeg with VA-API or DxVA2 for hardware acceleration on desktops. On Android however, knowing that hardware acceleration with OpenMAX would be a problem, I chose a different approach. Instead of getting video from ffmpeg, I cheated and used the Android's MediaPlayer. From the looks of it, the approach is similar to QtCamera. I simply create a new SurfaceView on top of the QtLayout. To get it on top, I call SurfaceView.setZOrderOnTop(true). This works great. I can get 2 1080p h264 videos playing on the Transformer Prime TF201. 
>

Please check also this thread [1], there I try to describe another approach, but it will require android-14+ (maybe android-11+ will work too).


>My question is, are you interested in getting the code to do this?


Of course we are interested!


> I could integrate it into QtMobility and provide the patch. 

Please, do it! Just make sure your patch will not brake something and upload it here[2].


>I know you guys preferred the FFMpeg approach so far. The reason is probably to have a real integration with Qt and I can understand why. I could dig into this OpenMAX thing but some part of me fear that this standard might be dropped for something else in the future.
>

FFMpeg is a great library, is very easy and probably this was the reason why we choose it, anyway for android is not good so we can not use it.
So, OpenMAX (or Android's multimedia API) are the only real choices for the moment, that's why I'm trying to do all these changes which I described here [1].


>
>By the way, for the YUV420p to RGB conversion being slow, have you tryed using OpenGL shaders? 

No, I tried to use ffmpeg's neon implementation.


> I have never used this myself and I am not an OpenGL expert but one of my colleague had some success with it on desktops. It makes the GPU convert colors for you so maybe it could help.
>

Yes, it could help, if you can, please share the code with us.


>Just let me know if I can help,
>Gabi Julien
>

Thanks !


Cheers,
BogDan.


[1] http://mail.kde.org/pipermail/necessitas-devel/2012-May/000913.html
[2] https://git.reviewboard.kde.org/dashboard/

>_______________________________________________
>Necessitas-devel mailing list
>Necessitas-devel at kde.org
>https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>


More information about the Necessitas-devel mailing list