Hello and welcome.

My name is Russell Trafford-Jones and thanks for joining me.

This is Broadcast Focus, a show where we look behind the scenes of the broadcast media and entertainment industry by chatting to the people who make it happen.

Now, this is a small independent channel.

Thanks for everybody who supports it by liking and subscribing, but just watching is absolutely fantastic.

Thanks for being here.

There's something for everybody, I hope, whether you're technical or otherwise.

And this time I'm joined for the third time by ex-BBC engineer Peter Whitesall, who's been talking us through how Teletext works.

The first two episodes are already available, so feel free to check them out in the description or in the cards above.

For those of you who need a super quick intro to Teletext, it's a way of sending up to the second information over the air as part of the TV signal.

With a Teletext-enabled TV, getting news, TV listings, and more is as easy as pressing a couple of buttons.

Now, no longer available in the UK, there is a simulation of Teletext.

And here it is.

This is NMS Ceefax.

We've looked at this before.

We won't go into it very long, but I did want to just quickly show what it looks like.

And if you type in numbers, then it will look through and get the latest info.

This is being regenerated from the BBC website and transmitted as Teletext within a simulated environment.

But yeah, that's what's on tonight.

Peter, welcome back to the show.

Thanks for joining us again.

It's very nice to be back.

So I think we just want to plough straight in.

Do you want to give us a quick update on what we've covered so we know where we are?

And then we're going to kick off with subtitles, one of the most important features, I think, to be honest.

Yes.

And what we've covered so far is what Ceefax is in terms of a service and how it was used and how it was put together and how the BBC distributed it across the countryside with regional services and combining Teletext from a different range of things, mostly the Teletext-serviced Ceefax, which we've just seen the simulation of, but also mentioning in this session the subtitles and then data broadcasting.

These are a minority in terms of the amount of bandwidth taken compared to the text service, but are both, as Russell has said, very important parts and usages of Teletext.

OK, let's start with subtitles.

The text services we saw goes on all the time.

Subtitles are intermittent.

They only happen when somebody speaks.

In terms of handling the subtitles through the network and through the systems, they go with the programme, not with the channel.

News being something that Ceefax would carry is what you would see on BBC One or BBC Two.

Subtitles go along with the programme, the news or EastEnders, and they actually occupy a bit of the video waveform, which sometimes gets blanked by vision mixers.

It's close to the picture, so it can be easily carried through, but it can get lost very easily.

I actually, in the design of systems, which I talked about in the last episode, enabled us to be able to specify that all programmes were to be transmitted at a technical level, which was assumed to be the video, the programme audio and the subtitling, and actually was enabled to make that public statement ahead of the editorial targets, because we didn't have enough subtitling staff to actually subtitle absolutely everything.

We now in the BBC specify that we will do 100% of programmes.

That does give us some problems with live, but for every single pre-recorded programme, it is so relatively easy to go and transmit subtitles.

Subtitles typically are just two rows of text, so we actually transmit them on lower row numbers in the page normally.

They sit at the bottom, and these are the sequence of packets that we would put out, the header which says, I'm a subtitle, and my page number is 888, and then two rows of subtitles.

They actually start with a double-height character for the two rows of text, and then a header that closes the subtitle.

That means that any decoder should then immediately have displayed it if it hasn't already displayed it as each row of subtitle has been received.

In case somebody was joining the programme late, we actually repeat the whole thing again four seconds later, with one subtle difference is the header doesn't say clear page.

It just transmits it to add on effectively.

It overrides.

That just basically means that the people watching television have got subtitles.

Immediately, they press the text, the subtitle button.

Within four seconds, they've got something, even if it's a long scene, I guess something could be on the screen for five, ten seconds.

Yes.

In fact, I don't know whether it still is the case, but for DVB subtitles, which is used in digital television services, there actually is a maximum length that the coder assumes that the subtitle is going to be on air for, and that's around nine or ten seconds.

So, we've probably got seven or eight seconds display time for each subtitle before it changes.

And these row numbers, earlier we were talking about pairs of lines where there was a line number for the field one and line number for field two.

Are these only on first field?

No, these are row numbers of the displayed text, which goes down to 23.

So, 19 and 21 are basically almost the bottom two lines, subtitles on the screen.

I got it.

Okay.

It is rather confusing.

We have to deal with lines, which are in the VBI, and rows of text, which are written lines that you see on the screen, if you see what I mean, that the actual subtitle itself.

So, we use rows for what you can see, and lines for where the signal is carried.

And so, the VBI line that this is on is?

We would actually transmit, the BBC transmits this on line 20 and 333.

Right, yes.

Which is very close to picture, there's line 21 and half of line 22 are in the vertical blanking.

So, it's basically got the subtitle line on one normally blank line of the displayed picture.

Okay.

So, it's on both fields.

And if I remember correctly, the line above and line below, are they for VITC?

The line above is, has got test signals on it.

And the line below is normally blank.

You've got that package of three lines that could be passed through, although we'd normally the whole of the systems, particularly in a read one.

So, we're talking about rows on the teletext page now.

I guess.

Yeah.

And there are a whole set of various rules that we do to ensure that the subtitles are well displayed.

We say it's a subtitle.

We say that we don't want the header shown.

We flag up that it's an interrupted sequence.

That isn't, strictly speaking, needed, but it's put in there because some decoders get a little bit confused with intermittent text.

And then we say that it isn't a newsflash, and we're transmitting it not in magazine serial.

Then we transmit on the first transmission of the subtitle.

We erase the page and update indicator.

We then don't use those when we do the auto-repeat four seconds later.

The other thing that's important is, we clear it by doing just a straight page 888 header followed by a page 8 something or other header, which clears down the subtitle.

And we also repeat that every four seconds because on a normal television set, if you came in and turned it on, one of the normal operations would be to turn it on, tune to the channel, press the text button, which would almost immediately bring up page 100, and then you put in 888 as the page number used for subtitles.

If they're not saying anything, if you think of a natural history program, typically you've got an awful lot of just scenes with nobody speaking at all, where you wouldn't want to be stuck for 20 seconds' worth of page 100 when you're missing all the beautiful wildlife.

So again, every four seconds, we clear it so that whatever the page was is cleared with effectively a blank page 888.

And given that we're saying that the subtitles are on row 19 & 21, so the reason that it's not on 20 is, as you said, it's double height, so it's 19 and 20 at row 1.

Does that give us the flexibility, if we knew there was something to avoid on the bottom, that you would want to see, you could put them at the top of the screen?

Yes.

I mean, if you're doing a football match, you'll be going out on typically online, well, actually, these are using odd ones, but going out on one and three, or perhaps if it's a more sophisticated system, on two and four, to just give a little bit of headroom at the top.

And then for certain programs, you might actually say, well, I've got the football score up there, so I will move it even further down.

But that then invades picture, and the idea of subtitles should be that it misses all voices, and all people that are speaking and their mouths, because most people who use subtitles also, to a certain extent, lip read, and it wants to avoid key action.

So, you know, you wouldn't put a subtitle over the fact that car was coming on the screen about to knock somebody over.

That's the sort of thing that in authoring subtitles, you have to be aware of.

There's a subtitle demo on this simulation.

This is what it looks like, isn't it?

And it's just there, and you've got different colours.

Yes, you can use all the range of colours.

Normally, white, yellow, green and cyan are the ones that will be used.

You can change the colour of the background.

And for some style guides, particularly ITV and Channel 4, if you have a sound effect that will have a suitably vivid coloured background rather than black.

