RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming

In point 1, I mean DFXP. You could, e.g., place parallel languages in
separate div, p, span elts, etc., although this is not a recommended
usage for interchange. Then you could use XSLT/XQuery, etc., between
your archive and over-the-air inserter (where presumably it would be
transformed into some final distribution format, e.g., DVB Subtitles).
Also, you could do something similar for annotating content to be
filtered in the transform step, e.g., ttm:role="x-adult".

 

  _____  

From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
Sent: Tuesday, March 29, 2005 8:41 AM
To: Glenn A. Adams
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Pr ofile (DFXP) Streaming

 

Hi Glenn,

 

I'm not sure I understand your response?

 

In point 1, do you mean AFXP? cf DFXP. Alternatively, how would you
suggest structuring a multi-language DFXP document?

 

w.r.t. point 2, I have perhaps created confusion by referring to a
timedtext stream. I did not intend to imply that the content of that
element was intended for streaming in the internet sense of the
word..... rather I used the term stream as analogous to 'thread'.

 

regards 

John Birch. 

	-----Original Message-----
	From: Glenn A. Adams [mailto:gadams@xfsi.com]
	Sent: 29 March 2005 14:13
	To: Johnb@screen.subtitling.com
	Cc: public-tt@w3.org
	Subject: RE: Timed Text Authoring Format - Distribution Format
Exchange Pr ofile (DFXP) Streaming

	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.