- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Tue, 29 Mar 2005 08:13:11 -0500
- To: <Johnb@screen.subtitling.com>
- Cc: <public-tt@w3.org>
- Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C03C379@longxuyen.xfsi.com>
1. In the main archive, you could have a single DFXP document that
combines languages and usages (adult/child), and then use an XSLT
transform (or XQuery) to select the portions required for a "send to
air" document.
2. While the TTWG does consider streamability to be a necessary
property of DFXP, it drew the line at actually defining a streaming
form, which was considered out of scope; however, there is nothing to
prevent a future specification (either in or out of W3C) from defining
such a form.
G.
_____
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com]
Sent: Tuesday, March 29, 2005 7:22 AM
To: Glenn A. Adams
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Pr ofile (DFXP) Streaming
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 13:13:06 UTC