Subtitles really come in two flavours, those that are played with a recorded programme and those that are done live.

Recorded programmes, something like EastEnders, a live programme is typically news.

And this is how we started off.

Fairly late on in my involvement here, but with new transmission areas coming in for both analogue, which is called the Network Transmission Area, and the digital transmission area, the DTA, in 1998 for the launch of digital television in the UK, we started doing things a little bit differently and actually in SDI as the video signal rather than analogue.

One of the challenges was that if you, again, using this basic principle that everything has vision, programme sound and subtitles, you ideally need to put the subtitles in as close to where the vision and the sound are as possible.

And therefore, we have a videotape machine, which is putting out time codes so that we can lock the subtitle to the time code and immediately add subtitles to it.

And then there's two outputs.

One goes to the digital system mixer.

And the other one goes via an aspect ratio converter, which is set not to blank the lines to the network transmission area.

So, if we were playing out perhaps more in 1999 rather than 1998, the majority of BBC programmes originated 16:9.

We'd be playing out from Digibeta on to a, through an inserter.

And then one output, it goes to the analogue service through an arc.

And the other one goes through the mixer on to the network transmission, the Digital Transmission Area, and then out.

And if that was playing from a file, a file to EBU 3264, which is still being used, although subtitle files should be moving more to an XML format, the EBU TimedText.

The idea is that we want to have, as soon as possible, this package of vision, programme, sound, and subtitles.

The live sometimes we would need to live subtitle a programme because we haven't had time to prepare subtitling it, quick turnaround programmes.

Something like question time used to be done in this way.

It was recorded, perhaps a legal edit done on it, and then played out more or less down the line.

And we were subtitling as if it was in the studio being done there and then.

And the live subtitling would be sending data over a serial link to the inserter and to add it in.

So, if you had a studio, you just put the inserter, the live subtitling in the studio, and the output would wander all the way through the BBC systems on to the main digital transmission network mixer and then out.

One thing that we did was to ensure that subtitles were going out.

They're intermittent.

And if something did it, we would want to be aware of the fact that subtitles have been lost and actually to put up an apology message.

You see this sometimes on channels at the moment where there's a programme that you'd expect to be subtitled, but they don't have a 100% quota.

So, they've chosen what programmes to subtitle.

And if you're expecting the subtitles, but they are not subtitling them, they actually put out a message that says, sorry, this programme is not subtitled, but actually it's done by having a file that says that we had a more sophisticated system that actually detected it, selected the appropriate message, because the automation system could know that the reason that we hadn't got the subtitles was the subtitle file hadn't been received.

So, it's a different message that sort of says, whoops, we've forgotten the subtitle file as compared to the fact that we never intended to subtitle this programme in the first place.

So, we had this policing function.

It also checked that the subtitles were going out on the right lines.

It was the unit that actually generated the Keep Alive headers every four seconds or repeated the subtitle if it wasn't.

And if the item was not subtitled and the item in those days was, for instance, network symbol, it will put out a default subtitle, which is usually an 888 top right if the item was not subtitled.

So, going through a programme junction, you would actually see on the network symbol an 888 black background, yellow text, interesting single height, and that was neatly positioned to cover the 888 that was actually in the video for the network symbol, which you still see today, except the word subtitles appears.

The other thing that this police unit did was to send a clear down at the start and end of every item.

That meant that the subtitles would never stick on the screen over a junction between two items.

You sometimes see this on commercial channels, where the last subtitle or the previous advert appears at the beginning of the new advert, which is sometimes quite amusing.

But that was very important.

It also was tied up with the fact that we knew that we're going to be doing DVB subtitling on Terrestrial Digital.

And we actually also sent a complete, rather than just saying, here's a new subtitle, which has got nothing there, and not transmitting any line, we actually transmitted every single row from 1 to 23.

This gave a signal to any downstream equipment that this was actually the end of a programme and that could be used to reset the epoch in the DVB subtitling encoder.

I don't think it ever was used, but it was something that was very useful to have in our armoury, because particularly the original DVB subtitling decoders in the set-top boxes were not exactly the world's most rugged device.

And to sort of reset them every programme was perhaps a bad idea.

And just in case, we had got a programme that was meant to be subtitled, but we'd lost the subtitle somewhere, in extremis, it would act as a live inserter, so that we could actually put out subtitles.

I don't know whether it's still the case, but basically the intention was that the BBC subtitling team would have somebody standing by to run live subtitles at all times, just in case the subtitles broke, so that the only way of getting anything close to 100% subtitling.

Having got a unit on the output of the transmission suite, it was quite nice.

We hit a slight problem with the active format description, the AFD.

This is metadata in an MPEG stream that says what size and shape the picture is.

And some decoders that we had in the output chains couldn't understand the AFD information that was going out.

Actually, VI, strictly speaking, turned it into an AFD in the MPEG stream.

So we actually used subtitles to signal the aspect ratio, whether it's a 4:3 picture or a 16:9 picture, by putting in the subtitle headers, because they were happening sufficiently frequently.

A useful trick.

Of course, it took up no extra space, because what it was doing was using 8 bits in the subtitle header, and we would have a unit at the other end that just decoded it.

The data bridge that we spoke about in Program 2.

Origination.

Oh, this is interesting.

When you're sitting in the transmission suite, you need to know what the file name is of the file that you're playing out, what the current time code is for the subtitle.

It's in time, and it's out time.

What we did was we had to create a two-page 8-8 that went out simultaneously in the same vertical blanking interval.

On lines 8, 321 and 9, 322, we transmitted that file name and time code information, and on line 20, 333, we had the intermittent subtitles appearing.

We were transmitting on page 888, so VBI lines 8 and 9, and their complements, because we had to update that information every frame, and that enabled us to do that.

And then on the output of the transmission suite, actually the police unit, it would only allow subtitles on line 20 and 333.

Therefore, the additional information that was on lines 8 and 9 just didn't get through.

This meant that anywhere in the transmission suite, you could see what the subtitles were doing with their in and out times, and the file name was right.

It also had another useful property, which was that most normal television sets do not decode subtitles on their own.

Because it's intermittent, you do actually require a continuous teletext clock.

Well, there we've got three rows of constant teletext going out, plus an intermittent bit for the subtitle.

So a normal domestic television would work perfectly okay and decode the subtitles, which saved you quite a bit of money on specialist subtitle decoders.

So in the regions, it was rather sort of the same, but an awful lot simpler.

At the time, you would not have any prepared subtitles.

It was entirely a lot.

It had really two requirements.

One was to pass through any subtitles that were coming in, or to add live subtitles to what was going out.

So a source with subtitles would bridge the Vision Mixer, because the Vision Mixer would usually remove line 20, and under the live subtitle, that insert could be sVITChed from a data bridge from what was coming in to pick up the data feed that was taking the live subtitling from wherever the live subtitler was.

And this was used in all regions, and also by CBBC, which put its mixer somewhere electronically partway through the play out suite.

So in fact, the source with subtitles could be, was one of those videotape machines that I talked of before that had an output that went to the digital transmission area, and through an aspect ratio converter to the analog transmission area, was a third output, which went to CBBC, which then got looped back in as an outside source into the transmission mixer.

SDI provides some nice little problems.

SDI itself, as we all know, is 13.5 MHz sampling.

We happen there to have got something which is very close to a data rate which is half of 14 megabits per second, which is very close to 13.5.

