The article deals with the challenges of streaming video to a device for video on demand while m-View mainly concerns streaming from a device for live streaming.

Below is a brief summary of the Gizmodo article by Matt Buchanan.

Wireless signals rely on radio waves, which have limitations in terms of speed and reliability. Plus, wireless can be costly because radio waves require huge amounts of power (especially if you want to increase the wireless networks speed and reliability) and providers have to pay for the right to use radio waves.   

The article then goes on to look at what it identifies as the single biggest growth area for internet traffic – video – and names three major problems on streaming video to a mobile device over the air:  wireless spectrum, backhaul, and the device itself.

In terms of video, Buchanan talks about specific standards for mobile video (such as 3GPP) but also mentions that most of the video traffic currently uses HTTP (hyper text transfer protocol) or adaptive HTTP. Standard HTTP is used because it’s the most firewall friendly but has its drawback, because it doesnt adapt to the network conditions and video can freeze up. Adaptive HTTP adapts to the bandwidth to deliver the best available video frame rate without stalling however for real time, live video with low latency this is not always possible.

The article finishes up by looking at a few different video technologies in the US, specifically Verizon's VCAST, AT&T 3GPP video, Qualcomm's MediaFLO and Apple’s HTTP live streaming.

APCO Australia was held from 14-17 March and all the Momentum staff involved were exhausted by bump out…as I’m sure everyone else involved in APCO was too!

It was an exciting event for Momentum this year, with a real buzz around m-View.

We kicked off the event with a bang, when Telstra CEO David Thodey talked about the m-View deployment for NSW Fire Brigades, and gave attendees a sneak peek of the video case study. On Tuesday morning Allan Short from QLD Ambulance gave his presentation on m-View and community safety in QLD, and in the afternoon Momentum MD Adele Whish-Wilson stood in for Adam Damen of Victoria’s State Aircraft Unit to present his case study on the deployment of m-View in SAU planes. Adam was called away to a fire!

In addition to our own stand, this year Momentum staff were also available at the Telstra, RIM/BlackBerry and Modular Mobile Solutions (TLC) stands, representing our strong partnerships with these organisations.

Of course, m-View demos featured at our stand, as did our naked and brand-spanking-new mannequin (see the pic above).

Our competition also proved popular, with visitors given the opportunity to win a DeLonghi Nespresso coffee machine. Congratulations to the winner – wouldn’t mind a Nespresso right about now myself!

It seems Momentum staff must be on the naughty list… most of us didn’t get the tech gadgets we wanted for Christmas! Below is a round-up from some of the team members.

Debi (Project Manager) asked Santa for some Bose noise-cancelling ear phones. Perhaps they were too expensive at $500. She also has her eye on the L5 Remote for iPhone, which will replace her six remote controls at home. Birthday?

Arundev (Software Developer) wanted the new 27inch iMac, but got a business shirt instead.

Darren (Technical Team Leader) was hoping Santa’s sack would hold a Parrot AR.Drone – a wi-fi toy helicopter described as “when video games become reality” that can be controlled by an iPhone or iPod Touch. See it at http://ardrone.parrot.com/parrot- ar-drone/en. Maybe Santa (and his wife) didn’t know what it was…or thought he should grow up.

Phillipa (Communications Officer) I wanted a Netbook or new mobile phone to replace my existing mobile, which is decidedly worse for wear after going through my daughter’s teething slobber over a year ago. No go on the Netbook or phone, but I did get a Bluetooth car kit.

Guy (Chief Technology Officer) and Adele (Managing Director) faired a little better. Guy got a new digital camera, the Canon Ixus100 – a compact camera with 12MP 3x optical zoom and face detection. He also received a Logitech Harmony One Universal Remote control that's meant to control all his devices including the Playstation 3 with TV tuner and PVR. However, eight hours of set up later he still has some work to go to achieve remote control nirvana.

