EBU Technical Review : No. 290 (April 2002)
Today's teletext is based on the "World System Teletext" developed in the UK by the BBC and IBA in the early 1970s. It was conceived mainly as a programme-associated text display on the television screen. It allowed transmission of 40 characters per line in 24 rows and in eight colours. However, the available "block mosaic" graphic characters offered little creative potential (see Fig. 1).
In 1994, under the aegis of the European Association of Consumer Electronics Manufacturers (EACEM), work started on upward specification of teletext from the so-called level 1 to levels 2 and 3. The two major chip manufacturers, Siemens and Philips, eventually agreed on a compromise – level 2.5 [1].
The 1997 Internationale Funkausstellung (IFA 97) saw the market launch of the first sets compatible with this display level. It was soon clear that there was little to be gained from modernizing teletext by raising the level. Despite the improvement brought about by the introduction of teletext level 2.5 – with 32 colours and improved graphics – the big gamble did not come off because it had to make allowance for the old level-1 text decoders still in use. Even the possibility of transmitting simple pictures as bit samples (DRCSs – Dynamically Redefinable Character Sets) was not up to expectation. This is because the level 2.5 graphics are only two-colour and are confined to too small a surface. The production of level 2.5 graphics with complex software tools, taking level 1 into account, also complicated the lives of teletext editors and, hence, adversely affected the changeover to level 2.5. What was more, the advertising industry found the "added value" of this improved teletext level was negligible, and this was why that industry, too, showed little interest in an increased use of level 2.5.
Added to this is the fact that the television viewer who has a PC is accustomed to a sophisticated graphical user interface, which he/she navigates by means of a mouse. Today's teletext user already finds entering the three-digit page number too complicated. Despite easier teletext navigation with TOP 1, and aids such as "page catching" 2, these tools already look antiquated.
In spring 1997, the television receiver industry in an EACEM Working Group (led by Jan van Lier of Philips, Eindhoven) was looking for a successor system to teletext which was expected to meet two requirements: it had to be cheap, and it had to offer functions familiar to PC users. The system also had to be evolutionary, not revolutionary – i.e. it had to keep the existing teletext standard within its sights.
This led the IRT in Germany to propose – among other things – that internet content should be transmitted along with standard teletext. This idea was accepted and the TeleWeb consortium was launched [2]. Its members are:
The aim of the consortium was to develop TeleWeb technology as an open standard for a new generation of teletext services.
TeleWeb demanded the redesign of existing text decoder components. They had to be made graphics-friendly, since internet pages containing pictures need at least 256 colours with a resolution of 640 pixels per line, and 480 lines. Navigation, as in the case of internet browsers, was to be via colour-highlighted address buttons. Since the television viewer does not have a mouse, he/she navigates with the aid of arrow buttons and an OK button on the remote control. HTML version 3.2 was adopted for the displayed internet pages (see Fig. 2).
It was found that these requirements could be met and the result was a completely new construction for the teletext chips hitherto used in receivers. The receiver manufacturers felt able to fix a price below DM 40 for TeleWeb chips, a fact attributable to a predicted fall in the price of computer memory components which account for a hefty proportion of the costs. Now, an even lower cost is being envisaged. At present, 5 MB of memory capacity is planned for TeleWeb. In comparison, a complete teletext cycle needs only about 1 MB of memory.
The name TeleWeb is intended to spotlight the link between television and the worldwide web. TeleWeb was demonstrated by ARD-Text in conjunction with SFB's ARD-Text at IFA 2001 in Berlin. ZDF provided TeleWeb pages for the Phoenix company. Further generators of TeleWeb pages were:
TeleWeb's concept of combined transmission of teletext and web pages confronted its developers with a host of problems which are discussed below.
TeleWeb must ensure that older decoders can go on receiving traditional teletext. This is achieved through joint compatible use of the vertical blanking interval (VBI) in analogue television. The basic version of TeleWeb, the so-called "Profile 1", does not need a two-way channel. The TeleWeb editors generate or select particular pages in HTML format and feed them into the teletext transmission system. There, the selected pages are transmitted in "Packet 31" 3. Thus, this system only allows viewing of pages preselected by the editors. For "Profile 2" TeleWeb, a two-way channel via a modem is planned. This will enable the user to obtain a proportion of his/her selected pages via the two-way channel, thus reducing transmission capacity demand on the VBI. Nevertheless, the majority of HTML pages will be transmitted by broadcast means. Surfing the Internet will only be possible in the interactive "Profile 3" – also with a two-way channel – and will no longer require transmission in VBI.
In the case of "Profile 1", the system must still share with teletext the scarce resources available in the VBI. Although this is limited to about 150 kbit/s, it is possible to transmit many web pages without noticeable lengthening of the cycles in the teletext service. This is achieved, first, by effective compression techniques and, second, by use of so-called headline repeats. Thus far, teletext broadcasters have been obliged – in order to allow for older text decoders – to insert waiting loops consisting of needless repeats. Such repeats, of some 5 - 10% of cycle time, can be used for TeleWeb. This type of transmission is called "short service". It is intended as a package for important navigation and news pages which viewers, when zapping past, can read immediately. Another form of TeleWeb transmission is the "full service" mode. This enables more web pages to be transmitted during off-peak viewing periods (e.g. early morning), and here the broadcaster decides not only when, but how much TeleWeb is packed into the VBI This type of transmission is called dynamic allocation; the broadcaster does however need the appropriate software.
Although TeleWeb makes elegant use of residual teletext capacities, the transfer or updating of Tele-Web pages takes additional time. Updating, where whole web pages are reloaded, can easily take 20 - 30 minutes and so should be done at night if possible. However, reloading of individual web pages can be carried out at any time with the 5 - 10% residual capacity (see above) of present-day teletext and, thus, is no problem. If TeleWeb is a success, the share of this service can progressively be increased in the VBI over a long period of time – and the share of teletext signals reduced by the same extent (see Fig. 3).
It is expected that TeleWeb decoders will store the complete teletext cycle and make it available to the user immediately – i.e. without waiting times. Thus, elegantly and almost in passing, TeleWeb fulfils a long-standing wish of teletext users: immediate access to teletext pages without any waiting times! Since the television receiver uses the same memory store for teletext and TeleWeb, and the text decoder "understands" both formats, it is logical that each transmission system should refer to content in the other format. This is done by means of hyperlinks which, after all, are typical of the HTML format. By choosing a colour-highlighted teletext address button in TeleWeb, the viewer can access a teletext page direct. The complicated three-digit page number is a thing of the past. To return to TeleWeb, the user simply presses the TeleWeb symbol on the corresponding remote control. Conversely, the user can jump direct from an appropriately referenced teletext page to a TeleWeb page.
A further advantageous feature of TeleWeb is the support of "trigger" pages. For this, a symbol is temporarily displayed on the television picture, referring to a TeleWeb or teletext page of relevance to the programme being screened 4. In TeleWeb Profile 1, reference can be made to a teletext page or an (already stored) TeleWeb page. TeleWeb with Profile 2 or 3 gives an address (URL) on the worldwide web. Pages thus made available in the programme-associated data service then provide further information on the programme. They can be selected simply by pressing a button on the remote control. Use of trigger pages does, however, presuppose a complicated interplay between transmission control and the teletext/TeleWeb editors: the trigger pages must bear a temporal relationship to the ongoing television programme, and also be up to date.
The use of trigger pages is likewise possible in teletext without the TeleWeb service: teletext pages 5 containing internet addresses (URLs) are broadcast. This was first demonstrated by ZDF, in conjunction with the Loewe company, at IFA 2001. The triggers create a wealth of new openings – for broadcasters and advertising companies – to highlight their content.
Basically a television receiver works using an interlaced scanning technique, in which half a screen is scanned every 20 milliseconds. Two half screens combined give the whole screen, consisting of 575 visible lines of 720 pixels each. This maximum theoretical value is often not attained when simple colour picture tubes with far lower resolution are used. With pictures of strong contrast, however, screen flicker at 25 Hz occurs which the eye can perceive and the brain finds disturbing. This arises from the nearly 50-year history of the PAL television system and the earlier available technology. Hence, to avoid flicker, teletext prevents varied picture content between the first and second half screens, since this would further halve the vertical resolution.
In contrast, a computer screen works using a non-interlaced scanning technique and a repetition frequency that exceeds the inertia of the human eye. Also, because of its finer "pitch", the resolution of a computer screen is well above that of a television screen.
Thus, web content that is intended for the computer screen cannot automatically be displayed on television screens. Small scripts become illegible and large ones fill the entire screen. The TeleWeb specification therefore reduces the seven possible type sizes in HTML to four: the largest and smallest are converted into the second-largest and the second-smallest. Moreover, not all fonts are equally suitable, and so TeleWeb makes use of the Tiresias font, specially designed for the television screen.
The next-generation TeleWeb decoder, with a two-way channel, opens up new possibilities and new uses for the television viewer since, in principle, he/she will have full access to the worldwide web – and not only the content preselected by the editors (see Fig. 4). However, this raises a raft of technical, legal and operational problems which still have to be settled.
The above-mentioned problems of interlaced scanning affects TeleWeb in all its profiles. In Profiles 2 and 3 – with a two-way channel in particular – there are additional difficulties specific to the Internet. Many web pages today include streaming video (MPEG-4, Real Video) and audio (MP3, MP3-Plus), as well as animations produced by Flash, Shockwave etc. With a computer, the relevant decoders (browser plug-ins) can simply be downloaded. Often enough these programs generate error messages not acceptable to television receivers. In the worst case the computer crashes, i.e. it finds itself in a software deadlock from which there is no escape 6.
To prevent this scenario from even arising, TeleWeb ignores all these streaming web objects. This includes Java and Java Applets. The position is different for JavaScript, which allows logical calculations in the TeleWeb browser and thus lightens the server's workload. The use of JavaScript for the forthcoming interactive TeleWeb is at present under discussion. The working groups are also in consultation about the use of cookies. Since cookies contain information of relevance to the user – e.g. the receiver's switch-on time and the type of information read by the user – they are not problem-free from the data protection viewpoint. It should at least be ensured that the user is informed at all times of any private data contained in the cookies. He/she should likewise be given the opportunity to decide whether to allow these personal data to be sent to the provider concerned.
Such problems make it necessary to transform or pre-filter web pages into TeleWeb-usable HTML pages on TeleWeb Profiles 2 and 3. This process ("transcoding") means "translation" into web pages which are displayable on a television screen. At the same time as the transcoding (which can also be automated), a security check is carried out. This ensures that only pages that conform to the TeleWeb specification are transmitted. It also allows the elimination of internet pages that glorify violence or are unsuitable for children.
Initially, the two-way channel will be provided by a built-in modem. For cost reasons this will not be one of the high-speed systems increasingly used in ADSL networks or Powerline. Nor is it strictly necessary, since the TeleWeb specification does not allow streaming – which needs a great deal of bandwidth – and furthermore the picture content is confined to "lean" forms such as JPEG and GIF. Current thinking involves a bit-rate of 56 kbit/s as used today by many internet users with analogue modems. The TeleWeb specification enables the TeleWeb user to choose from different providers who can compete on the basis of various tariff models. Naturally, TeleWeb – in using the telephone network – is not cost-free, unlike TeleWeb Profile 1 whose content is receivable only by broadcast means and thus is freely available 7. To connect a two-way telephone channel to the internet, "servers" are necessary. The internet content on these servers is also subject to the need for transcoding the web pages made available (see above).
The two-way channel will render services such as e-mail possible. As there will not be a built-in "e-mail client" in the TeleWeb decoder, a "remote client" facility will be used. With this, all incoming and outgoing mail is transferred to a remote server and channelled to the TeleWeb user who enters a password. This means that the work is shifted to the server and renders possible low-cost implementation in the television receiver, since no special e-mail protocols are needed. Above all, it is expected that the possibility of sending e-mails to the home television receiver will be especially attractive to user groups with a rejectionist attitude to home computers.
Home shopping and home banking are further avenues currently being explored. Since work is still in progress on second-generation TeleWeb, state-of-the-art internet security technology can be incorporated at this stage.
However, the main advantage for television viewers that are using the two-way channel will be access to the full TeleWeb service. Full access to the Internet is also conceivable; it is limited only by the possibilities of the HTML 3.2 standard employed. It is estimated that, after transcoding, it will be possible for the vast majority of web pages to be displayed by a TeleWeb receiver.
Set-top boxes providing internet pages on the television screen have been around for some time. The best known of these was Grundig's "Web Box WB 1" a few years back, though it worked with a proprietary transmission system and thus had little success on the market. Systems like that of Satway Business Communication, for commercial use in services and marketing, use the vertical blanking interval.
Just as TeleWeb was being introduced in the German-language area of Europe, the French TAK initiative started to be discussed. This is a similar system to TeleWeb but it also has a built-in two-way channel in the basic version. TAK was developed out of the earlier US ATVEF (Advanced TV Enhancement Forum) system and today is promoted chiefly by the French firm Thomson Multimedia. Using HTML 4, this system makes excessive use of VBI capacity and is not compatible with teletext. From the European viewpoint, it is better suited to countries without teletext in the VBI Here it must be realized that teletext services on any scale exist only in the UK (its country of origin), the German-speaking countries, Switzerland, the Benelux countries and Scandinavia, as well as – increasingly – southern and eastern Europe. In other countries, no allowance need be made for teletext.
In France, teletext is virtually obsolete – due to the early introduction of the Minitel system, tied into the telephone network. Minitel – familiar in Germany as BTX – rapidly gained ground in France, thanks to cheap call rates. Consequently, both France and the USA can be classified as "developing countries" in regard to their use of the VBI in analogue television and, with TAK, they have found a gap in the market. Thus, the bilingual (German and French) channel ARTE, whose home country is France, at present relies on TAK as the multimedia component for its few teletext pages.
The specification of TeleWeb entered a critical phase when some companies supported the use of MHEG-5, which is an open standard developed by the Multimedia and Hypermedia information coding Experts Group in ISO/IEC [3]. MHEG-5 is a multimedia format with similar displays to the Internet, but programmed in its own language. Like TeleWeb, MHEG is optimized for the television screen. It is, however, chiefly designed for transmission in digital television systems and so is not optimized for the VBI in analogue television. It is mainly to be found on DVB-T services in the UK. So, when EACEM voted in 1997, there was only a narrow majority in favour of HTML instead of MHEG-5 for TeleWeb 8.
Another system is OpenTV [4], a proprietary multimedia standard from Sun Valley (USA) for DVB but containing more interactive components than MHEG 9.
In principle, public service broadcasters in the German-language area support non-proprietary systems, since only they ensure a "horizontal" market. This means markets which, as far as possible, use open royalty-free systems which are available to all. Consequently, it is logical that a new multimedia standard (MHP – Multimedia Home Platform) is being developed under the aegis of the DVB Project [5]. This standard is based on the JAVA language 10 and meets the above-mentioned requirements. Unfortunately, due to its bandwidth needs, it cannot be transmitted in analogue television but is restricted to digital television.
With the spread of DVB services, and the greater bandwidth it offers for new associated services, it was clear to the TeleWeb consortium that the life expectancy of TeleWeb in the analogue television VBI would be limited. However, TeleWeb is not fundamentally tied to an analogue transmission mode. Since the new digital services of the future will probably also display internet pages, we can presume that TeleWeb must offer future compatibility. For example, plug-ins for TeleWeb are conceivable in a (digital) MHP platform on which TeleWeb could also be received and displayed compatibly in the MHP standard. A characteristic of worldwide development is the convergence of technology – a merger of the Internet, television and (mobile) telephony on a single "multimedia terminal". This will be supplied via a variety of transmission channels, thus rendering possible a variety of business models, i.e. attractive offers or marketing modes for the manufacturers and customers. In this scenario, the public service broadcasters must fight their corner and contend for their market share. The fact that present-day television is still largely based on analogue transmission makes TeleWeb quite a courageous venture.
Dipl. Ing. (FH) Werner Brückner is a Research Engineer at the Institut für Rundfunktechnik (IRT) in Munich. He is convinced that high-quality innovative products, offering the viewer tangible benefits, are bound to succeed. TeleWeb, the successor to teletext, could develop into such a product.
Footnotes
| * | Head of EBU Publications: | P. Jaquin |
| * | Editeur Responsable: | P.A. Laven |
| * | Editor: | M.R. Meyer |
| * | French Editor: | E. Piraux |
| European Broadcasting Union Case postale 45 Ancienne Route 17A CH-1218 Grand-Saconnex Geneva Switzerland techreview@ebu.ch |
 |
