Tuesday, July 24. 2007
We were initially asked to present on the Mashup TV 2.0 session held last week, but when it changed dates we were unfortunately unable to make it owing to client commitments (due to IP multimedia projects ironically). However, reading the blogs seems like a good time was had by all, except that a number of comments showed a similar thread - that it felt a bit disjointed, or that no-one defined "Web TV".
To be fair to the Mashup team, it is a large and still emerging area with (just a small !!) amount of hype attached, so here is a piece of background on the industry that may help.
This paper itself has a history, we were asked to write it early in 2006 by a respected journal in the industry, and talk about the evolution of what we then termed the TV "Broadcast Website" rather than Web TV - (This is all pre YouTube, Joost, Babelgum etc etc remember) so some of the terms may seem a bit arcane now, a whole 18 months later.
At any rate, the piece was not used, we were told that we were waaaay off beam. We were planning to use the same basic structure here - albeit updated - at the Mashup, (plus a Part II on current players which we will publish later this week), so see for yourself, 18 months on, just how off beam we were....
BUILDING BROADCAST WEBSITES
The Broadcast Website today – and tomorrow
Over the next few years, the impact of Interactive IP based TV services will define a new type of video media that is far more interactive, and will change the way media is used. The IP Broadcast Website will move from the current model - a Broadcaster’s website pointing to its broadcast services - to being a Website that the customer uses to manages the content.
There are a number of competing approaches to “IP based TV” today. This article focuses on 3 main areas to consider in designing an IPTV broadcast website.
(i) IP Broadcasting Technology
(ii) Core Broadcasting Website Processes
(iii) “Web 2.0” changes
1. IP Broadcasting Technologies
There are 3 main “Internet TV” technologies emerging – fixed line (mainly xDSL based) IPTV, and mobile broadband based (M-TV), plus an interesting hybrid - WiFi based TV.
(A note here - the article assumes some familiarity with IP TV and the differences between transmission over wires vs broadcasting over the airwaves)
Internet Protocol TV (IPTV)
There have been many excellent IPTV articles published (such as this one of ours), this article will focus on the issues facing the Broadcast Website in particular. IPTV today gives a TV like experience already if the evidence so far is anything to go by. In the future 14Mb/sec+ per home (allowing multiple TV feeds) using the improved ADSL2+ format is promised. Moore’s Law also suggests that compression algorithms will continue to get better.
Mobile TV (M-TV)
With the launch of iPod Video and early evidence from the trialling of M-TV services, mobility will clearly have an impact on TV services in the future. At present Mobile TV technologies only exist in trial mode in Europe and the USA. There are 2 essential approaches:
- Over existing 3G networks, a higher speed 3G protocol (c 1.8 Mb/sec) called HSDPA (High Speed Downlink Packet Access) is being trialled today. A new approach called MBMS (Multimedia Broadcast and Multicast Standard) is also being proposed over existing 3G W-CDMA networks.
- Over Broadcast networks - via DVB-H (Digital Video Broadcast - Handheld) protocols, or, in a recent BT trial, using existing Digital Audio Broadcasting (DAB) technology.
There are technical issues with these new mobile technologies. Both DVB-H and HSDPA would require new infrastructure investment, and it is unclear which technology/s will really win out. South Korean experience is that after initially rolling out mobile streaming video services, the mobile point to point networks became congested and a separate satellite network (DAB based) was required to broadcast mobile TV service.
Wireless IP TV (WiTV?)
WiTV is limited today because so little commercial Wireless IP is available. However, given that it has many of the benefits of mobile IP TV without the costs of getting the higher bandwidths, works fairly easily with fixed line IP TV, and that many Municipal area WiFi services are springing up, this could be a very interesting space to watch in future.
2. Core Broadcasting Website Processes
There are 4 main processes – Ingestion, Repurposing, Distribution, and setting up the required Customer Environment.
Ingestion
Content is taken from a (known) incoming source and format, (for example off a satellite receiver in MPEG-2 format), transcoded into one (or more) of a number of competing digital video protocols for output. MPEG 2 and 4, Windows Real Video, Real Media and Apple standards are the most common.
Content is handled in two major ways; (i) “live” content that has to be ingested on the fly for immediate distribution (for example a TV feed) and (ii) content that can be ingested, stored and then played out later (typically an “on Demand” sort of service).
Ingestion “on the fly” is riskier, and requires more real time processing power and bandwidth – but uses much less storage. Some basic metadata (data about the content) is usually added at Ingestion stage.
Repurposing
Repurposing content for distribution typically includes:
- Marking up the existing metadata further for users to interact with the media – both for the Interactive Program Guide, but also to interact in depth with the media – to search it, and say pull a series of clips of similar types of scene from different films. There are emerging standards (eg MPEG 7) but many other formats are used today. Interactive media can require a lot more markup (and repurposing overall) than straight broadcast media, because it is so flexible.
- Inserting additional data – for example adverts, security and rights access data, rich media streams and so on.
- Editing content – for example, for children.
- Transcoding the ingested content into other user requested formats for output, for eg if your site stores in MPEG 2 format and Real Media is output - and (yet again) to output at various bitrates for different user devices (much as streaming IP does today).
Handling content for “standard size” TV screens is fairly straightforward today. There are major issues with small screens (eg Mobile TV). Close-in headshots work far better than wide-pan shots where you can't really see the detail, and the size of the graphics needs to be increased (as anyone who has tried to surf the web on a mobile will testify).
In the future, users are also expected to want to record – and mark up - a lot of material themselves, and there is already software appearing that lets customers make and manage their own video blogs. Maybe we will all have our own Broadcasting Websites one day!
Distribution – Streaming, Unicast, Multicast and Peer to Peer systems
Streaming in Internet speak commonly means sending out IP audio or video media to a PC. Streamed media is not stored on the end user device, whereas downloaded material is. In Progressive Downloading media is streamed, stored and played from disk as close to real time as can be.
Strictly speaking all digital delivery systems - radio, television as well as the IPTV approaches below - are "streamed" media.
- Unicasting is the dominant IPTV streaming model today. The source streams an individual copy of a message to each requester only. It is good for Video on Demand (VOD) as it’s a one to one service. It’s not so great for “broadcasting” as transmitting a separate copy of the same piece video over the whole network to each requester has a major impact on bandwidth.
- Multicasting arose since both Broadcasting and Unicasting are inefficient ways of sending large amounts of the same content in a network. Multicast sends one copy of media as far down the network as it can before breaking it out to its recipient end nodes. It requires major changes to most networks, and today there are no true commercial Multicast consumer services (to our knowledge).
- Peer-to-peer (P2P) protocols let nodes arrange between themselves for media to be sent from those that have it, to those that want it. This prevents the main servers and network connections from becoming a bottleneck, so is very scalable. However, P2P raises many other technical issues, especially legal ones, as evidenced in the Audio industry today.
The Customer Environment
Today, IPTV media ingestion and repurposing is done at server side and sent to a fairly “dumb” client – the IPTV STB (Set Top Box) and increasingly the Personal Video Recorder (PVR). This architecture may be more due to IPTV’s evolution from DTV and Cable however. Home PC’s, Games consoles and the Web itself can all potentially do these roles, plus their other jobs to boot, and as they exist in many homes we can envisage these being increasingly used. In fact we can imagine a battleground emerging between which screen type is used - TV, PC or Mobile.
(Aside - in fact, as we later showed with our MyPCTV experimental rig, it is very simple to use a laptop as a set top box)
The overall trend in the Internet is towards “Webservices” –ie the Web is a service platform - much of the role of the PVR could potentially be done in the Web, and as IPTV standards crystallise it will be easier to take STB functions into the network - with no or just a very small client remaining. Now if that device were portable - say a PDA or high quality video Mobile device - that would be very interesting indeed….
Quality of Service
The 3 key drivers of IPTV quality are:
- Network Quality of Service (QoS)
- Contention
- Latency
The Broadcast Website cannot assume the core network has any QoS, and today nearly all IPTV operating deployments are based on some combination of rapidly scaling available bandwidth, multiple big servers as close to the edge of the network as possible, and prioritising video packets over others.
Contention is the number of other users on the same local node. Typically, consumer broadband is at a 30 – 50:1 ratio, so although early users will see great throughput, as users are added it will degrade the service for everyone unless more capacity is found somehow. A similar problem exists in 3G mobile and Cable (to a lesser extent).
According to most user trials latency is bad news – we are very impatient on our remotes, and a lag of more than a few seconds creates great user frustration, as “normal” TV is instant. Latency is a function of low capacity. If capacity is constrained then either (I) the backbone network will have to prioritise traffic (see QoS above) or (ii) the customer side equipment will have to buffer it as lost and delayed packets increase.
Web 2.0 Impacts
Emerging research indicates people are spending as much time on the Internet at home as they do watching TV. People are used to dealing with websites, and we believe the Broadcast Website of the future must be like a Website that broadcasts, and not a Broadcaster’s Website that points to their broadcast media.
Web 2.0 is a paper on its own, but the core trends for any Broadcast Website design are:
- The Consumer as Producer or “Prosumer” – customers increasingly produce and consume content, typically niche content – leading to the rise in value of the “long tail” of non hit based content so common on internet based services.
- The EPG is just another Search request – Good metadata means better searches, and good search is shown to be very effective in most arenas.
- Identity, profile and social networks – many web applications these days use the customer's voice – rating and tagging content, rating each other, and creating user self help communities for example will all be part of the Broadcast Website. We can imagine this behaviour in fact driving the scheduling.
- Customer Self Service – reduces operating cost, and can increase loyalty (or at least decrease frustration).
- Customer Analytics – Portals such as Google and Yahoo know a lot about their users activities. PCCW’s “Now” IPTV service in Hong Kong reportedly has much better economics due to its customer analytic systems.
Off beam eh ?
Saturday, July 7. 2007
Those nice people from Skinkers (just up the road here in London) have collaborated with Microsoft to build a peer 2 peer approach to getting live TV media onto a PC without a translating black box - Livestation. It uses Microsoft's Silverlight technology (and no doubt quite a bit more) to try and give a zero buffering, on the fly TV experience on the PC*.
Microsoft's, Steve "Blue Monster" Clayton has blogged it here, complete with video
Interesting approach, our experience is that it its darn hard to do this on-client without mediating appliance-ware or without something happening real time on the server side, so we assume the broadcasters will have to transform their output for this in some form or another.
* we've already applied to be on the beta test of course, to fire it up on our MyPCTV rig 
Is it a Joost killer - well, insofar as it streams TV direct to the PC it is, but there is no VOD element - so its more a "compete for the attention time" and thats where it potentially is a killer as it looks like there are far fewer moving parts to get right. As many other people have pointed out, Joost is its own Joost killer as its a walled garden selling stuff one can get elsewhere.
But thats just business as usual...
No, the really good story here is that a host of US based A List tech bloggers apparently were tripping over each other in the wee hours of the morning to announce this as the Joost killer, and have thus got lots of things wrong in their stories, and there is now much huffing and puffing going on to climb back onto the Blog Tower's High Ground.
It would appear therefore (reading Mr Scoble's recent missives for example) that the space for breaking news is getting more competitive for the A-Listers as various newer, brighter, shinier - and better informed? - commentators appear. We await with interest the denouncing of blogging as old hat by various A Listers as they flounce off to pastures anew, like Facebook.....
Postscript...in fact, it would appear there is such a Gaping Void emerging between what the A Listers desire and what We, the Virtual People want that a Declaration of Independence has been mooted.
Hide the tea.......
|