So putting teletext in SDI really came in three generations.

Generation zero just took an analog waveform, had an analog to digital converter, and that produced the analog waveform as represented in digital, just as it would do for the picture.

That was all well and good, but if you're generating the waveform, wouldn't it be nice to take the data from a live subtitle feed or from the subtitle file and directly modulate it as teletext in a digital form?

The first generation simulated the digital waveform by pulse width modulating in the SDI.

If you were very clever about exactly what sample you used and at what amplitude, not necessarily very fine quantization, you could actually get an output that when it was turned back to analog looked quite presentable.

It looked totally horrid in SDI, but it really did work very well to have the correct filters in the digital to analog converter.

But it was at the time about the only thing that we could do with what was available in silicon, the FGPAs then.

There's an interesting feature here.

Subtitle teletext itself has an active line that is longer than an active line of video, and it has that timing tolerance, so it can be 400 nanoseconds earlier than the timing reference, or one microsecond less than the timing reference, which is 18 samples of SDI, which again gives you interesting things if you're trying to decode it straight from SDI into the teletext text.

Certain decoders just assume that it's all perfectly timed and didn't have this floating 18 sample window to get it going.

So very interesting work there, saying we've got an analog waveform, we have it in digital so that it looks good enough in analog, but it doesn't actually look that good in SDI.

We didn't need it to look good in SDI though, did you?

That was just a carrier.

No, it's just a carrier.

Second generation, the FGPAs are a lot faster, and we actually had a particular shaping of the pulse that made it look actually better.

The output of the SDI unit was better than any PAL unit that we'd ever seen.

And technically, we merged the functionality from what was an inserter, which is a sort of one in, one out, perhaps a data in or data bridge, which has got video in, the text that you're bridging in, and an output into the six input data bridge that we spoke of earlier.

So actually, rather than having two boxes, we could actually do it all in one box, which would do everything, which was first done for the nation's analog from digital project in 2002.

This is the fact that as the regions, so that the nations, Glasgow, Cardiff and Belfast could generate their analog output from their digital input, thus saving an analog circuit, which in those days was very expensive.

Well, it was a bit cheaper than it had been, but it still was an extra cost.

And having got that, we also installed it in the broadcast center for main network play out.

It generated Presfax, which is the internal next junction information, which was then decoded in the nations.

It also did program delivery control as well.

So it really was a box that did everything, which was very, very nice.

Kept your spares holding down.

It meant that if you wanted to do something, you just knew that a DTP 600 was the box that you would put in and it did whatever you told it to do.

Actually, getting those in the first place was a bit exciting because the first set of prototype boards got dropped into the bottom edging tank by the printed circuit board manufacturer.

So I spent a very useful afternoon on the phone to various health and safety people about how you fish multi-layer printed circuit boards out of the bottom of a tank containing cyanide and similar nasty substances.

You chose you have to be very capable of doing all sorts of things.

This is a picture of Presfax.

Ah, yes.

So this was purely built on teletext and it was carried on different lines, was it?

Yes, yes.

The history of Presfax goes back a very, very long time.

In fact, a few bytes on the insertion testing were first used.

With data broadcasting, which we will come to later on in this episode, you're able to send an awful lot more information and it doesn't really take any space.

The first decoders that we had looked like the previous system, which was green on black VDU type displays.

But with the new transmission system, if you've not got a vast amount of information to display, you can just make it look sufficiently chunky and clear.

We used to have this on the stack so you could always see it.

Yes.

So we've got the program name and then the program ID.

Yes.

Assume the 2.0 is in stereo.

I don't know.

I don't remember that.

So the time remaining, I think, yeah, the duration.

And then there's obviously a junction coming up at nearly 1959.

So you can see the different things in the junction.

You know which IDs are going to be playing.

And you know when Holby City is coming on air, which of course is important.

You don't want to miss that.

No.

Right.

The text service that we've been talking about uses displayable row zero, the header through to 23 for normal text and the fast text links are on row 24.

Then row 25 actually isn't used for anything.

And then 26, 27 and 28 are used for different enhancements.

Row 26 enables you to put diacritical marks on the text. 27 is where the data for the fast text links and some color information occurs.

Packet 20, advanced color information if you're in one of the higher modes of teletext for that magazine.

And packet 29 does it for the entire service.

Those are not used very often.

But we've got a coding space which goes up to 31.

So you then have got effectively rows off the bottom of the teletext page that can be used for other things not to do with the main text service.

So we have some independent data lines to be rows perhaps.

But that means that it can be used just like a modem basically.

There's a special type, the magazine 8, packet 30 is used for specialist purposes to do with the broadcast service.

But other than that, you have got a number of independent lines, which means you've got 14 unique addresses at quite a high level so that it can be used for other things.

And of course, as it's basic data, you can then code it.

So you actually can code up a number of different data channels, run it just as a data service, which means that you can encrypt it, you can do whatever you like.

It's just taking 8-byte packets in, putting them through the system and squirting them out.

So you actually have got a vast amount of data available, a number of data channels, which perhaps are useful, and then a 24-bit service address, which gives you 16, 17 million different service addresses.

It's not as bad as IPv4, which was favorable at the time, but it's an awful lot.

You said that each of those was an individual customer.

We could individually address every household in the UK three times over.

The data rate is just under 13 kilobits per second per line pair, which is a nice sort of number.

It's greater than 9K6, which was what most modems at the time seemed to be using.

So we've got a little bit of headroom there.

The important thing was that if it's a broadcast service, it goes to everybody at the same time.

And if you just want a small amount of data to go to everyone at the same time, it's very, very useful.

So what applications have you got?

Corals, bookmaking.

You can get up to the sub-second prices for betting.

And the most important few bytes that were sent was to stop betting on the Grand National and the like.

The London Stock Exchange, a private network that showed stock prices.

Again, the idea that you've got everybody getting the information at the same time.

So it was infinitely fair and the fact that it was really near instantaneous.

Cardcast, they broadcast faulty stolen credit card numbers.

So you saw every petrol station in the country with a television aerial so that they could receive that.

If for any reason the petrol station couldn't receive the signal, typically it was closed down.

Whitbreads had a whole series of pub games which were downloaded and could be brought up to date so you could have a quiz that was based on the current news stories.

And updated it in real time into a computer.

Yes.

Presfax, we've just seen showing in sub-second on the screen, yes, showing what was going or about to go on in sub-second updating.

So basically, if they had redone the junction, the network director could press the button during the update and then start talking immediately about what he'd just done to the regions and they'd already got the information.

Very useful.

Telfax, we talked about putting BBC internal information that was meant to pre-empt the staff reading in the three o'clock edition of the Evening Standard.

And we also used it for opt-to-control.

Certain locations had an opt-out that was at the transmitter, not at the studio centre.

So we could actually control a switch at the transmitter by putting a data broadcasting feed on the output of that studio centre.

These places were places like Cambridge before they moved, Tunbridge Wells, and the Channel Islands all worked like that.

We just talked about sending lots of little information.

It's important to also realise that 10 kilobits per second is about four megabyte an hour.

It's actually quite a lot of data.

We had some very interesting ones here.

This actually shows some of what's happened in telecommunications since we were doing this in the early 1990s.

So this is what, let's say, 30 years ago.

The problem was, the way the system worked was that the farmer would milk his cows, the milk tanker would come along, collect the milk, take it back to the processing plant where they would measure fat and similar parameters of the milk and want to communicate that back to the farmer.

This was all well and good.

