notes from sept. 19 telecon

TTWG minutes Sept 19, 2008

Attending: Geoff Freed, WGBH (GF, scribe)
David Kirby, BBC (DK)
Sean Hayes, MSFT (SH)
Glenn Adams, Samsung (GA)
Philippe le Hegaret, W3C (PlH)

Regrets:
Kees Blom/CWI


Review of agenda

NOTE:  Telecon passcode will always be 3397!

Review of action items -- membership:  PlH will contact adobe and EBU
for membership in TTWG
GF:  WGBH has rejoined TTWG
DK:  In contact with Franz at EBU; Franz will check with EBU re  
joining as invited expert.
PLH:  Contacted John Birch; waiting for PlH to invite as expert
SH: Apple will not be part of TTWG, probably due to change in IP
rules.
DK:  What about Mike Dolan?  Mike says the telecon time is not  
convenient.  Does he need to be reinvited?
PlH:  He does need to be invited.
SH:  Ask PlH to contact MD and invite
ACTION:  PlH will contact Mike Dolan to invite to TTWG
SH:  What about Google, Yahoo! and AOL?
PlH:  Not sure but will contact Google next week when in San Jose.   
Yahoo! is a problem because of patent policy.  Very pessimistic about  
them joining the group.
SH: And AOL?
PlH:  Already members.
SH:  Will contact Tom Wlodkowski to see if AOL can sponsor someone to  
join.
ACTION:  Sean will contact Tom Wlodkowski about joining TTWG.
SH:  Anyone else that needs to rejoin the TTWG?  MSFT is in the  
process of rejoining, will follow up today to move things along.
PlH:  We have a member from AOL but needs to rejoin.
SH:  Someone needs to ping AOL
DK:  CWI will join TTWG later.
SH:  What about george kerscher/DAISY?  Masahiko Kaneko (MSFT) has  
moved on to other things
SH:  Progress on test suite?
GA:  No progress on test suite yet, but sent spreadsheet to list re  
XFSI implementations.
GA:  Will take care of moving test suite.  Wants to move current DFXP  
draft and test suite to CVS at W3C.  Will start soon.
SH:  Discuss GA's spreadsheet.  This is a reasonable structure to  
which we can add other implementations.  We need two implementations  
of each feature.
GA:  PlH and GA say to use the DFXP table of contents as level of  
granularity right now to start tracking implementations.
DK:  Does that go deep enough?  DK's spreadsheet ended up with 950  
options, more than GA's.  Time can be expressed in multiple manners,  
for example.  Adobe's implementation is more restrictive.  Would that  
be shown?
GA:  Yes, even though spreadsheet is reasonably coarse-grained.  A  
list that is too fine will be difficult to meet the two- 
implementation requirement.
SH:  Then we should begin with coarse-grained approach, then add  
extra sections as necessary.  No objections?
DK:  Okay, but will expect to add sections later.
SH:  Fine.
SH:  Will use Glenn's spreadsheet as a starting point for  
implementations.
SH:  DK will put headings in for all other known implementations?
DK:  Okay.
SH:  Then get implementors to fill in their part of the spreadsheet,  
otherwise we'll have to do it.  Create a line for implementation  
name, then contact info for owner of implementation.
DK:  If the implementation isn't available for testing, don't waste  
time.
SH:  Fine, then delete from spreadsheet.
GA:  What's available?  No requirement that we must obtain these  
implementations and test ourselves.  Owners are usually taken at  
their word, we need not verify.
SH:  True.  Would hope that they would give accurate info.  Only a  
problem if we don't have two obvious implementations; then we'd have  
to chase that down.
PlH:  Assume that we have to run this test suite.  Later we'll have  
to verify, no?
SH:  Don't we just provide the suite and implementors do the testing?
GA:  There are no requirement to perform test.
PlH:  Yes, there are.
GA:  Not the case in the past with other groups.
PlH:  Correct, but must rely on implementors to use the test suite  
and tell us if they pass or fail.
GA:  Absolutely they must.
SH:  Not sure that we must require implementors to return results to  
TTWG.
PlH:  Yes they must so PlH can show results to director.
GA:  Not true.  We must rely on implementors to give accurate results.
PlH:  Must be able to show results to directors and report whether  
tests were passed or not, so implementors must run each test and  
return results to us.
GA:  Fine.
PlH:  Did not mean that TTWG must test each implementation.
DK:  Should we add a column showing which files in the test suite  
exercise each feature?
PlH:  Would be useful.
SH:  Should be on a separate sheet.
PlH:  Yes.
SH:  Must wait until we have the test suite is available.
GA:  Will alter spreadsheet to reflect either test the feature or  
exercise the feature.
PlH:  ACTION:  once test suite is in, will alter sheet to reflect above.
SH:  This will also show us where we need new tests.
GA:  Have used comments column to describe elements or features that  
were tested.
GF:  When should we contact the implementors?
GA:  When table is ready.  In the meantime, TTWG members can begin  
testing themselves.
SH:  Fine.

