Comments on: MHP was no GEM: the jewel in interactive TV’s crown is likely to be the Internet http://www.connectedtv.eu/mhp-was-no-gem-the-jewel-in-interactive-tvs-crown-is-likely-to-be-the-internet-313/ Talking about TV's future Fri, 10 Sep 2010 04:26:10 +0000 http://wordpress.org/?v=2.3.1 By: Anthony Smith-Chaigneau http://www.connectedtv.eu/mhp-was-no-gem-the-jewel-in-interactive-tvs-crown-is-likely-to-be-the-internet-313/#comment-64194 Anthony Smith-Chaigneau Tue, 27 Apr 2010 12:00:37 +0000 http://www.connectedtv.eu/mhp-was-no-gem-the-jewel-in-interactive-tvs-crown-is-likely-to-be-the-internet-313/#comment-64194 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. 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.

]]> By: Marnix Vlot http://www.connectedtv.eu/mhp-was-no-gem-the-jewel-in-interactive-tvs-crown-is-likely-to-be-the-internet-313/#comment-58686 Marnix Vlot Wed, 24 Feb 2010 21:23:34 +0000 http://www.connectedtv.eu/mhp-was-no-gem-the-jewel-in-interactive-tvs-crown-is-likely-to-be-the-internet-313/#comment-58686 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? 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?

]]>