TELETEXT – OLD DIGITS IN A NEW AGE

P.Weitzel1 and J.R.Hunter2

1 BBC Resources Ltd., UK2 BBC Research & Development, UK

ABSTRACT

Teletext is a well established method of delivering textual information to the home. For example, the BBC’sCEEFAX service regularly attracts 15 million analogue television viewers each week. As such it provides amature and stable source of “television friendly” content which can be re-published on the emerging digitaltelevision systems.

However, Teletext has other properties that allow it to support much more than just information services. Itexists in analogue, digital and MPEG forms, all available with accurate synchronisation in time. This makes itideal for the carriage of programme Metadata and sometimes essence alongside the programme video andaudio throughout the broadcast chain up to the point of final emission to the viewer. The BBC uses Teletextto distribute subtitles, automation status, scheduling data, AFD information, opt-out control and programmetimecode.

This paper will attempt to describe how Teletext is not only a valuable tool for existing analogue televisionservices but also has a place in the roll-out of new digital services. It provides a generic overview of howTeletext has recently been enhanced as a transmission standard and offers some examples of how the BBChas taken advantage of this new functionality. It further describes how an existing Teletext infrastructure maybe used to provide a migration path to more exotic data broadcast environments now being supported bydigital platforms.

INTRODUCTION

For many existing broadcasters, including the BBC,Teletext forms an essential part of their analoguetelevision offering. However, even in the rush todigital Teletext is still proving to be a useful andpopular component of these new systems. This ispartly due to its maturity in a rapidly evolvingenvironment and partly due to efforts to define afuture role for it.

In the past few years the Teletext specificationshave been reviewed and expanded. Existing parts,such as text services (ref 1&2) and dataservices(ref 3) have been enhanced in a compatible way.Whilst new functionality, such as support forElectronic Programme Guides (EPGs) (ref. 4&5)has been added and Web like services, such asTeleweb and IP over VBI are being introduced.Efforts are being made to ensure that theseextensions are being including in the appropriateemerging standards. This suggests an industry stillfinding ways to use a familiar tool.

TELETEXT

At its simplest Teletext can either be page based -which is the familiar text pages but also includesforms of databroadcasting, such as EPG, orIndependent Data Lines using Teletext packetsindependent of the page structure as a datachannel.

Teletext is the carrier for a number of services, forinstance in the UK there are typically 6 servicesbeing carried via Teletext to the home or office:-

Databroadcasting; National text service; Local textservice; Country and Network Identify, ProgrammeDelivery Control and Subtitles.

Databroadcasting can cover a range of servicesfrom strictly commercial to EPG and “IP over VBI”.

In addition Teletext is the only dataservice whichco-exists in the Analogue (PAL or SECAM), SerialDigital (Rec 601) and DVB (ref. 6) domains andhas a intimate link with the TV Frame so enabling(almost) frame accuracy in delivery.

Thus it is easy to use this for simulcasting thesame information as well as working in most

broadcasters’ infrastructures (ref. 7). Processingand decoding equipment is cheap being based onmass-produced chips for domestic reception.

Editorial aspirations to enhance the viewingexperience for the audience receiving analoguetelevision and Teletext co-existence in multiplesignal formats that forms the background to thispaper.

Existing Text services Editorial enhancements

A Level 1.5 decoder can display with only the threeprimary and three secondary colours, plus blackand white. However many newer televisions havelevel 2.5 decoders which support pastel coloursand can also colour the borders outside theTeletext display area.

With no extra editorial effort, and with no effect onthe speed of the service, a single Teletext packetX/29 for each magazine can be transmitted everyfew seconds. This can map the basic colours toless saturated colours and provide a backgroundrow and screen colour which is defined by thebroadcaster.

If a more dynamic and graphical output is requiredthen level 2.5 is the next step. With some carefulplanning and transmission, effective pagetemplating some very attractive and “differentlooking” pages can be constructed that will bedisplayed in a manner that is still attractive to thelevel 1.5 viewer. The majority of large systemssupplied to broadcasters in the past 3 years havethe ability to transmit level 2.5.