You could do it using a fax machine.

The problem was the farmer was always on the phone.

Therefore, it was very difficult to get for the fax machine to connect because the phone line was always being used.

So could we broadcast it through the air?

Well, that's not a bad idea.

If we've got a communication system, we could also use it to tell people that the milk tanker was delayed or had landed itself in a ditch or something like that.

All of this wanted to be fairly rapid.

So we had this basic idea that if you broadcast, you could broadcast to a group of farmers.

Milk tanker number one has got itself stuck in a ditch.

Or you could broadcast to individual farms saying, here's your milk fat data.

And once we've got this in and running, it was quite interesting to see how else it could be used.

The farmers rapidly discovered that they would have a different category of operation called a newsletter.

So they were putting together a sort of information sheets or whatever that they were also using to transmit to these things.

Sometimes it was actually that somebody was at a stock sale or was actually telling you the price of heifers and pigs and hoglets and the like.

In those days, we also broadcast that information, a bit like the shipping forecast now.

We used to broadcast that at the godforsaken hour of the early morning.

So there was a situation where we were broadcasting effectively to the whole country, but actually going down to individual farm level just to get the right data.

Let's see what the next application we've got is.

Ah, audio.

Our dear friends in Wales wanted a Welsh commentary on the internationals for S4C.

Now, the problem that they had got was you'd have two links out of the site, main and standby radio link.

One would be carrying sound and effects plus BBC Wales sound, and the other one would be carrying an international sound, i.e. the actually substantially different music and effects type chapter channel of the sound round the ground.

So how do I get a Welsh commentary out?

Well, again, you can use data broadcasting.

We've got a complete blank vertical blanking interval.

So if we hijack 10 line pairs of that, we can put an abtex encoded audio at 128 kilobits per second out in the VBI.

There was an issue with a one frame offset in the audio compared to the programme, the international sound.

So you needed a fairly clean commentary that didn't have too much of the effects in the ground.

It did actually work remarkably well.

You could actually put it out on both feeds so that you actually were duplicated if you had to do it.

But it was a very elegant solution.

Was this over the air?

On the ground to the studio centre, two microwave links, one carrying the, let's call it the BBC mix, and one carrying the international mix with the Welsh commentary in the VBI.

But that would just use the standard abtex encoder, a D-type plug on the back.

We just double-ended it all that went into the abtex broadcasting encoder.

Cool.

So one frame offset soon came back with Dolby.

Yes, yes, yes.

Then we had other situations.

Remarkably topical.

I can't remember what the incident was, but the Archbishop of Canterbury had done something or other.

So all the news could disappear down to Canterbury.

We didn't have any mobile phone.

Well, I think the whole centre of Canterbury could take 12 mobile phones.

Well, that wasn't good enough for the news crews.

So they couldn't get any talk back.

How can we get around this problem?

Well, actually, we were doing some work on audio description, experimental work under an EU contract, a project called Auditel.

And that used codebook linear excited prediction coding from work done at Surrey University.

Therefore, we could put a low data rate audio signal on a single line pair of the VBI, which effectively is a trivial amount, and put news talkback out over it, so that you could then put whatever you wanted, talkback program sound to your reporter in the field.

Because they all use mobile phones to queue themselves these days, we could use teletext to do it.

With the dynamic allocation, it took next to no space, and we were putting 8 kilobits per second through it.

That really was a very good sort of solution.

But unfortunately, or fortunately, satellite news gathering came in, which gives you umpteen numbers of audio subcarriers.

And of course, mobile coverage got an awful lot better.

So we talked about dynamic allocation last time.

But basically, that's opportunistic insertion, really, isn't it?

Yeah, yes.

Basically, if a packet comes in that is the audio, it can displace a Ceefax packet, delay the Ceefax packet onto the next VBI, or if there isn't one, because Ceefax was fundamentally inefficient, because of the field blanking.

There are lots of null packets going out, and you just replace those with an audio packet.

And don't tell too many people, we actually could also put it in with subtitles with another single line pair service, and that would work quite well.

Actually, the KELP coding meant that you could actually have it interrupted by subtitles, and the coding was so good, that you didn't notice that you'd lost any packets.

You didn't lose more than three of them.

When it comes to the Auditel experiment, the idea was you wanted to put an audio description.

Now audio description is subtitles for the blind.

It's a description of what's on the screen.

So for instance, you could say where it was for a shop change.

So in EastEnders, you might just about have enough space between the dialogue to say "In the Vic." or "Out in the square."

Or if you were describing a natural history program, you would say something like a seagull lands on a seal.

So we had the problem of sending audio.

We actually wanted to have the ability to fade the program sound out, and it would be good to be able to pan the voice of the describer.

In analog television, this is a European project, it actually ran in two phases, and the BBC was not involved in the first phase.

The first phase, they said, well, 11 kilobits per second, NICAM channel.

In the NICAM multiplex, there is actually this peculiar channel, which is just pure data, which has no use.

To a certain extent, it's a bit like the fact that teletext uses the blank lines that aren't used by a picture in a television waveform.

Well, here, we've got a data channel, which was not being used in the main stereo sound distribution.

So let's try and use it.

The problem with using NICAM was that television distribution does not maintain NICAM.

You decode and recode every regional center in ITV, mainly in ITV.

NICAM was a bit difficult to distribute.

We're a lot easier now, actually, because, of course, all ITV programs are played out centrally.

So you have a one-to-one correspondence to the transmitter.

Another slight alarming feature was that it was discovered that the chipsets in television sets were defective.

And if you did exercise this 11-kilobit-per-second channel a little bit more than you might think, although perfectly legitimately, rude noises came out of the left channel of the program sound, which was not a good idea.

Phase two was far more practical.

Both BBC and ITV employed a describing team, and a lot of work was being done.

So we actually were transmitting it for real on the air, as NICAM didn't work.

And Norman Green, who really did an awful lot of pioneering work of teletext and the ITV network, was effectively Director of Research Engineering.

We moved to teletext.

And therefore, if we used a low bitrate audio, it would fit in one line per frame for ITV.

And as I mentioned, we could mux it with subtitles, which is really very, very elegant.

It got replaced in the digital world by doing it an awful lot more sophisticatedly using the PES packet headers in the MPEG audio stream, which was quite good.

But Presfax.

We started off with something that actually looked suspiciously like a sort of teletype operation that had been done before teletext was used.

We ended up with a display that had 86 characters mono display, which really was rather pushing it.

There was some very clever work that we were doing in filtering the text characters there.

But when we moved to the broadcast centre with Omnibus Automation, we decided that something that you could more easily see on the monitor stack rather than a VDU sitting on the control desk was the right answer.

So we adapted teletext decoders that were being used for betting display systems to decode data broadcasting that we were using for PES facts.

We just did a subtle change to how the thing was decoded, a bit of firmware change.

And we had a unit that displayed teletext in vision.

Coming off the first version of the PES facts decoder, we've got quite a sophisticated remotely controllable character generator.

At the time, the majority of BBC viewers off a single transmitter were carried by Dover, which was received by the Calais relay and sent by coax to the Low Countries, where the cable companies used them.

The only problem with any reception of anything on the coast was the fact that there was interference from the French broadcasters.

Therefore, we perhaps needed to put an apology to our viewers in the Low Countries to say that sorry, the picture's a bit bad because we have co-channel interference.

So one of these was installed at Dover.

We'd actually think it was used for anything much except for children in need, where we put up the Brussels phone number for donations.

