Back from Computex, time to sum-up our activities there. As written in my last post we had a booth at the Open Embedded Software Foundation (OESF) and I spoke about Advanced Communication Services for Android and the different options for launching video service on Android devices at the OESF Android Blast off!.
At the booth we had that demo I hinted about in my previous post. 720p x 30FPS on a TI OMPA 4 based tablet.
My presentation at the Android Blast off! was actually a story about an imaginary dating company and their head of R&D that receives a list of requirements from their Marketing manager Beth, the requirements are:
- Needs to work on any device
- Good quality, we are a dating service after all J
- Embedded in our dating app
- People can connect from anywhere
- A girl can invite her friend to peek in and rate the guy
- Connect to our partners? services
- I want this working for our high season, this summer
As simplified as these requirements may seem they actually have many technical challenges behind them, and this was the main focus of my presentation, implications of these requirements and possible solutions. Surprising as it may seem RADVISION with its video communication deployment solution and BEEHD offering is in a position to overcome these challenges.
If you want to see the full recording of my presentation go to http://www.ustream.tv/recorded/15090464. Since this is a recording of a few more presentations they posted together you will need to go fast forward to 1h:11m.
Here are the slides:
View more presentations from RADVISION Ltd.
Going back to the requirements, let?s review them one by one and elaborate on the technical implications Jeff had to cope with.
1. Needs to work on any device
This is actually one of the most complicated requirements. Basically there are 4 options to handle the video encoding/decoding part on Android devices. In the presentation I reviewed these 4 options. Additionally these requirements impose the need to run on different platforms including desktop, mobile and tablet.
Software Codec
Software codecs run on the ARM processor of the device and don?t use the HW accelerators. Therefore this type of solution consumes a large percentage of the processor power minimizing the ability to run other applications in parallel, quickly drains the battery and result in a limited video quality in means of resolution and Frames Per Second (FPS) typically reaching QCIF or CIF resolution at 10-15 FPS.
On the bright side of things, this option gives the application developer full control over the video codec, assuming he has source code of it, allowing him to add his own secret sauce such as Scalable Video Coding (SVC) to the codec.
2-Way Streaming
Some applications use streaming technology for real-time video communications. This allows them to utilize the native phone interface of Play/Record, an interface that uses the HW accelerators.
The down side of things in this option is that 2-way streaming is not built for 2-way communications in terms of delay, packetization, codec optimization and error resilience mechanisms such as retransmission and forward error correction. Additionally, this method of communication is not standard thus, it creates an island, something OK yet not perfect if you are in the size of Skype (even they need to connect to the ?other? world) but more of a problem if you are a small startup or a service provider. More on this conflict of interoperability Vs. islands can be found in my post Are OTT The New Walled Gardens?.
Stagefright
Stagefright is an API layer that is part of the Android OS. It is implemented/optimized by the device manufacturer or chipset vendor, utilizes the hardware accelerators for video encode and decode and is supposed to be device agnostic.
Apparently the ideal solution but it has its drawbacks as well: It is available as of Android version 2.2, not always implemented by all device manufacturers and was created with streaming in mind.
OpenMAX
Last option is going real low to the OpenMAX level. This is a much lower level interface giving more flexibility and potentially performance.
In real life it has some major drawbacks.
It is standard in theory but in reality it has many different implementation variants in means of threading model, parameters setting and last but not least it typically requires rooting the device (bye bye warranty) and sometimes even installing a new firmware, there goes out the window the option of a downloadable application.
?
Given all this it looks like choosing the ideal solution is not a simple task. I can also tell you that we have gone through this in a few cases already and are doing some kind of combination between these options.
2. Good quality, we are a dating service after all J
This requirement relates to the 4 options detailed above but also requires technologies external to the codec that need to be part of the media engine, technologies that improve media quality and user experience. Such technologies include bandwidth estimation such as RADVISION?s NetSense technology that predicts packet loss before it occurs and avoids it by changing call bandwidth on time.
3. Embedded in our dating app
This simply means that the client needs to be a customizable framework and not an executable with configuration parameters for customizing it. As a framework that comes as an SDK with sample GUI on top it can be easily embedded in another application. By this the user remains in the same screen of the dating company?s application.
4. People can connect from anywhere
This requirement means connect regardless of the access. Users should be able to connect from a well managed broadband connection or from an internet caf?. Supporting this need requires all the technologies in context with the Good Quality requirement above adding to it things such as rate shaping and scalable FW/NAT traversal.
5. A girl can invite her friend to peek in and rate the guy
This means conferencing capabilities to allow for this ?3rd party monitoring?. This can be offered by RADVISION as we have a complete end to end video solution that includes also a conferencing bridge.
6. Connect to our partners? services
Since they were presented as partnering companies in Europe that already have video deployed it is assumed that other protocols such as H.323 will be required. This inter-protocol communication requires a gateway. Again, something available today as part of our video infrastructure offering.
7. I want this working for our high season, this summer
After going through all the functional requirements, came the schedule requirement, Beth needs this service up and running this summer, in 2 months, this leaves very little time to build all these components internally.
At this point I showed our client framework, how it answers these needs being a fast track for building such a service.
Source: http://blog.radvision.com/voipsurvivor/2011/06/13/computex-and-your-next-dating-startup/
jimi hendrix cate blanchett barista sarah silverman baku dave chappelle jehovah witness
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.