On the speed of transmission a number oftechniques can be used. However with moretelevision sets being equipped with some pagestorage, many of the problems of access times topages and sub pages reduce. At about 1 K byteper basic Teletext page the total memoryrequirement is not great.

But there are some tricks that can be employedwhich can help to minimise the apparent time toaccess a page for those viewers with sets withoutmuch memory.

However the calculation of what a trick does to thetiming of all the pages to fit in the availabletransmission capacity is not simple (ref. 5).

Recently some transmission systems have beensupplied which work by allocating a proportion ofthe available bandwidth to each magazine. Thisgives a finer degree of control than the allocation oflines in magazine parallel (where magazines areallocated into streams which are each allocatedone or more TV lines) and is equally applicable tomagazine serial (where all the pages are

transmitted on all available TV Lines in numericsequence).

Technical issues

In all the editorial discussion the concern has beenon pages as an entity and how they are scheduledfor transmission. At a technical level, the individualpackets, (one per TV line) that make up theTeletext transmission and the rules pertaining totheir transmission are more important. The keyrule “Page erasure interval” means that thetransmission of a page takes an integer multiple offields, with TV Lines that occur between the lasttransmitted packet and the penultimate line of thatVBI, which is where the new page starts, beingoccupied by “filler packets”.

This table gives some statistics - more details canbe found in References 2&5.

VBIlines

26 packets (pkts)/Page

24 packets (pkts)/Page

VBI/Page

Pages/sec

% fillerpkts

VBI/page

Pages/sec

% fillerpkts

7 4 12.5 7.1% 4 12.5 14.2%

6 5 10 13.3% 4 12.5 0%

5 6 8.3 13.3% 5 10 4%

4 7 7.14 7.1% 6 8.3 0%

3 9 5.5 3.7% 8 6.25 0%

2 13 3.8 0% 12 4.2 0%

Filler packet space can be used for other Teletextservices, such as independent data linedatabroadcasting and for the broadcast servicespackets 8/30 format 1 which identifies thebroadcaster and includes date and time and packet8/30 format which carries programme deliverycontrol, (PDC). Packet 8/30 has extremely tighttiming requirements and thus take priority over thetext service.

About 7 years ago BBC started using thetechniques of replacing filler packets with Teletextpackets containing real information to combine twomultiple TV line Teletext streams ofdatabroadcasting which had priority and the BBCText service Ceefax which occupied a largenumber of TV lines. The purpose was to maximisethe bandwidth available for the Ceefax and used amultiple input databridge that controlled outputlines of the Ceefax transmission system.

The techniques have extended and multiple inputdatabridges are being widely used in a variety ofmodes to maximise the number of active packetsin the output Teletext streams. The need for controlto the text transmission system has been removedand the input streams are totally autonomous.Typically three text streams (coming from twolocations) and two Data streams plus Subtitles arecombined, thus maximising efficiency andremoving the need for a separate line to beallocated for subtitles (see Appendix 2). Furtherguidance on the use of the VBI can be found inReference 8.

Future systems

When considering future systems, technology andeditorial requirements need to be consideredtogether.

There is some opportunity to add databroadcastingwithout impacting any existing Teletext text serviceby making use of inherent inefficiencies as outlinedin the previous section. If further databroadcastingcapacity is required, simple changes to the textservice can free-up bitrate with minimal editorialimpact.

The services that can be offered at the moment area Teletext Based EPG (“NexTVieW”) which issupported by many TV set manufacturers in theirtop-of-the-range sets. This is beginning to pick upfavour in the German speaking countries.

There are a number of “web like” applications thatare being developed using Independent Data Linesfor transmission to Personal Computers and someto TV sets.

Storage in the home means that thedatabroadcasting can have cycle times of an houror more.