SH:  Next item:  Geoff and concerns about dynamicFlow and real-time  
captions/subtitles
GF:  (pasted from TTWG list): One of my concerns about the current
dynamicFlow in DFXP is that it cannot emulate an important feature of  
EIA-608
captions, which is the ability to create and change regions on the fly.
Currently, dynamicFlow can feed text into pre-created regions in pre- 
specified
locations.
In a real-time-captioning situation, region locations may not be  
known ahead of
time, and during a broadcast blocks of caption text sometimes have to  
be moved
from, say, the lower-third of the picture to the upper-third to avoid  
covering
important graphics, or sometimes they are just moved up (or down) one  
or two
rows.  As far as I know, DFXP does not allow to on-the-fly creation  
of new
regions, does it?  If not, then the current dynamicFlow isn't really  
suited for
live captioning or subtitling, and this is something that I'd like to  
improve,
it if is possible within the bounds of the charter.

GA:  dynamicFlow currently inhales text into a region.  Can use  
animation to move regions around.  Could have a stock set of regions  
and use animation to move items into regions.
GF:  Would involve predefining regions?
GA:  Could have default regions that are turned off and then use  
animation to position and turn them on.
SH:  But display doesn't apply to regions.
GA:  But visibility does, and can have the same effect.
SH:  Doesn't 608 have finite number of areas for display?
GF:  Yes, can use the 15 rows per screen.
SH:  Would we need more than that?
GF: No, probably not but what about predefining regions?  Is  
problematic.
GA:  Can just define regions and keep them invisible and turn them on  
as required.
SH:  True, but would have to define from the start (header).  Would  
have to know what set to put into the region from the start.
GF: What about adding regions in-line??
SH:  Would be difficult
GA:  608 and 708 doesn't create regions, just reuses regions.
SH:  Creating regions up front isn't a problem, but what is is not  
being able to stream that?
DK:  Why need animations?  Why not define regions up front?
SH:  Animation would make them visible.
DK:  Can't just turn on background?  The region is always active if  
default is set to transparent?
SH:  Can't we use showBackground?
GA:  Could do that, but would need animation to change background.
DK:  Could clear text in region 1 and then start writing text to  
region two.
GF:  What about streaming?
GA:  Probably not because we haven't defined streaming for DFXP.
SH:  Model is you send the file and the client interprets that.  We  
haven't really addressed streaming.
GA:  Would have to make that a later implementation.
GF:  Not part of current charter?
SH:  Streaming of XML in general is not well defined.
GA:  Had hoped that XML group would address streaming, but they did  
not deal with this yet.
PlH:  Not part of their requirements, probably.  Are in last call or  
going there soon.  Maybe we want to say something to them about  
streaming XML.
PlH:  Will send around the link to the LC document. See IRC log.
GF:  So real-time DFXP not possible right now?
SH:  If we implement current annex:  predefine regions, then select  
which regions you want to use.  XML streaming is still a problem,  
however.  Doubts if straight streamed DFXP is possible; will need  
transformation.
GF:  Not smooth implementation, though.
GA:  Can represent info but is not necessarily transportable, or  
would allow expression of that data for distribution and exchange.   
Would need to transform DFXP to make it streamable.  XML is not a  
streamable format; DFXP is XML.  Some transformation must occur.  How  
does that transformation get standardized?  Could define a  
transformation to 608/708, but does that allow expression of this  
data set in target format?
GF:  Can't solve this problem in one year; hands are tied by XML non- 
streaming?
SH:  Our job is to finish DFXP and not change much.
SH:  Out of time; carry remaining agenda items to next week.
DK:  May not be joining next week
SH:  May not be there either.  PlH won't be there.  Next meeting on  
10/3?
DK:  M Mike Dolan can't join at 9:00 on Fridays.  Will have to see  
about fitting him in.
SH:  When does glenn go back to Asia?
GA:  Back by 10/3 meeting.
SH:  May need to change meeting time later.  However, the next  
meeting is October 3 at 9:00 Eastern time.

Adjourn.

Received on Friday, 19 September 2008 15:56:08 UTC