Europe’s TV standards group DVB has designated GEM as its primary middleware technology in place of MHP - after standardisation body ETSI adopted it as a self-contained specification.
GEM - which stands for Globally Executable MHP - was, as its name suggests, a DVB-independent derivative of MHP (Multimedia Home Platform), a Java-based system originally proposed as a common European interactive TV platform.
Now, GEM becomes a standard in its own right, eclipsing MHP.
The original idea behind MHP was that its inclusion of a Java Virtual Machine would enable interoperability of interactive TV applications across different digital TV platforms. But in practice, MHP implementations turned out to be stripped-down, customized affairs that were only nominally independent of the platforms that deployed them.
MHP boxes also generally cost more than ones using interactive technologies such as OpenTV or MHEG, a factor which was exacerbated by an unexpected hike in licensing-fees in March 2006. MHP interactive environments also proved costly to maintain.
Thus, apart from MHP’s success in colonizing the Italian DTT market (the result of a government subsidy being made available for interactive set-top boxes), the middleware was never widely adopted.
GEM has now emerged as the more significant technology: (a) it is incorporated into the high-definition optical disc standard Blu-Ray; (b) it forms the basis for the US Opencable standard (under the brand ‘tru2way’); and (c) it underpins Brazil’s interactive middleware standard Ginga-J.
GEM is also compatible with the US and Japanese digital terrestrial broadcasting standards.
DVB claims that GEM/MHP technology is currently in around 50m devices worldwide, the vast majority of which are likely to be Blu-Ray players, in Farncombe’s view.
However, the trend towards hybrid decoders and connected TVs indicates that such broadcast-specific interactive TV platforms have probably had their day. In the future, interactivity on the TV is likely to use the broadband link and to derive from existing, tried-and-tested Internet technologies, with new standards such as Europe’s HbbTV and the UK’s Canvas pointing the way.
GEM has found a place in this world, mostly in systems which are at least in part one-way systems. In such systems the hig local interactivity that can be created with Java is important.
However, in the broadcast world there have been very few interesting applications that can be built with one-way interactivity. True depth and richness of content is essential and can only be offered by a IP connection and a server (with typically regularly refreshed content). I.e. fundamental for the success for interactive applications are IP / server technology; the strenghts of one-way interactive functions are substantially less important. So IP / server based applications will be key and light clients are more flexible and more easy to target than heavy ones.
The technology details are subtle: GEM, MHP, OCAP, HTML (+ javascript), even MHEG “can do many of the killer” app’s as client engine to a server based application. The opening discussions around HbbTV (CE-HTML being critisized by MHP and MHEG technology companies) and the recent DVB statements are surreal in not acknowledging the server based application reality as being the crucial difference with the past. What is the most appropriate client presentation engine to target from a IP based interactve application server?
Well it is interesting to see that the “methodology argument” in interactive TV has taken a new turn - sorry a U-TURN. When HTML was offered up to the DVB in the late 90s and early 2000s it ran on inferior networks and ISPs that could not deliver more than 96 or 128KBits/second. It was never designed for TV markets and was considered “not fit for purpose” in TV land. ATVEF tried, DASE tried etc. So the TV Industry built a solution in the DVB and selected a certain path (Java+Browser) and the DVB has stuck to it which can be applauded. there are over 77million deployments of GEM and those can be seen at www.mhp.org. Even the DVB’s Technical Committee - TM-MIS review on Next Generation Middleware acknowledged that there was nothing technically that could change opinions on the way forward but that “Methodologies” still reign as the differences between opposing camps in interactiveTV. funnily enough during the 10 years of “MHP bashing” no Broadcaster or Operator has selected any smaller, less expensive, presentation based alternative in Europe…because they had no Business model. MHEG5 was touted as the answer… its deployment in ALL European CE and STB equipment still did not encourage Broadcasters to take up iTV services. Not the technology but the Business Model. Today the business model in “Connected TV” is Free VIDEO over the Internet…accessed by Widgets or Browsers…how long before that is not sustainable? There are no Applications Sets for HbbTV such as exist in Broadcast today there is a lot of Slideware. EPGs, Bound Applications, et al, even MHEG5 has a large portfolio but HbbTV has shown almost nothing. The UK obsession with the iPlayer which is a VOD service on the Internet - Specific to a single content provider has found favour in Europe…French TV etc has an equivalent. The whole fragmentation of Channels has arrived on the Internet…great now what? Make another “Standard” for interactive that does not need the internet? A complex business model is before all of us and so lets see if we can make it happen all over again or just repeat the past with another technology solution to the same problem. So what happened to Broadcasters that got caught out by not deploying anything over 10 years? The CE manufacturers came along with an RJ45 connector on board - Now they are stealing their Broadcast lunch (so we are led to believe)…shame on them (the broadcasters) they had the chance-could have selected any number of technologues and passed the pain barrier like the UK and Italy. They could have kept control of their market and not seen the hyped market meltdown that is predicted by Connected TV…But then we factor in the ubiquity of Broadband (its not 10% coverage anywhere in Europe) …ISP connection of proper European wide coverage capable of delivering Qos video speeds - tie that to different legislation in each country and EU regulations and we will see that there is a long way to go.
It is not Server Side Applications that are the issue, GEM and apparently HbbTV both do that…It is is the fact that an “Execution Engine” (A sort of virtual computer) resides in the GEM specification as its core. The Browser element which in 3 European deployments is a forerunner of CE-HTML called DVB-HTML…any other Browser can also reside in a GEM stack… and as a consequence you get the best of Java - Multi-Threading, Multi-Instance Applications AND WEB Browsing and all the server-side that HTML now seems to offer over HTTP…ironically the Japanese Broadcaster NHK have just dropped their HTML solution after 10 years in Japan and declared in a White Paper at IBC2009 that it was not as good as an Execution+Browser combination for STBs and iDTVs. Finally the DVB cannot just drop or walk away or ruin deployed Specifications without seriously impacting on businesses and Companies that have supported them… and as such it is careful how it evolves or devolves its portfolio.
Had the CE-HTML been offered up to the DVB correctly it may have seen it as a replacement for DVB-HTML and we would all be seeing a different landscape. But the CE Manufacturers have a different business agenda and in that more differences are opened in this complex fragmented Digital TV market. The more we knock each other over methodologies the more the fragmentation increases. At the end of it all it is all about revenue for unique solutions and the IPR a vendor can squeeze into a spec - this is all about - History nicely repeating itself.