But it was interesting use.

And then many, many years later, when we were turning off analog transmitters and turning them into digital, you could install a unit at the transmitter that you could then, during programme junctions, put up a message saying XYZ transmission will be turned off on such and such a date.

Look at the website for more details.

So a very nice little way of using the data broadcasting to send a message, which was then turned into characters that the viewer at home would see.

Now, our next section is on standards.

But before then, I just wanted to highlight something I don't think we've talked about, which is Ceefax in vision or Pages by Ceefax.

It says here that it was in the 80s that we started playing out Ceefax for like half hour periods.

Do you think that was as much about promoting the idea that it existed?

Or do you think by the 80s it was because that was early on in terms of actually having the chips available in the TVs, wasn't it?

Yes, it was a number of things.

One was, of course, that a television programme did not go out all the time.

Therefore, between transmission, normal transmission time, so that would be, for instance, the whole of the afternoon until between the one o'clock news ending and at four, thirty, five o'clock children's television starting, would be transmitting test card typically.

Well, you know, much as though I love Young Miss Hersey and The Clown, it's not exactly informative television.

And therefore, to put up something which was a carousel of pages that would perhaps put the programme listings, put up news headlines, put a few stock prices, put up a few sort of magazine type items, perhaps even some lovely sort of graphics that were perhaps a little bit more elegant than that.

Was that actually quite a good idea?

And that we actually would perhaps even be using higher levels of, especially Decoder, which actually could display higher levels of teletext than was normally being transmitted, just to make it look prettier.

I was going to ask, was there a special page that just had all of them on?

Yes.

Basically, it was something like 198.

Well, this is 298 on this.

Yeah, right.

So it's a 98.

I knew it was 98.

Yeah.

That would be fed by the editorial system, a list of pages that would then be sent down the page 198 or 298 slot.

One after the other.

So it's a multi-page set that was perhaps 20, 30 pages long, all on page 198, 298, that were selected by the editorial staff and sort of just put in a cube.

There were other units made.

You would have a command page, which had the list of the pages that you had to pick up from the normal service, which is a little bit more flexible and didn't require you to do anything with the editorial system.

You could just say, OK, I've got my television out.

I've got these pages that I'd like editorially to put in.

Yes.

That one's 198, that one.

Yes.

Yeah.

Well, I think 198 was on BBC One and 298 was on BBC Two.

So at home, could you watch 198 or was that just something?

Yes, at home you could watch 198.

All right.

OK. On to standards.

If you wind back to 1972, 1974, when Ceefax was being developed and put on air, the government took great interest in this and the Department of Trade and Industry formulated the Green Book, which I have a copy.

This was a very, very comprehensive document.

It looked at every single thing that you could possibly put in, in teletext by different ways of coding, including music and kanji characters.

The problem was it was seen by everybody as being a very national standard.

It was the UK way of doing things.

Actually, I was involved in the decision to ask the European Broadcasting Union to formulate a specification that was designed to be used by broadcasters that covered the things that were actually being broadcast in Europe at the time.

So we moved from a national book, which was mind-bendingly comprehensive, to the European Broadcasting Union setting a standard to take the features that were being used and make it into something that was very broadcaster-centric.

Basically, EBU 492 took the bits that said, OK, if you've got a Ceefax-y-like service, a subtitle-y-like service, a data broadcasting-like service, what are actually the bits out of the Green Book that you need to have and reflect, and threw away the kanji and music notation.

I got involved through the IEE, IET, in persuading the government that they should release the Green Book to the EBU and let the EBU sort it all out.

But then, around the early 1990s, it was very clear that although there had been the cooperation of the chip and set manufacturers back in the 70s when Totex was being developed, television receiver manufacturers were doing strange things.

And wouldn't it be a good idea if we all sat around the table together, the broadcasters, the equipment suppliers, the television set manufacturers, and the consumer electronics television set makers, to actually hammer out what we actually needed, put right some of the things that were wrong, or to explain in more detail why something was being done.

And therefore, the European Broadcasting Union had a joint technical committee, which is what JTC stands for, with ETSI, the European Telecommunications Standards Institute, which pulled together the broadcasters and the consumer electronics manufacturers.

I was asked to lead this group on behalf of the EBU, and so assembled myself for the BBC, covering all UK text operations, which is quite interesting.

So I was equally able to support Sky Text, or Oracle, Teletext Ltd, Swiss Text, which, like Teletext Ltd in the UK, was the only Teletext supplier to profit, IRT, the sadly now defunct Joint Research Association between the German and Austrian broadcasters, ARD & ZDF, the German broadcasters, and RAIText from Italy, with the consumer electronics, who have an organisation called ECEM, which I can't remember what the E stands for, but Thomson, Philips, surprisingly Sony.

Pulling into those, we had Philips semiconductors and Siemens semiconductors as well, because it's no good having chipsets that don't decode things, or chipsets that don't interface with the television set.

What I did was to pull in two equipment manufacturers, Softel and MRG, both of whom were probably the leading manufacturers of systems that Ceefax would use, and some subtitling systems.

So we've got a sort of level, even from the broadcasters, some of the broadcasters' representatives were engineers, some were the editorial staff.

So we pulled everybody together, which is now everybody just assumes that these sort of things happen.

But this was around the time that the DAB were coming together, which again, used everybody that was involved in the whole value chain to work out what had to be done, rather than a bunch of techies in one room, working out something or other, providing something that was not what the editorial staff would actually want.

Great fun.

ECEM is the European Association of Consumer Electronics Manufacturers.

Yes.

The thing that was most useful was to make it look better.

The idea of being able to carry more language sets, make more colours, I mean, yellow, blue, cyan, black and white is a bit limiting.

So could we have a few more colours, if they could be redefined, that was quite a good idea.

So that you perhaps, as a broadcaster, could choose a background, which was unique to you.

There were some matters about exactly how you changed from graphics to text and vice versa.

Wouldn't it be nice to have some characters that you draw yourselves?

Because the basic graphics characters, which were basically six blobs per character position, was a bit coarse.

And because widescreen televisions were perhaps coming with power plues and other things, if you had a four by three picture, could you use the space to one side or other of the picture, or both, to display teletext?

I mean, you see this an awful lot actually today in the real video on the football or the Formula One operation, where you've got textual information down one side of the screen.

We were looking at doing that in teletext.

And another higher level, just doing more and very artistic things.

Those are the visible enhancements.

The technical enhancements were very important here.

We needed to get the specification to be clear.

I'm not saying that the specification previously was not, but we were trying to define what was normative, which thou shalt, that must be done, an important feature, or just informative, that gave a bit of the background as to why you were trying to do something.

Or the sort of custom and practice that sort of put the context in, so that whoever was writing the software for the decoders, or the control interface for the television set, actually work out what we were trying to achieve.

And as well as doing that within the specification, we also wrote a series of codes of practice that explained it in a more sort of practical level than the formal sort of restrained language that you have to write specifications in to be unambiguous.

The major innovation was a thing called a magazine inventory page.

This was, if you had a television set that had memory in it, because memory was now beginning to be cheap, well, it's cheaper, you could store all the pages.

So let's assume that you were transmitting pages with a repetition rate of roughly once every 14, 15 seconds.

You could grab all the basic single-numbered pages, non-multi-page sets, guaranteed to catch it in under 30 seconds, and store the whole lot.

And you then had a viewing experience, which meant that you were never, ever waiting for a page to appear.