And Adele got a Dell Wasabi ink-free Mobile Printer, a portable colour printer that allows you to print photos from your phone wireless, via BlueTooth. Kind of like a Polaroid, it’s the size of small paperback book and is apparently great fun at parties.

Were you on the naughty or nice list?

When we got our first Forum Nokia email about the NAVTEQ Global LBS Challenge, the timing seemed perfect. A chance to be in the premier industry event for the development and emergence of cutting-edge location-aware wireless applications was just the opportunity we were looking for.

Okay, I’m interested! Now, what to submit?

We were thinking about adding location information to one of our existing mobile applications, but we were not sure what would be the best use of GPS data. This contest allowed us to consider the many innovative features we could add by incorporating LBS (Location Based Services) data. And potentially gain some fame and fortune along the way!

After a couple coffees and a quick brainstorming session, we came up with a few wild ideas for a new project, but the one that stuck in our minds was Local Joe Live. Local Joe Live is an online service that lets users connect with, and view live video footage from, local travel guides around the world (for more information, visit: www.localjoelive.com).

So why did we embark on this project? Well, 70,000 visitors seek travel information on Expedia daily. Meanwhile video is currently the fastest growing social media platform and is tipped to be the next growth driver for the mobile web. It seemed logical to marry travel-related location-based information with our pioneering M-View technology platform and create an exciting, new consumer offering.

So we got our thinking caps on ….

LBS, NAVTEQ and GPS?

To get started, we did some research into the NAVTEQ data offerings, LBS services, and GPS availability on the Nokia N95, which was the official device for the contest.

For an LBS newbie, it was quite interesting and daunting to find out how much data lives behind the maps we use every day. POI (Points of Interest, i.e. a hotel or park) data, navigational routing, and even traffic data, are all available on request from various services (online requests, downloaded databases, etc.).

It’s a simple feature to place your location on a map but it’s a much more useful if you can relate your position to the environment around you, for example, where is the closest ‘place that you are interested in’ here?

Let’s get coding!

So we signed up as a developer partner with NAVTEQ (developer.navteq.com) and registered our interest in the contest (www.lbschallenge.com) and hit our first technical hurdles – with which programming language to work (C/C++, Java, Visual Basic), and in which format to get the data (RDF, GDF, ESRI Shapfile, SIF+, Mapinfo TAB).

The first question was easier because we are a C/C++ shop, but the next choice was not so straightforward.

We knew very little about these different data formats, but a quick review of the FAQs on the LBS Challenge site clarified our options. GDF and SIF+ are ASCII representations of the data, ESRI Shapfile and MapInfoTAB files are for use with the appropriate third-party tools (which we did not have), and RDF is a relational database format (phew!) that we could load onto one of our existing database servers.

