Streaming video playback performance issues with background tasks on Android

Question

I have developed a little application that can play video from a rstp streaming sever (darwin in this case, but this is not relevant) by means of the VideoView widget (I have tried Mplayer+SurfaceView approach too). I use Wifi connection for this.

The video plays just smooth when video is the only task. The small application should carry out other tasks at the same time such as continously discover bluetooth devices and call a remote web service (I am using Ksoap2 for this). When these background taks run at the same time as the video playback the performance incredibly drops (the image and sounds sometimes stop and image gets distorted, showing rather big squares instead of proper frames).

This happens even with low quality videos (3gp at 50 kbps). For the bluetooth discovery I have used both available methods with no performance enhancement over each other:

• Using discovery way provided by SDK 5 and register every found bluetooth device.
• Using a native call to a self written scan() method that takes advantage of hci_inquiry() function provided by Bluez API.

The call to WS requieres the bluetooth adressess of the discovered devices. The call comes after the discovery has finished.

I tried to use a GLSurfaceView instead of SurfaceView, but as I am rather new to Android platform, and have no 3D graphic programming mileage, I could not make it work, since I could not find any example of how to use OpenGL ES propertly to playback video and still being able to let Android API control other UI related stuff (Dialogs/Menus/Toasts). On the other hand I do not know if this could indeed improve the playback.

Any clues or tips of the way I could take?

Edit: I forgot to say that I am developing on a Motorola Milestone

Edit 2: Following CommonsWare and snctln suggestions I tried to minimize memory footprint of application while not completely leaving out SOAP WS calls.

Now I try to cache as many objects as possible and only execute call when new BT devices are found (WS need discovered BT devices as input) to minimize GC calls. Video still plays awfully only with Bluetooth discovering active (no WS calls at all).

Edit 3: Solution: I modified my application to use UMTS (3G) data connection instead of Wifi when scanning bluetooth devices. Though device accesses public Internet (m.youtube.com) it plays streaming video far smoother over 3G (from public Internet servers) than over local Wifi (from local streaming server). Local streaming server performance is not an issue since streaming to desktop PCs just runs fine. I also upgraded device firmware to 2.0.1 and also experienced some improvement with local Wifi connection, but 3G playback performance still beats Wifi.

My conclusion is that this device must have some conflicting hardware (maybe same chipset) or software issues when using simultaneous Wifi/Bluetooth communication.

Answer 1

Please understand that the Motorola Milestone has the CPU speed and RAM of a PC from about 12-15 years ago.

Any clues or tips of the way I could take?

Dump SOAP and use a lightweight Web service protocol (e.g., JSON over REST). Lower the priority of the thread(s) doing this work so they do not interfere as much with the threads handling video playback. Add as much "breathing time" in your Bluetooth scans as possible, rather than continuously executing code to try to discover devices.

Assuming that does not resolve the problem, use traceview and similar tools to try to optimize your background threads (probably without the video running).

Answer 2

One thing you could do is take a look at your memory allocations. About a year ago I was having display performance issues with a game, every 2 seconds or so there would be a large amount of "lag". I posted to the android-develoeprs Google group and got some pointers for tracking down the problem from one of android engineers. he later put together this blog post that details the process of tracking memory allocations, this is important to track because the lag that I was seeing was directly due to garbage collection. Now that I keep my allocations to a minimum this lag happens much less frequently.

Also I agree with Mark(CommonsWare), if you can dump soap for a light weight protocol you might see some improved performance.