And I have to say that that operation was very, very slick, and it made teletext viewing very, very different.

The problem is, how do you know that somebody has cancelled the page, or somebody has added a page?

The memory management of something that is catching whatever is coming through the air is a little bit hit and miss.

Therefore, if you transmit a page that says, these are the pages that we are meant to be transmitting, which is information that is readily available, the decoder can then decode that and organise its memory appropriately.

And so that was a major addition.

Packets 28 and 29, the additional attributes for a magazine or the whole service, we unified the coding of those so that they both have the same sort of feel to it, which previously they hadn't.

So that would actually mean that it was not compatible with whatever had gone before, but as there hadn't been any very much done before, it didn't really matter.

So codes of practice, most important.

Give some background in an educative way, things to bear in mind as you're doing this, whether it's a service or the display, how is it going to be used?

What are the benefits?

What's it going to cost?

Whether that's in money or people or the balance, if I want to suddenly go and add another magazine, and I'm not going to have any more VBI lines allocated, how much I'm going to have to slow down all the other magazines to do it.

Some of the practical hints about how people actually have implemented stuff.

And again, some of the thought history as to why it's done this way, because you can come to things in specifications, which because they were written a long time ago, and when technology wasn't so advanced, why is it done like that?

A prime example of that is this field erasure interval that we talked about, which basically means that you put the header out, and then you have to wait for a field interval to come along before you put the rest of the page out.

That was because the early decode has required that amount of time to decode the header and sort of get itself ready to go and grab the pages that are coming up.

And that's where the codes of practice came in.

Specification had normative and informative annexes, alongside, or strictly speaking, after the normative text, which is all very dry and precise.

Some additional normative, thou shalt type rules, and then something that was a bit more informative, and just gave that bit of a colour to try to get people to think in the right way.

All in the single normative document, so actually given the specification, just from one document, you could actually build whatever you wanted to do.

But then normative annexes talk about how you number pages, how you use the constantly erased page bit and the update indicator, and things, how you transmit the pages, how you decode things, default operation of decoders, all this sort of stuff, so you're actually in a code of practice, how you navigate using the two systems, Flof and Table of Pictures Top, these sorts of things, and just flagging up where it all went, all in one document.

But you need to read the codes of practice to really understand if you had to do it for real quickly, and it was something that we, for the EBU and ETSI, in getting this differentiation put in.

I think it's interesting because perhaps it's one of the few, possibly, technologies that we deal with where it matters how you use it as much as how it works.

So if we go back to our example of SDI, nobody really minds how SDI works.

Most people using SDI just get to plug stuff in and send data down the line.

There's no real knowledge or nuance.

But I guess a modern day example with HTML and writing a web page, you kind of have to know how the browser's working and what the rules of the road are.

There are some better ways of doing things than others.

And similarly here, it's the same task, isn't it?

It's putting text and graphics in a raster, so to speak, on a page.

So there's ways to go about it which most standards probably don't need to give that level of guidance.

Everything you've said in the last two episodes previous has been about how the editorial staff do this and getting them to do this and the other.

So normative and informative are equally important, I would say here.

Yes.

What I think DVB should be remembered for as a suite of standards was that it starts off by somebody having the commercial requirements laid down and that is then given to the technical groups to go and write up the way in which you do it, the recipes of hardware, software, protocols, and whatever that makes it all work.

But you've got to start off with what are you trying to achieve, not, oh, there's a very cool technology that we should be using, which is actually sort of how Teletext started.

Oh, yes, this is great fun.

The electronic program guide.

EN 300-707 was the first open standard electronic program guide.

This came about because whatever an electronic program guide was, which was interesting because nobody knew, there was a feeling that there were going to be a number of proprietary providers of electronic program guides from America.

Wouldn't it be nice if the Europeans got in first with an open standard?

And the obvious way of doing it was to do it using Teletext.

So we've got a group who understood the technology.

And I have to say, we had a great group who worked together well.

The requirements for the electronic program guide had to work from something that was a 4-bit processor.

Now, bearing in mind that normal Teletext is 8-bit, this was obviously a step down to a specialized graphic chip, the Siemens Megatext.

There was not much difference between that and a fully spec top of the range broadcast character generator.

So we've got a wide range of requirements in terms of the technology to cover.

Oh, yes, this was really very, very interesting.

In the UK, on BBC Ceefax, on Teletext, Teletext Limited, on Sky Text, you could find the listings for BBC One, BBC Two, ITV, Channel Four, when Channel 5 came along, Channel 5, and on some of the channels that were carried on the Sky analog satellite platform.

So the tech services had both the sort of parent broadcaster services, the opposition, and yet even more opposition in terms of listings.

This was unique.

RAI Uno would only carry RAI Uno's listings.

All right, in Germany, ARD and ZDF carried their listings, but they didn't cover anything from RTL.

On the idea of electronic program guide, which is across a platform which enables you to see everybody's programs was a bit strange.

The fact that an electronic program guide could be operated by somebody who was not a broadcaster.

And then, who actually owned the look and feel?

If it was an EPG operator that wasn't a broadcaster, would they make it look not like the parent broadcaster?

And of course, how are you going to fund all of this lot?

And the answer is no.

So you had to have something that worked like that.

And getting the broadcasters to actually acknowledge that they might actually carry the program listings of another broadcaster was a major effort.

And they just couldn't see it.

Now, we had come in the UK and developed this environment, where in a lot of ways, the Ceefax or Teletext Limited service, they were an additional service, sort of on the top of the television, rather than being linked into the television programming or the broadcaster.

Because after all, Teletext Limited didn't produce any video or any audio.

They were entirely a text operator.

And that was how we saw the world.

But it wasn't what was shared.

To try to get harmonization of that was quite an interesting exercise.

Of course, the manufacturers wanted to surprisingly put it into simple text to test sets.

They felt if manufacturer A put it into their simple text set and could charge a few more euros for it, or while manufacturer B was not putting it into their simple sets, this would be a commercial advantage.

So you have them all sitting in the room, trying to not declare exactly what their design ideas were.

And on the more complex sets, was this something that really was equivalent of putting your television set in a nice wooden housing to make it look more expensive?

And then manufacturers would quite like to have the look and feel rather than the broadcasters having control of the look and feel.

And how are they going to make the product distinctive?

Because one Teletext page does look rather similar to another Teletext page, no matter how it's displayed.

And if all you're doing is taking basically raw data, just the text of the program listings, how can you make that look, you know, do you want to have pompous elaborate fonts?

I don't know.

And we then had technical issues as to how we could squeeze this in the limited bitrate.

The idea that you might have multiple electronic program guides transmitted in the same VBI.

After all, if you assume they're basically data broadcasting services, as I said earlier, we have 13 million of those going out within the existing coding structure.

And the problem of managing a database with no return path, a bit like the magazine inventory page, if something changed, how do you flag that it has been changed to the database and to get that to respond appropriately, whether that's to add something or to subtract something or to check that what is actually got in it is what the broadcaster thinks it should have in it.

And then an interesting point, which is the persistence of data when the television is turned off, that you instantly got the electronic program guide.

If you think about what happens at the moment with terrestrial television in the UK, you turn on, you'll instantly get now and next within seconds, but you then have got how much of the other channels and further in the future you get.

The whole lot actually is downloaded at the moment in about 20 minutes.

But basically how much do you get?

Now, if you started off with a database that was half full, when you turn the television on, that would sort of speed things up, but it might not be accurate.

