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

What I meant was that if there are references that can disappear (or change
and become invalid) at some unknown time in the future then it will be
necessary for the transmission systems to preload the DFXP file and
encapsulate it in a way that it includes all its references so subsequent
transmissions will not have the opportunity to fail.
 
Russ
 

-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 26 March 2005 05:52
To: Russ Wood
Cc: public-tt@w3.org; Johnb@screen.subtitling.com; shayes@microsoft.com
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming



Russ,

 

I'm not exactly sure what you mean by "a DFXP preload and store operation on
first transmission", but I gather that you are generally supportive of not
having references in DFXP to other resources. Correct?

 

To follow up on your comment about obsolescence of referenced content, it
was indeed an implicit requirement of DFXP that it should be completely
self-contained, just like a video or audio stream or clip.

 

G.

 


  _____  


From: Russ Wood [mailto:russ.wood@softel.co.uk] 
Sent: Monday, March 21, 2005 10:30 AM
To: Glenn A. Adams; Johnb@screen.subtitling.com; shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (DFXP) Streaming

 

BULK OF MESSAGE DELETED see comment RW> below

 

"does not require dereferencing (and subsequent loading) of any resources
other than DFXP content (i.e., no embedded URIs);"

Is this just a timeliness issue?

 

[GA] No. Having to load any other resource may preclude direct streaming
through inline insertion, otherwise, any referenced resources would have to
be inlined and made availabe contemporaneously.

 

 Loading of a resource (referred to for example by a header section) would
presumably just delay the ability to decode subsequent timed fragments. A
stream decoder may then incur a 'one off' setup period where referenced
resources were dereferenced and loaded. Any timed fragment in a streaming
scenario would need to be sent some (short) time in advance of its
activation period(s) on the timebase.

 

 

RW> Another reason why the referencing of non-included resources should be
prevented is the issue of obsolescence.  If a broadcaster purchases a
programme with subtitles, he wants to know that those subtitles will work
today, tomorrow, next year and in a decade.  If a reference is made to a URI
that needs to be fetched then that resource may have moved for reasons
beyond the control of the originator.

 

I would prefer not to have a DFXP preload and store operation on first
transmission.

 

 

Russ

 


________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.


________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.




________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.