The key systems are PC based:- Intercast - and IPOver VBI and TV / Set top box orientated Teleweband Web TV.

Broadcasters are also looking at ways of usingTeletext text as a delivery method that works now,to experiment with the origination and backroomsystems for interactive and enhanced televisionand to see how the audience reacts.

Most of these are based on triggering from theprogramme schedule or timecode, to allow relatedTeletext pages to appear and disappear justbefore, during, or after a programme.

Teletext as the universal data distributionsystem for broadcasters

Teletext has a number of important properties:

• Linked to the video signal frame structure

• Uses space which may otherwise not be used

• Exists in a number of video signal formats:-analogue PAL or SECAM, Serial Digital andDVB/MPEG

In addition in Analogue and Serial digital signals itis embedded in the video and thus should be fairlydifficult to strip off and thus loose.

Most broadcasters use Teletext text for subtitling(Ref. 6) and thus must ensure that inter-site linkspass at least one TV line pair of Teletext, and oftenthere is more available. Even with one line pairavailable with subtitles there still is over 9.6 kbits/sof data capacity available.

Databroadcasting, which has a vast number ofcommercial possibilities in emission, has uses forbroadcasters themselves on their own inter sitevideo links

A variety of equipment is commercially available todo such functions as

• Audio – low bit-rate for talk-back, Linear PCMor “ISDN like” MPEG-2 Layer II or aptX™

• Data – opt-out control; remote machine controland schedule transmission

• Other systems - Signalling Timecode andMixer Status in Subtitle headers; storage ofMetadata (for example using a simple Key-Length-Value format).

CONTENT PROVISION FOR DIGITALTELEVISION INFORMATION SERVICES

The BBC is currently involved in the roll-out ofservices on all the DTV platforms; DTT, DSAT andDCABLE. In the UK, all these delivery systems areexploiting the need for new receiving equipmentand the necessity for increased memory andprocessing in the receiver, as an opportunity tointroduce new multi-media environments forbroadcast applications. These environmentsgenerally provide greater flexibility in the structuireof the broadcast stream, data compression,downloadable applications as well as data allowingcustom navigation, flexibility of graphics layout, andimproved text and graphics. Faced with this it couldappear that the use of Teletext might be out of thepicture?

The ideal content production system?

However exotic the presentation, it is often arguedthat an information service is only as useful as theinformation it provides, essentially text andgraphics/images. So, even once the editorial

design of a service that exploits the capabilities ofsuch new receiver environments is completed,there is still the issue of generating large volumesof content on a daily basis.

The ideal content production system (CPS) mightsensibly include a “What You See Is What YouGet” (WYSIWYG) editing environment, basedaround the final editorial design for the service.However, there are a number of practical realitiesworth considering before embarking on such astrategy.

For many broadcasters, an editorial staff alreadyexists for the creation of Teletext content foranalogue services – in the BBC’s case over 60people nationwide. Duplicating a similar size ofteam to support just digital services might well be atime consuming and expensive operation.Furthermore, the existing Teletext staff are likely tobe skilled in the rapid generation of “televisionfriendly” information, i.e. easily readable in screensize portions.

This economic driver for using existing Teletextstaff may be a strong one, but Teletext editingsystems tend to be very Teletext-centric (althoughthis is not so true for some of the newer systemsemerging) which can make republishing to otherplatforms difficult. So, if following this strategy itmight be sensible to migrate the editing systemused by the journalists to a more “object based”WYSIWYG one, and indeed this is the BBC’s long-term strategy.

The BBC’s launch strategy

The BBC has not pursued this in the short-term fora number or reasons:

• The requirements of such a system are stillunclear due to the limited industry experienceof operating information services for the newdigital platforms.

• No suitable third party could be found whocould provide such a system within the BBC’stimescale.

• The BBC’s technical resources were alreadystretched with the roll-out of the wider DTVinfrastructure.

• Even assuming the most optimistic adoption ofDTV, the viewers accessing the information inthe analogue form, i.e. broadcast as Teletext,will outweigh those accessing it via digital by aratio of at least 10:1 during the launch period.