Yes, program delivery control and BPS, the current German system, linked very much to this accurate recording type thing, as we know it now in the DVB, the idea of how do you program your video recorder to record the program that you want.

If you think about it, that actually is two parts.

One is pre-selection.

We call it electronic program guide these days.

In the days of teletext, it could just be the ordinary listings page.

So that says, okay, video recorder here is some parameter of the program that you need to do to able to record and then record control, which is basically when the program comes along to turn the video recorder off and the like.

We had two different ways of doing record control signaling.

One was a German system called VPS, which was not teletext, which would only reside on line 19, which, as I mentioned, I think in a previous episode, I mean, the certain German television sets wouldn't decode teletext on line 19, because that's where VPS lived.

It's not holes in your page, or the system that we use, program delivery control, which use packet 830 type 2, which is a data broadcasting packet for broadcasters and the second flavor of it.

The first flavor of it is transmitted once a second.

The format twos are transmitted 200 milliseconds apart after that.

So you got four of those per second.

So what do we need?

Well, we need to have a unique program ID.

Well, if you think of the country that you're in, some identification of the network number and a marvelous thing called the original build start time is going to be unique because if you think about it, if you're building up a channel, you are working out what programs you're putting out at a particular time, and you could only have one program going out at one time.

And therefore, if you make it the original build time, that is a unique combination.

So that therefore gives you a program ID, which could be stored, transmitted into a teletext listing page by using packet X36.

Those are the other uses for those pages.

Those packets are for diacritical marks.

And the basic format of this is it gives the x and y character position on the screen, and then followed by the program ID.

So we then move to how to do it.

The channel for using Intel fax is their text provider.

We're using one label channel for record control.

BBC wanted to have a more sensible way of reliable way of getting the start done.

So we waited until Gemstar with their video plus system came in, which basically just programmed the recorder for the channel and start time.

So if I recall correctly, video plus in Radio Times magazine, you'd see a number next to the program.

Yes.

And then you type that number into your video recorder.

And it would just be at the right time.

Yes.

Otherwise, there would be no way in if you put your thing on eight o'clock, you wouldn't have any way of timing it, would it really?

Yes.

And the VideoPlus+ code was very clever, because at normal time, so on the hour and a half hour, there were very few characters in it.

But if you've got something that was like sort of three minutes past the hour, that will be an eight digit number.

So if you want to Coronation Street, EastEnders and the like, there's a three digit number.

And most of them were four or five digit numbers.

Or you could do it, but this was more.

The thing was that you needed a data broadcasting decoder to decode the record control, while you need the full text decoder to use a teletext listings page for the preselection.

And if you're a video recorder manufacturer, you would not want to put an expensive teletext chip in.

So most of them didn't, they used a data broadcasting, especially designed a PDC decoder, and it was sort of an eight pin chip, rather than being a 36 or 38 pin teletext decoder chip.

Channel four had done this, but with a lot of support, we took time talking to the industry about what we were trying to achieve.

So what were we trying to achieve?

All right, first question.

What is a program?

Ah, this is a lovely one.

I decided and told presentation department that what I felt it was that we needed to give the viewer the same experience of tape as live.

So what was that?

Well, we wanted to have, we wanted to identify that we were BBC One or whatever.

We wanted to ensure that we got any health warning.

This program was unsuitable for those with a nervous disposition and things.

But in those days, we didn't have as many of these trigger warnings as we have nowadays.

We wanted the program itself.

And we probably wanted to have the next item.

That could be that we had the action line if you've been affected by items in this program, or it could be the promoting the next episode of the program or something else.

It also meant that we guaranteed to get the end of the program because there's nothing more annoying than you not getting the end of a program.

I have to remember, in these days, there were none of these squeezebacks and goodness knows what else at the end of the programs.

There was actually no BBC blocks on the front end of programs either.

So it was network symbol, the program, and have you been affected idea.

That was the BBC.

Others might have different ideas.

It could be you just take the program.

That's one extreme.

The other one would be that if you're a commercial broadcaster, you take the ad break before the program, or the ad breaks during the program, and the ad break after the program.

It's up to you to decide.

So you had to decide what a PDC program was versus the recorded program.

It could get very complicated, but we worked out a starting rule and a stopping rule.

This really was mind bogglingly simple.

We actually had gone through, there was a phase where somebody else had tried to work out what it was and came up with all the various situations.

PDC had the ability to put the video recorder into what could be called record pause.

So you've got the tape all laced up.

You have got everything there.

It's just that the pinch wheel hadn't gone against the capstan so the tape wasn't actually moving.

So starting rule, 30 seconds before the program start, i.e. the start of the symbol, send a packet out to say PRF set, put it into record pause.

You did that unless the vision mixer was in hold.

The vision mixer was in hold, you didn't know when the next program was going to start, therefore there's no point in queuing up all the video recorders.

At the start, the last item before the genuine program, clear PRF, that's record play.

Therefore it unpaused itself and went into play.

If you suddenly discover that you have got, the program is already on air, you pull out the PDC code at once.

That covered the fact that all of this stuff was predicated on an automation system and a schedule.

If the network director just press the go, press the take next button, you have to be able to respond very rapidly.

And then at the end of the program, the next item after the end of the genuine program, i.e. we've got the health warning or the action line reference, you then would send out stop packets, at least five of them.

And then if the starting rule hadn't already started, you continue doing that.

So we were explicitly stopping the recorder from recording during interstitials.

That was necessary because you could have a situation where you were using PDC to competitively obstruct the competition.

You could overrun the end of the program, which would mean that the video recorder was still recording your channel, but that then meant that the video recorder couldn't change channel to pick up somebody else's channel.

At the time, there was an awful lot of very interesting goings on about exactly what time Coronation Street started at half past the hour, which was 29 minutes past.

And there's other nefarious goings on.

This is because the theory of it was that the video recorder should be sitting there all the time, scanning all the channels all the time, but not recording, just see if the program label had changed.

That's why our starting rule was 30 seconds before program start, because that gave about 20 seconds before a 10-second symbol, which was normal.

Actually, symbols are a little bit less than that.

But basically, if you think about it, it takes four seconds or five seconds to sVITCh, to retune, acquire enough packets to know what channel you're on and whether you've got the label set or not.

And then if it wasn't, you then move on to the next channel.

So we were putting something out that guaranteed that you could swing through all five channels that were available and see if the program label was there or changed or whatever.

No manufacturer ever did that.

What they did was they started perhaps a minute or two before the time that you'd normally put in the video recorder and woke it up then.

Was that because they couldn't tune in to multiple channels?

No, they just didn't do it.

They just did not get the whole purpose of it.

Wimbledon is the prime example.

In those days, Wimbledon always got rained off, which meant that it always started at 10 o'clock the following morning rather than at two o'clock the following afternoon.

And that meant if you want to record Wimbledon, you just record Wimbledon.

It should at 10 o'clock say BBC1 Wimbledon and it should pick it up.

But of course it didn't turn itself on until two minutes before two o'clock in the afternoon.

It really was that they just did not get the idea that this is what the requirements of the broadcasters were.

You just have to have an ID for the program and whenever it occurred, it will be recorded.

Unless you're recording something else.

Okay, we're coming to the end of what we're talking about.

Let's move from Teletext to what was going to happen.

With digital broadcasting, it would look a little bit prettier than analogue.

So would there be an opportunity to effectively send web pages or web-like pages to digital televisions?

