- From: <Johnb@screen.subtitling.com>
- Date: Tue, 29 Mar 2005 13:21:58 +0100
- To: gadams@xfsi.com
- Cc: public-tt@w3.org
- Message-ID: <11E58A66B922D511AFB600A0244A722EE57DAE@NTMAIL>
Glenn,
Current practice for subtitling in broadcast TV is to hold an archive of all
subtitle files for all material that has been, will be, or may be broadcast.
This can amount to many tens of thousands of files. (David can probably give
you a number for the BBCs archive!)
Current practice (at least for us) is to combine all individual language
files into a single multi-language package for a given program.
So, subtitle files are originated by subtitlers in a single language - and
transferred, QA'd and then typically combined into a multi-language 'air'
file.
These 'air' files are then held in a 'subtitle archive' that can be accessed
by the insertion systems when station automation requests the playout of a
particular piece of material. Typically for a European operation there may
be on average 4-6 languages present in each multi-language file (although we
have systems with many more langauges per channel than this).
There are many models being discussed within the ad-hoc committee, doubtless
there will be a transition interval where DFXP content is held externally to
the media content. Indeed it may be (for operational reasons) that the
combined MXF/AAF with subtitles incorporated internally is only used as a
'between broadcaster' format - not as a near to air format.
So, a nominally single language DFXP could result in a proliferation of
files (probably by a factor of 4 - 8) for broadcasters. Note - we are
assuming that insertion equipment will move across to using DFXP
**directly** here.
By onerous, there are implementation issues to consider. The increase in the
number of files creates a subtle problem. The files have to be referred to
by the automation equipment, changing from a multi-lingual system to a
single language per file concept means that either the automation system has
to send multiple demands to the insertion equipment (for each language) -
changing the whole concept of the automation interface, or the insertion
equipment has to determine which individual DFXP files constitute the
fileset for a given material reference. It is unlikely that many
broadcasters will wish to make changes to station automation... this is VERY
much an area of "If It Aint Broke Don't Fix It" - by which I mean there is a
strong resistance to messing with such a critical aspect of a broadcasters
operation.
So we can fairly safely assume that the insertion system will need to expand
a single material reference into a fileset. This in itself doesn't sound to
difficult until you consider that the system will need to be created and
maintained by human operators!. At present there is one point of potential
failure - the appending of a new subtitle language 'stream' into the
archive. With the multiple files approach dictated by DFXP's limitation to
single language - more opportunies can arise for problems.
So - single language DFXP increases the number of files to handle (by
perhaps a factor of 4 - 8), and the omission of a conditional content
mechanism may multiply that again....
BTW
Is there any practical reason why DFXP couldn't be multi-stream, or is it
simply a philosophical issue? What (apart from the schema) prevents a DFXP
document having effectively more than one instance of the tt element
structure?
e.g. (introduction of element tts "timedtext stream")
<tt xmlns="http://www.w3.org/2004/11/ttaf1">
<tts xml:lang="fr-fr">
<head>
<meta/>
<styling/>
<layout/>
</head>
<body/>
</tts>
<tts xml:lang="en-uk">
<head>
<meta/>
<styling/>
<layout/>
</head>
<body/>
</tts>
<tts xml:lang="en-uk-caption">
<head>
<meta/>
<styling/>
<layout/>
</head>
<body/>
</tts>
</tt>
regards
John Birch.
-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 29 March 2005 12:28
To: Johnb@screen.subtitling.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming
Could you describe what you mean by "subtitle archive" and "onerous to
require ..."?
_____
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com]
Sent: Tuesday, March 29, 2005 3:47 AM
To: Glenn A. Adams; russ.wood@softel.co.uk; public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming
Glenn,
An issue that was discussed recently at the AAF/MXF EBU ad-hoc subtitle
commitee....
While the generation of multiple DFXP 'files' for individual languages is an
acceptable solution, I feel there may yet be a requirement for a
'lightweight' conditional content mechanism. The specific example I have in
mind is to support the concept of viewing 'watersheds' - i.e. content
unsuitable for minors.
In this case the majority of a subtitle file would be suitable for all
viewers - but the odd word or phrase may be 'sanitised' for pre watershed
(e.g. 8.00pm) airings of the programme. It would be onerous to require a
subtitle archive to retain multiple copies of content to cater for just the
alteration of one of two words in a 1300 line subtitle file. Is there any
possibility of introducing a conditional content facuility to DFXP that
would support this kind of minor use?
A second use of this mechanism, which might be a stretch too far, is to
support subtitle files that can be used as captions (i.e. near verbatim +
sound cues) or as subtitles. In this case the conditional content may be the
'sound cues' and possibly the replacement of some of the subtitle lines with
less accurate (but more concise!) translations.
best regards
John B.
-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 26 March 2005 05:47
To: Russ Wood; public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Profile (DFXP) Streaming
DFXP supports general use of xml:lang attribute in order to (1) specify a
default language for document instance and (2) to annotation language of
nested content. It is up to the author to decide how to use this mechanism.
For example, an author could potentially specify different <div/> elements
using different languages, or different <p/> elements, etc. Nonetheless, the
intention is not to explicitly support in DFXP conditional content selection
based on preferred language. In contrast, conditional content selection will
be supported in AFXP. The intent with DFXP is to have already made all
conditional selections prior to transmitting/exchanging in DFXP format. This
means that if an AFXP document supports course granular conditional
selection between parallel language representations, then one may produce
multiple DFXP document instances from a single AFXP document instance, by
enumerating over the condional parameter space (of which each permutation
may produce a distinct DFXP document instance).
Regards,
Glenn
_____
From: Russ Wood [mailto:russ.wood@softel.co.uk]
Sent: Monday, March 21, 2005 5:36 AM
To: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming
3) I don't see a problem with allowing different languages in the same
document but amalgamating different language files at run time is not
difficult.
Received on Tuesday, 29 March 2005 12:05:39 UTC