Does HDTV support Teletext? DTV (Sky-Australia + Sky-NZ [Pace Decoders] supports teletext.)

Does HDTV support Teletext?
DTV (Sky-Australia + Sky-NZ [Pace Decoders] supports Teletext.)
Certainly there is room for an improved HTML (with Unicode-16 support) based
Teletext.
An extremely trimmed down HTML could still support images using
image2html_table algorithms.

http://HireMe.geek.nz/ wrote:
Does HDTV support Teletext?
DTV (Sky-Australia + Sky-NZ [Pace Decoders] supports Teletext.)
Certainly there is room for an improved HTML (with Unicode-16
support) based Teletext.
An extremely trimmed down HTML could still support images using
image2html_table algorithms.

Well the DVB systems support both World Systems Teletext (i.e. the same text
system as used on analogue broadcasts in most PAL and some SECAM
territories - CEEFAX and TELETEXT in the UK) and also the newer MHEG-5
system that is far more graphically flexible than the old WST system. Both
systems are used in the UK - MHEG-5 on our DVB-T system, and a mixture of
WST and a proprietary system (OpenTV) in use on DVB-S. The MHEG-5 stuff
supports graphics, more colours, integration with video streams etc., as
does the OpenTV solution (but this is a proprietary - and not really open at
all - standard) The BBC run similar text and interactive TV applications in
both MHEG-5 and OpenTV over here.

The subtitling on DVB can be separated from the text support as well - with
DVB subtitles being supported via a separate standard (based on encoded
graphics rather than ASCII style text and a receiver based character set) as
well as a version of the WST system (that is also used on analogue TV)

(The main difference between WST via analogue and WST via DVB is that the
WST data is encoded as part of the vertical blanking interval on analogue,
whereas it remains as data packets - and nothing to do with the video
service - in the MPEG2 stream carried over DVB)

Steve

http://HireMe.geek.nz/ wrote:

Does HDTV support Teletext?

Too broad a question. (Digital) HDTV programming is always sent
over some sort of a broadcast framework - encapsulated within it.
In the US, the framework is based on broadcast standards defined
by a committee called "ATSC" (and often called by that name too.)
In Europe and Australia, the framework is called "DVB".

The _framework_ is what defines what extra services that can be
sent to the viewer, not the picture content or production format
(be that HDTV or SDTV). Both "ATSC" and "DVB" are flexible enough
to carry practically any kind of data streams and extra services,
given they do not exceed the obvious bandwidth limitations.

The framework itself does not care whether you transmit old-style
teletext data or some fancy shmancy new kind of information service
- the only practical limit to it is if the standard bodies,
broadcasters and makers of STB receiver/decoder equipment can just
mutually agree upon which standards and additional services _should_
be universally supported, and what is their data format.

Now, the inclusion of extra services can be (and usually is!)
decided on a national level - or on a broadcaster-to-broadcaster
basis. Some countries want and need some extra "enhanced" features
(besides just broadcasting picture and sound) so they make them
standard features in their broadcasts - something that people
will learn expecting to get. Some other countries or broadcasters
could care less, leaving the extra features out and never using
them in their networks.

Currently, there are at least three competing standards for creating
interactive applications and information services on top of the DVB
broadcast framework: MediaHighway, OpenTV, and MHP. (MediaHighway
and OpenTV are - despite the name of the latter - not open standards,
but MHP is.) All of them are based on having a Java Virtual Machine
and a standardized API for creating programs that run on the
receiver/decoder (set top box). Possible applications range from
enhanced teletext/information services and browsers to program
guides, to games, voting applications, electronic banking, and
shopping services, etc.

If interactive applications are what people want, MHP is probably
going to be the winner in the long run.

It is expected that DVB countries which now have popular Teletext
services, will switch over to using one of these Java-based
platforms, and eventually deploy a system in which the STB
runs a Java-based simplified (web-)browser(-alike) application
which displays similar content - but this time with proportional
fonts, inline true color images and better navigation (hypertext
links etc.) These kind of services are already up and running in
some countries, although the market still lacks good STBs for
using them (the current MHP-enabled STBs are lousy at best). For
some examples, see http://www.sofiadigital.com/mhpproducts.php.

Meanwhile, at least the DVB framework has a standardized way of
transmitting the old-style, regular teletext services embedded
within the digital streams. Many countries which have long had
teletext on their analog networks, are running these old-style
teletext services on digital services as well. This scheme
usually involves a teletext-aware STB, which either has a
built-in teletext browser or knows how to encode teletext
data into its analog outputs (so that you can decode it with
the teletext decoder inside your old tv), or both.

DTV (Sky-Australia + Sky-NZ [Pace Decoders] supports Teletext.)
Certainly there is room for an improved HTML (with Unicode-16
support) based Teletext.

The improved HTML-based "teletext" is just what some countries
are trying to take in use. See
http://www.sofiadigital.com/arena.php and the downloadable
PDF on that page.

An extremely trimmed down HTML could still support images using
image2html_table algorithms.

Browsers based on the MHP platform can usually display JPEG and
PNG images. I doubt anyone (at this age of modern information
technology) would any longer like to limit any such system into
using awkward tricks and gimmicks for getting pictures on the
screen. The support for common image formats is already built
in to the specifications of these platforms.

--
znark