Although there's a DVB spec there for Teletext, if the television could take HTML, if it had a genuine mode in it, you could actually have a very simple internet viewer in your television set.

However, the BBC had decided, the ITC and the BBC had decided that the answer was not to go to HTML because actually HTML in those days was very, very primitive.

It didn't actually look very good.

But into MHEG5, which was a broadcaster's or screen-derived way of coding and displaying information which was otherwise known as red-button text in the BBC.

So you actually were able to get stuff that looked more like stills from television than the rather chunky graphics that you got on Teletext or the semi-chunky graphics and layout that you got on the internet in 1996-ish.

The example there on the left TV, by having the better text, it almost kind of shows how little text there ever was.

For me, it kind of changed the relationship because you're kind of used to having a page full of text.

Yes, there's a lot of this.

There's perception.

The other thing, of course, was that web pages are designed to be viewed fairly close up.

And the Teletext or MHEG5 is sort of viewed at five times the picture height.

Definitely, yes.

Sometimes without your glasses, so.

Yes.

I mean, MHEG had other advantages.

You could take quarter-screen live video and embed it in, which is what's happening on the left, use simple animations, which is actually what's happening on the right.

And that was a policy by the UK broadcasters or broadcast regulators to make digital something that was different from analogue.

Continental Europe, most of the broadcasters, all that happened was that they added an MPEG in parallel with the palette encoder that had the SDI of their play-out suite, while in the UK, we changed the shape of the picture as well.

So digital was 16:9.

It had DVB subtitles, which is an area where I also wrote the specification.

It had MHEG5 text service, and we very rapidly moved to having audio description there as well.

So it was something different.

Again, it should please the set manufacturers, because a 16:9 set looked different.

So even if there wasn't a picture on it, you could keep up with the Joneses by having a wide screen set.

We got flat panel displays, which accelerated things quite nicely.

So it was in 2012, wasn't it, that the final Ceefax pages were transmitted.

Was that the same across the other UK broadcasters, or had they already done it?

Well, yes.

The other main broadcaster was Teletext Ltd.

Now, they had been given space on PSB2 MUX to do their MHEG5 service, but they couldn't make any money out of it.

Teletext Ltd decided that they would remove their text services from all platforms.

Not a good move, because they didn't tell Ofcom.

It was a bit miffed.

Broadcasters were even more miffed, because what actually technically happened was that Teletext Ltd turned off their entire magazines on analogue television.

An awful lot of ITV companies have no ancillary text service.

Channel 4 had got 4TEL, which was its own service with the great bamboozle name.

What then happened was the only Teletext in the VBI were subtitles.

Subtitles are intermittent.

And there is not a single decoder chip that was available then that were able to decode it.

So no Teletext decoder could decode subtitles on their own.

So there was a mad panic, because that actually put an interesting philosophical debate as to whether the broadcaster was in breach of their subtitling quotas, because they were transmitting it, it was just that nobody could receive it.

And some rapid work on that day to prevail upon the broadcasters to do something that put more Teletext into the VBI that enabled continuous text, which meant decoders might work, and to Teletext Ltd to put a line or two up of that something or other that enabled television sets to lock on so that the subtitles could be seen.

It was, again, something that... it's interesting to think about this.

The industry had got so used that Teletext was just there and it worked, because it did.

So when something rather different happened, an understanding that your decoders couldn't actually decode the signal you're putting out if there wasn't somebody else's signal alongside it.

A very inspiring day.

Okay, so perhaps to bring all this lot to an end, your television set was more than just audio and vision.

Teletext really was the internet of 40, 50 years ago.

And I mean, Teletext Ltd made their money because everybody brought their holidays.

It now seems perverse.

You sat down your television set data per page, which is an infinite number of multi-page sets from each of the travel agents.

And you sort of waited till one came around that might interest you.

You then pressed the hold button and probably wrote down some of the details from it.

You then decided that perhaps that wasn't quite what you wanted to do.

And you then unheld it, or I don't know, some of the other pages, and made a few notes.

And then probably went and sort of put in a particular page number for the travel agent, and roughly what the subpage was as the particular one that you wanted to do on.

Dialed that in and put that on your television.

Or pressed the hold button to hold the screen so that you could see it.

And then you phoned up the travel agent.

That's how you booked your holidays.

That isn't how you do it now.

It isn't that how you [did] it in 2010 when Teletext Ltd. removed their text service?

It goes to show how much we know that everything's changed.

You don't need to pay per ticket anymore and all this kind of stuff.

So, I mean, the travel industry changed massively and it's partly because of the technology which is behind it.

But I think it goes to show how much of a big deal it was to even find out how to get on holiday, rather than sitting in a shop and a travel agent, which is the only real option.

This actually allowed you to at least dream from the settee.

And many people then took the next step and, say, they made money out of it.

It was a profitable business.

It was a very profitable business.

For one year, when Teletext Ltd. paid more tax than the budget for Ceefax.

What's interesting, of course, is the technology was specified over 50 years ago.

As I outlined, we were still developing it 20 years later.

We're now 30 years on and it's still being used.

The way in which we get subtitles from the playout suite into the encoding system is still teletext.

Slightly different.

It's teletext waveform within an HD signal, but it basically is teletext.

And in other countries, teletext is still on the air.

And yes, in all the other countries, teletext is still on the air.

And the text creation system made the best sales in the beginning of this century, which was four years after the new text spec had come out.

And at a point where, you know, teletext was not really being supported or expanded within the UK.

But it's still there 50 years on.

It's amazing.

I'll just finish with this.

It also was very useful because so much of what we were talking about is what happens with a packet-based system like IP.

In the previous episode, I talked about this input data bridge that was able to distribute various services in various lines according to a set of rules.

That looks suspiciously like quality of service to me.

I was going to say, yeah.

You've got the fact that you couldn't put too much down a particular line.

You've got how much null packets have you got.

And all of this lot, I was doing in the early 1990s and was reusing in the early 2000s, putting video and audio over IP on the BBC network.

And likewise, the whole idea of carouseling of service every 14 seconds or thereabouts, and how you might have different carousels for different things.

But we carousel our EPG data now and next is done within seconds.

The next few hours, this channel is done within a minute or so.

Other channels on the same timescale, five minutes.

You've got all of these sort of concepts.

And there's an awful lot here.

It's simple, which is grasping the fundamentals which we now use and we just sort of assume happens.

It was great fun.

That's the major, major thing.

Well, absolutely.

And I think things like packetized data, they come up in so many areas because it's fundamentally a good idea.

And I think it's certainly blossomed since teletext and other technologies took it on.

And what I'm pleased about is that we've really been able to cover the whole thing to a certain extent, the usage of it, but also how it's put together.

And I just think that having that in one place is really valuable.

And I appreciate you spending the time with me to look over those slides that, as we said at the beginning, you did for the 40th anniversary of Ceefax, and now it's the 50th this year.

So thank you very much, Peter.

I'm sure everybody watching this would be very appreciative of your time.

And so if you could like and subscribe, that would be fantastic.

It's a great way to show it.

It's easy to do so.

Fiona and Becky from PageMelia PR are fantastic and help me make sure that broadcast focus keeps going week by week.

So big thanks to them.

And I'll just finally say thank you, Peter.

Really appreciate you spending the time and hope to speak to you again soon.

Thank you very much.

It's always good to try and pass on the information, things that I've discovered so that people can exploit it and perhaps not make the same mistakes as I might have done over the years.

Thanks.

Bye bye.