W3C home > Mailing lists > Public > public-tt@w3.org > January 2003

RE: TT and subtitling

From: <Johnb@screen.subtitling.com>
Date: Fri, 31 Jan 2003 17:21:08 -0000
Message-ID: <11E58A66B922D511AFB600A0244A722E6C5FD7@NTMAIL>
To: glenn@xfsi.com
Cc: public-tt@w3.org

I wrote:
> 	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. 
		Glenn wrote:
> 	Is this a problem in the DVB subtitle format or is this merely
> 	an operational constraint based on broadcaster unwillingness to
> 	assign sufficient bandwidth, and thus force pre-delivery? 
	Pre-delivery is present in most aspects of DVB streams - its just
that subtitles are more peaky than video or audio (which are often
constrained to constant bitrates).

	Subtitles in DVB have certain characteristics that exacerbate
delivery - 1. they are bursty - a new subtitle may occur every 3 seconds or
so with nothing in between, 2. when subtitling a channel, often multiple
languages are carried, but the subtitle on air times for all the languages
tend to be similar. So we have a very peaky demand for bandwidth.

	The 'last subtitle hangover' is primarily an outcome of the lack of
notification of a change in the synchronised parallel content (video /
audio) **after** subtitles for unsent video have been put on the wire.
(video / audio and subtitles are not isochronous) The subtitles have to be
pre-sent - because of the DVB decoder model (decoders are slow to process
subtitle data) and because of bandwidth limitations. 

	In DVB, subtitles are pre-sent in a PES packet which defines a
bitmapped region. These regions are then displayed according to a
composition page (analogous to the on air). Clear down is achieved by
sending a composition page that does not reference the pre-sent bitmaps.
Increasing the bandwidth available to subtitling reduces the 'time windows'
in which the 'hangover artifact' can occur (since we dont have so much
latency in the system) - but at the expense of a huge percentage of inactive
bandwidth. Generally the decoders eat packets in linear fashion - so even if
a clear down page is sent as soon as a program change is detected - the
decoder will display the subtitle - then process the clear down. The
duration of the hangover is dependent on the speed of the decoder (to
consume subtitling data) and the bandwidth available to send the clear down
(which affects how soon the decoder sees it).

	This is a practical problem that arises from the non-isochronous
nature of the streams of data in a DVB program and the implementation of the


	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.
Received on Friday, 31 January 2003 12:22:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:23:58 UTC