This resulted in a strategy to develop a CPS basedon downstream processing of information extractedfrom the existing Teletext database used to supportanalogue services. This approach had the

attraction of having minimal impact on theoperational Teletext service, and by making theprocessing highly automated required only a smallnumber of new staff. The trade is clearly one ofreduced disruption, risk and cost against editorialcontrol.

Launch system overview

The CPS that the BBC has created consists of aseries of processes as follows:

• Story Entry. Stories are entered as normalusing the editing system linked to the Teletextdatabase supporting the analogue service.However, tags can be added to rows of theTeletext frame that are subsequently discardedwhen broadcast on analogue, e.g. row 0.These tags can be used for any digital servicespecific feature, e.g. reference to a relatedimage, alternative headline, flagging animportant story.

• Data Extraction. This is based on a scriptinglanguage that forms part of the Teletextdatabase that the BBC is using. Scripts can beset up for specific pages or group of pages thatextract useful blocks of data, e.g. headline text,body text, sub-table text. The effectiveness ofthe extraction process is clearly dependentupon the functionality provided by the scriptinglanguage for spotting the desired informationwithin the layout of the page. However,extraction is also improved by the use of aknown in-house layout for the page beingprocessed.

• Story Mapping. This is also based on the samescripting language used for Data Extraction.Whilst Teletext effectively has a flat navigationstructure (based on page numbers), the BBC’seditorial proposition for digital platforms isbased on a hierarchy of menus. This meansthat Teletext stories must be mapped into thisstructure. In the BBC’s case this is helped bythe fact that related stories in the CEEFAXservice are grouped together using ranges ofpage numbers. Further mapping rules can beapplied within each range to spot particularkeywords. Known Teletext index pages canalso be parsed allowing stories mapped into aparticular menu to be re-ordered based onnews-worthiness.

• Coherency Check. This process checks theoutput of the Story Mapping and ensures thatall files described in the mapping are present.Where necessary it handles menus that haveno stories mapped into them, e.g. by display ofa suitable caption or by removing the menu, aseditorially required. Any problems are recordedby the setting of “flags”.

• Content Format. This is required to re-formatTeletext stories for presentation by the newdigital application environments. Examples ofthe processing required are conversion ofcharacter codes, re-pagination due to the useof proportional fonts, de-capitalisation ofheadline text and suppression of Teletextspecific references, e.g. “See CEEFAX Page123”. Again, any problems are recorded by thesetting of “flags”.

• Service Preview. Before going to air it isimportant to be able to check the results of theupstream, automated processing and ifnecessary, preview individual stories. Manuallychecking each story prior to broadcast wouldbe time consuming and operationally isunacceptable due to the potential delay inbreaking stories getting to air. The ”Previewer”tool provides a simple user interface that liststhe menus in the service structure. For eachmenu simple icons are used to display asummary status for the stories into it, based onthe “flags” that have been set duringprocessing. This allows a system operator toquickly see where there are problems. Thestatus of an individual story can then bechecked and if necessary previewed using anintegrated digital platform emulator. Obviouslythis preview is only as valid as the emulatorused. The flow through of new and updatedstories can be controlled manually or by theuse of automatic filters applied to the “flags”.This provides a means for stories to beblocked or passed on for broadcast basedupon the severity of the problem encounteredduring processing.

• Application Build, Playout and Insertion. Thisstage is obviously specific to the particulardigital delivery system.

This approach is clearly not ideal since journalistsgenerating content are not really able to optimisethis for presentation on the digital platforms.Furthermore, the feedback loop for resolvingproblems is for the “Previewer” operator to contactthe journalist who created the problematic story.This feedback loop is used as much to drive long-term change as for short-term fixes, i.e. to helprefine the rules used in the automatic processingand to encourage CEEFAX journalists to conformto “digital friendly” styles.

The system in use