We had a few technical issues with the batch loading commands and the SQL Server Migration Assistant (see Gotcha #1) but with some excellent support from NAVTEQ, we were able to import the data files and get started.

Gotcha #1: Don’t try running the batch uploads into SQL Server 2005 like I initially attempted (ignoring instructions given to me, then wondering why it would not work!)The batch commands are only compatible with SQL Server 2000 but to get around this, I installed SQL Server 2000, ran the batch uploads and then upgraded the SQL Server to 2005 and all was well.

Gotcha #2: The amount of data was huge (600+ MB just for Australia) and much more complex than I had envisioned, which put us behind schedule right from the start. I really needed to take the time to review the documentation to understand the relationships between the tables and data.

Once we figured out that relating POIs to a location based on postal codes (which is very universal and as close as we need for our system) we were able to continue to build of our application for the challenge.

Development continued, pressure mounted (no extensions on this deadline!) and the entire team worked feverishly to complete our application in time.

Submitting the Application:

To submit our application for the first round of judging we were given two options: upload our solution to run on an emulator, or submit on our own Nokia N95 device via courier to the NAVTEQ offices.

Due to the nature of our application (video streaming) it would not function as an emulator application as the emulator does not support video capture. So we had to use one of our own N95 devices, which was graciously loaned to us by one of our developers, so we could continue running our in-house development work in parallel.

Making changes right down to the wire (as usual) and trying to fit in every feature we could dream up, we successfully completed our application and shipped the demo N95. With hours to spare!

One last gotcha: We found out the application would be judged in Singapore and our system required a data connection to function. We shipped the Nokia N95 with our own local Telco’s SIM and hoped for a good 3G data connection.

A couple of nerve-wracking weeks (and an $800 data-roaming bill, oh well…) later, and we got the good news – we were in the semi-finals!

An extra bonus: all semi-finalists received a free Nokia N95!

The goal of a live streaming system such as m-View is to deliver a high-quality media stream from one location to another with the minimum of latency, which is basically the time between an action happening in the real world and that action being played at the other end of the media system. The more latency that a stream has, the less "live" the stream becomes.

The threshold for what an average person considers "live" varies, but it's typically well under half a second. When you think about it, half a second isn't an awfully lot of time for all of the things a streaming media system needs to do - to capture a video frame, compress it, ship it (potentially) halfway around the world, decode it, synchronise it to an audio stream and display it to a user - so the streaming system has to be pretty clever about what it does.

Probably the single biggest issue for any media system is that streaming media has fundamentally different requirements than most Internet traffic. Most data transfer on the Internet is very bursty - occasional spikes of activity with long idle period in between. But streaming media requires a sustained data rate.

Let's take a web browser as an example: a web browser spends nearly all of its time just waiting for the user to click on a link. Once the user clicks on a link, the web browser sends a request to the server for a page (a data transfer) and the server sends the page content back to the browser (another data transfer), and then goes back to waiting for the user to click on the next link (idle time).

Streaming media, on the other hand, requires sustained data transfer - the media system needs to receive the same data throughput for the entire duration of the media stream or the stream will break down. As most of the traffic on any given network is bursty, most networks are set up to favour bursty traffic over sustained transfers. This setup almost guarantees that all network connections start to behave like bursty transfers even if they're not, with the bandwidth available for the stream going up and down as the network tries to cope.

The traditional solution to this problem has been store up some media before starting to play the stream back. This approach, called "buffering", helps in two major ways:

1. It smoothes out the peaks and troughs of the network and gives the illusion of a sustained data transfer, and
2. It gives slower networks a head start - the network doesn't have to deliver data quite as fast because the streaming system already has some data it "prepared earlier".

Using buffering to manage bandwidth has a drawback (and it's a major drawback for a live system such as m-View): it introduces a hefty amount of latency into the system. Most of the webcasting systems out in the market have buffering times of over 15 seconds - which is great for webcasting, but makes them all but useless for any situation that requires real-time interaction between a viewer and a broadcaster.

On average, the standard m-View product has a system latency of around 200 milliseconds - that's 1/5 of a second - which allows m-View viewers to have useful, real-time interaction with the broadcaster. At that sort of latency, we're skirting fairly close to what's possible over the public Internet while still presenting a high-quality, synchronized audio & video stream. But we're always looking for new ways to improve it even further.

Streaming video from my mobile? Why would I want to do that? Isn’t this just a solution looking for a problem? I don’t get it!

Well maybe but before we tackle that question let’s step back a quick moment. Mobile phones today are becoming much more powerful than ever before. Even the most basic phones can capture pictures and video (just check out your kid’s latest phone - heck get them to show you how to do it on your phone!). And now with the rolling out of high speed data networks by most telecommunications providers, the technical limitations for sending video from your phone has been eliminated. You now have a phone that can capture video and a network that can send that video live, so what’s next?

When I sat down to write this, I was really excited to explain the intricate details of how the technology works. But I think most people just want to know "what can it do for me?" It really did not take me too long to come up with a short list that should demonstrate several uses.

First, professionals like real estate agents and moving consultants could use video streaming to provide virtual open houses in real-time. If you were unable to attend an open house in person due to prior commitments or practicality (ie: another city), the agent could walk you through the house and you could give feedback and make requests to which the agent can respond immediately (please show me that kitchen again). Moving consultants could perform the same walk-through services, including: house purchase, helping choosing a kids school, neighborhood features, etc. This would be a great differentiator in the crowded profession. As a recent migrant to Melbourne I would have appreciated such service when I was house-hunting!

A more personal use of video broadcasting could include being able to view little Johnny’s (or Jackie’s) recital/sports game/presentation to the class/etc for absent family members to be able to tune in, like Grandma in Birmingham or Auntie Jo in Adelaide. Since the technology displays to either a PC (over the Internet) or another mobile, the stream is readily accessible to anyone who wants to watch the event, even if they’re on-the-go. Even spontaneous events that can easily be missed like a first bike ride could be streamed live to grandparents and recorded for prosperity.

I had a few more examples lined up (ie: promotions of live events, out shopping and need a second opinion, updating your Facebook profile), but I think you get it. For the readers, try to think of some of the ways this technology can work in your daily life and email me your ideas. Or, if you just have a question or two, flick them my way – I’m all too happy to have a tech chat with a fellow mobile-ophile.

As a newbie to the Momentum family, I’m coming in with a relatively limited experience of video streaming, apart from a usage perspective (who doesn’t watch YouTube?!). So when the need arose to test the latest version of m-View, I jumped at the chance.

You may be thinking: is she insane, who gets worked up about software testing? Well, it may not be as exciting as my gaming friend who sits at an X-box all day, playing the latest version of their new Battlestar Galactica game (soon to be released) under the guise of “testing,” but it was a great chance to do something a little different: play with a video camera, pretend to be a roadie while saying “testing, testing, 123,” and ultimately gain some in-depth insight into m-View.

To give you some background, this latest m-View development further enhances the usability of m-View by monitoring and dynamically adjusting the rate at which m-View video is being broadcast, as changes occur within the network. This is particularly valuable when using connectivity with a fluctuating bandwidth, such as a WLAN or the NextG network. Variations in upload speed are especially significant when dealing with video streaming, as unexpected drops in speed will congest the network with excess data, which results in a poor experience at the viewing end. 

Now, as someone who has done their fair share of testing over the years, I thought I’d have a fairly easy time of things. After the initial routine and standard usability tests, I was looking forward to being out and about in a car filming the scenery. All, of course, while testing our bandwidth management over the NextG network. But, if you have ever had the joy of software testing, you will know that when you throw in uncontrollable attributes (such as a changeable bandwidth), you may understand the extreme frustrations I faced when attempting to monitor bandwidth restrictions against what I was seeing on the m-View Broadcaster and Viewer. Then add to that the fun of trying to reproduce the tests!

So unfortunately, although I did have my fun in the sun for a couple of hours, and a lovely trip to Williamstown, it was back to the office for me to push on with controlled testing.

To help me emulate my fluctuating bandwidth, but in a controlled and measurable manner, there are rather handy software tools that allow the throttling of bandwidth while viewing the actual upload and download speeds.

If you haven’t come across this before, bandwidth-throttling software in its usual application is used for bandwidth intensive devices, such as web servers, to limit or “throttle” the quantity of data it sends or accepts within a given time. This is to ensure that during peak times data congestion issues, such as server crashes, are avoided.

Making use of this software for our testing allowed for controlled, reproducible tests and results, without which our efforts in testing would have been monumentally more difficult, and the fine-tuning of the various features extremely time-consuming.

And so I have had a trip to Williamstown, established myself as an upcoming movie star, and gained insight into m-View just by being a tester for a day (or five). For the m-Viewers out there, you can look forward to the fruits of my labour becoming available in the form of a new release of m-View later in the year.

Whenever we go to see a client about our video streaming capability, they always end up asking us about the NextG network. Fair enough. After all, for the last 5 months Momentum has been the poster child for the capabilities of this network and probably 98% of our clients are either using or thinking of using mobile technologies for the transfer of real-time, live, streaming video.

Starting with the Victoria Police G20 project in Melbourne 2006, we've been out and about testing the NextG network from all sorts of locations and in different conditions. Now that we're working with most Public Safety agencies in the country, this is important so that we can accurately advise our clients on the effectiveness of this new network.

I am pleased to tell you that from our experience it is at least as good as they say it is and in some cases even better.

Recently, we took part in a couple of tests for Public Safety agencies to help them assess both our technology and the networks capability to deliver their overall video streaming and monitoring requirements. This involved testing from both the ground and in the air.

Now, NextG has not been designed for use in the air, but that's okay, neither has any other mobile phone network. That's because their customers are usually walking on or driving around on the ground. But, like all wireless communications networks, the coverage area is not exact and will depend on a number of environmental factors. For us we wanted to know how much "bonus" coverage was available and could be used for applications in the air.

Being able to partner with our customers to conduct test like these also puts Momentum at the forefront of live video streaming development in mobile environments and makes m-View the best in class for wireless video streaming. From the tests conducted so far we have been able to identify specific characteristics that we compensate for when developing our Network Management Engine (NME). The NME is the core component that allows m-View to automatically compensate for the fluctuations in conditions of wireless networks whilst providing real-time, live, video feeds.

The results of the tests conducted in various states around Australia, mainly in helicopters, has proven to us that we are able to provide Public Safety agencies with a compelling video streaming capability which, without Momentum's m-View and Telstra's NextG network, would not otherwise be possible.

As someone who generally develops desktop & server applications, finding myself the world of PDAs and mobile phones has been a bit of a shock to the system. In many ways it has been like stepping back into the 1980s - most of the things that a desktop developer can take for granted these days are gone:

• Blindingly fast processors: Gone.
• Ridiculously large displays: Gone.
• Staggering amounts of memory: Gone.
• Functionally unlimited disk space: Gone.

Of course, it's really not as bad as all that. While PDAs and phones lack some of the conveniences of a modern desktop system, they still easily outperform most desktop machines up to the mid 1990s - in addition to having multimedia and networking capabilities that those old-school PCs couldn't even dream of.

It turns out that the biggest hurdle for me has been cultural rather than technological.

In the desktop world - the world of Microsoft and Apple - the application developer is king. If a platform has no developers, no-one produces applications for that platform for people to run, hence no-one buys that platform and the vendor withers & dies. One of the reasons Microsoft is in the position they are is that they fall over themselves to take care of their 3rd party developers. The developers use that support to write great applications, which makes the platform more attractive and ends up selling lots of copies of Windows.

In the mobile phone world the vendor doesn't need application developers so much. With all the features already packed into phones these days – phone calls, text messages, MMS, etc. - third party applications just aren't as critical to phone manufacturers as they are to companies like Microsoft or Apple. The culture of fostering development for your platform doesn't really exist in the mobile phone world, and up until now it hasn't needed to.

Phones have been (by and large) closed systems and developer support hasn't been an area where the manufacturers needed to spend money in order to compete.

Nokia's slogan for their new N-series phones is "It's what computers have become". In many ways that's true, but it is also true to look at it the other way - that phones have become small, general-purpose computers. This means that the phone manufacturers are having to begin dealing with developers in the same way that Microsoft does, and that isn't something they're used to. I also think they're finding it hard going - we programmers can be a tough audience.

Generating and fostering a developer community is a tricky thing. It takes comprehensive & well-organized documentation, lots of sample code and rock-solid tools. Above all else it takes the recognition that developers are an important part of driving the popularity (and hence sales) of a platform.

If they get it right they'll have developers using their devices in ways they would never have dreamed - which might sell the odd phone or two in the process.