TT and subtitling

Dear All,

Excuse the rather lengthy email - you've been busy while I've been sleeping!

I work for a subtitling company, so the following comments will undoubtedly
be biased towards the utilisation of TT in that arena. I have tried to adopt
Glenn A. Adams nomenclature wrt Access Units and contexts, my apologies to
Glenn if my usage of those terms is not as he intended.

Robin Berjon wrote:

	>In which way do you think that having to wait for an empty line to
come to erase 
	>the text is easier and safer? I would tend to think that those two
lines might 
	>be split into two AUs, and that if for some reason the second one
were dropped 
	>(which isn't all that unlikely in a number of streaming transports,
especially 
	>unidirectional ones) the text might linger there forever (well,
until another 
	>line comes which could be immediately or in a long time).

This is exactly what happens now in certain types of subtitling - and it
causes exactly the type of problem you outline.

A more subtle problem occurs in DVB subtitling (STREAMING, SYNCHRONIZED).
Common practice for DVB subtitling is to use file playout for subtitles -
with rendering to DVB bitmap just prior to transmission. In DVB subtitling -
the subtitle is transmitted ahead of presentation time by as much as 5
seconds (due to limitations on bandwidth allocation to subtitle data).
Unfortunately it is uncommon for broadcasters (specifically re-distributors
using subtitling for localisation) to know when an ad break is about to
occur as these are often triggered by cues embedded in the incoming TV
program. Consequently a subtitle may be on the wire when an advert break
occurs. This can lead to a nasty effect where a subtitle from the
interrupted program hangs over the start of an advert. This is very
undesirable from the advertisers point of view - and the broadcaster as he
loses revenue for spoiled adverts. There is no real **effective** mechanism
to resolve this problem.

	>I would see no reason not to be able to support both duration and
overwrite 
	>approaches though, it should be simple enough.

While for subtitling purposes a duration based approach solves certain
problems, it does not solve all problems caused by interruption of the
stream or change of intent. It is certainly preferable to an overwriting
approach.

Jason Terando wrote:

	>I'm just joining in, so excuse me for any non-sequiturs, redundant
points or simplistic questions.

I've already set a low point for these I fear :-)
	
	>Some devices/applications (consumers?) are going to use formatting
characteristics that other consumers won't.  
	>Closed captioning (at least EIA-608) doesn't really deal with the
concepts of fonts, unlike subtitling and most "Internet media" file formats.

In general, support for fonts in subtitling is limited. Our proprietary
standard only provides for two fonts within a 'program' subtitle file.
Further the actual fonts used for display are severely restricted by
readability issues and in some cases regulatory issues. Fonts and WYSIWYG
remain a major headache in the subtitling arena.

	>As well as defining an XML schema, it might be useful to establish
rules/behaviors that consumers would abide by if they come across
 	>information in a TT file/stream that they don't process

Indeed, the lack of default rules is a problem with the various
implementations of DVB decoders :-(.

Glenn A. Adams wrote:

	>I do have some doubts about whether we should try to
support...."data tunneling" mechanisms....

Teletext magazine transmissions consist of timed text where different text
instances are repeated at intevals (page refresh). In addition other
features such as clock and fasttext require periodic transmission much the
same as V-Chip ratings. TT might be a useful format for the definition and
exchange of Teletext magazine content.

Erik Hodge wrote:

	>The *wire format* I think is what we probably don't want to define
for TT, but we certainly should think about it while designing the *file
format*.

IMHO a very low bandwidth *wire format* would be essential for the adoption
of TT in the emission context of the subtitling and closed captioning arena.
However I suspect that TT in this arena would predominate in the authoring
and storage contexts not the emission context, not least because of the
presence of existing standards.

Neil smith wrote:
	>The possibility to indicate various formatting styles should be
possible per line of captions - emphasis, alignment / positioning, 
	>even colour may have their place

I think the 'access unit' should be considerably smaller than a 'line'. For
some subtitling styles (snake and teletext add-on) the ability to time
individual words is necessary. Further - the ability to change style (colour
/font) on a word by word basis is sometimes needed. I personally would see
**no** use for per character 'access units', but others may! Ideally the
scope/size of the 'access unit' should not be defined. Snake and teletext
add-on subtitling would imply a further requirement on TT - that of
association of 'access units' into larger structures.

My current personal view is that TT should define a streamable file format
consisting of self contained access units:

Each access unit should reference a preferably orthogonal timing element
that supports at the minimum an on air time, optionally an off air time,
where timing is either relative or absolute (relative timing would require
the timing element to include a reference to the previous (and next access
unit - to support trick play / reverse play)). The ability to group 'access
units' together into a composite group is also desirable (e.g. words into
lines, lines into subtitles). Display style should be external to the
'access unit' and the 'access unit' should allow the inclusion of a content
definition (e.g. speaker, audio description...). A facility for defining
additional supplementary information eg authors, creation dates etc should
be provided. Guidelines for the streaming of the format should be developed.

regards

	John Birch

> 	The views and opinions expressed are the author's own and do not
> necessarily reflect the views and opinions of the Screen Subtitling
> Systems Limited.
>