In November 1998 the BBC went live with a CPSdeveloped to support the launch of digitalinformation services based on the systemdescribed in the previous section.

On the same day that the CPS went live, aMHEG-5 based DTT Digital Text “barker” servicealso went on-air containing a small number ofeditorially selected stories. This immediatelyprovided a focus for those operating the CPS andacted as an invaluable source of feedback. Thishas allowed the CPS to be steadily refined andenhanced over time.

In May 1999 the DTT “barker” was replaced by afull “DigitalText” service containing over 800 pagesrepublished from the BBC’s CEEFAX service.Work is already well advanced for the launch ofsimilar services on the other delivery systems ofdigital satellite and digital cable.

CONCLUSIONS

Teletext will clearly last at least until the end ofexisting analogue transmission of television as ameans of providing textual information. However, itis has already found a new lease of life in thelaunch of some DTV systems, due to the slowemergence of stable multimedia environments forconsumer devices such as television receivers. Itmay also provide a useful stepping stone for thosemigrating to such digital platforms.

For the engineers, the fact that Teletext exists inthe major forms of signal streaming, and is usedfor subtitling, means that there are ampleopportunities to insert data which will be passedthrough systems without degradation because it isembedded and time locked to the video signal.

ACKNOWLEDGEMENTS

Peter Weitzel thanks the Director of TechnologyBBC Resources Ltd for permission to publish thispaper.

Jeff Hunter wishes to thank his colleaguesthroughout the BBC for their contribution to thiswork.

REFERENCES

1. ETS 300-706 Television systems, EnhancedTeletext specification

2. ETR 287 Television systems; Code of practicefor enhanced Teletext

3. ETS 300-708 Television systems, Datatransmission within Teletext

4. ETS 300-707 Television Systems Protocol for aTV Guide using electronic data transmission

5. ETR 288 Television systems; Code of practicefor an Electronic Programme Guide (EPG)

6. EN 300 472 Specification for conveying ITU-RSystem B Teletext in DVB bitstreams

7. “DVB Subtitling - the UK experience “ N ETanton and PM Weitzel IBC 99

8. TR 101-233 Television systems; Code ofpractice for allocation of services in the VerticalBlanking Interval (VBI)

APPENDIX 1

The Structure of a Teletext packet:

The first two bytes are a clock run in of alternateZeros and Ones, followed by a unique framingcode 11100100.

The next two bytes are termed the magazine andRow address and define the address space forpackets. The magazine is coded in three bits ofbyte 4 and a packet in the four bits of byte 5 andthe remaining bit of byte 5, Bytes 4 and 5 are 8:4hamming encoded. Thus for each magazine thereare 32 available packets

A text page is made up of a header (Packet zero)and then in the next field (or frame) anyenhancement information (Packets 26 to 29) andthen the page text rows (packets 1 to 23 or 24).This rule which was originally to allow decoders toerase the previous page before loading the currentone means that there usually are TV lines whichcarry Filler packet which have no meaningfulinformation.

Packetnumber

Function

0 Page identifier and page terminator.

1 to 23 These packets carry the display dataof basic Teletext pages.

24 Fastext prompts.

25 “Displayable labels for key wordsearch” - rarely used.

26 Used for Programme delivery Controland to reference alternative symbolsand diacritical marks.

27 Editorial and compositional pagelinking.

28 Page specific display related data.

29 Page specific display related data fora magazine and character setreferencing.

30 Independent data lines –Databroadcasting.

31 Independent data lines –Databroadcasting.

APPENDIX 2

The following figures illustrate the use ofdatabridges.

Figure 1: Original Configuration Using Feedback

Figure 2: Typical Current ConfigurationOperating Autonomously

DatabridgeVideo

InVideoOut

Data broadcasting

Text

ControlSubtitles

8/30f2

DatabridgeVideoOut

VideoOut

Text Services

Sustaining NationalText Service

Local Services

Databroadcasting& Packet 8/30

Subtitles

8/30f2