We’ve had a lot of interest in our forthcoming multi-screen video application note, from both vendors and network operators. One question that’s come up regularly is “Can you give us a little more information on what will be provided?” OK, yes we can.
This application note is designed to show how ExperiaSphere can take a relatively simple service like streaming multi-screen video and expand that to something that can be monetized, not just in one way but in many. The document describes a basic ExperiaSphere Service Factory that offers streaming video to consumers who have obtained video rights (through subscribing to a multi-channel TV service, buying a network subscription, or pay-for-view). That framework, we show, is inherently expandable to support not only streaming, but streaming with screen/device switching, and for video sharing. It’s also suitable for not only IP-based streaming video but also for TV/VoD/DVR including recording and tuning, and also for switching from streaming video to TV viewing and vice versa.
But we don’t stop there. We demonstrate that this same framework can also support federated video between partners, video where a customer of Network A can obtain video (subject to that same rights verification) even when the customer is in a partner network—mobile roaming, hotel WiFi, or whatever. The mechanism even allows for the possibility that the rights to view don’t transfer to all possible locations.
But there’s still more. We demonstrate that this framework can deliver “meet-me” video/telepresence services that can include any number of users, let late-comers catch up with a replay, and even support flexible views of the conference attendees. You can do a webcast too.
The architecture we use here, of course, is that of ExperiaSphere, and we provide detailed component diagrams, XML, and explanations of how information flows from the order of a video through switching and sharing, to the end of the experience. It’s not code, and in fact no code is included, but the information would be sufficient in our view to allow a good Java architect/software designer to build the application. Access to our proto-code would make that easier of course.
The document will be freely distributable, and it comes as is with no support. We’d be happy to consult on details of implementation, but we can’t offer free help in interpreting or using the material. We also want to remind everyone that ExperiaSphere is pre-Alpha and so source code is available only to participating partners. Roughly speaking that means that if your company is prepared to work out an agreement with us to contribute to the project, an agreement you’ll allow us to release and to hold you to, an agreement that will include the creation and submission of at least one Experiam, Broker, Messenger, or other keystone object, then you can get the code and the full documentation set, which is now over 350 PowerPoints. Remember, we don’t support this activity with free consulting; we will only coordinate the milestones and insure that you meet coding guidelines when you submit.
So that’s what’s coming. When? No later than mid-October, likely no later than mid-September if our other commitments don’t get excessive. Select operators who helped us with requirements can get a draft document as early as late this month. An announcement of the availability of the material will be made here in this blog, and the material will be posted on the Project area of our ExperiaSphere website. We’re excited about this; we hope you will find it useful.