TTWG meeting notes 01/30/09

below.  glenn, apologies for butchering your comments in places; please fill in material i missed due to poor connection.

g.


============


Timed-text working group minutes 01/30/2009

Present:
David Kirby (DK, co-chair)
Geoff Freed (GF, scribe)
Brad Botkin (BB)
Glenn Adams (GA)
John Birch (JB)
Andrew Kirkpatrick (AK)

Regrets or absent:
Philippe le Hegaret (PH)
Sean Hayes (SH, co-chair)

=============================
IMPORTANT NOTES:  

1.  GA:  apologies-- poor phone connection so we couldn't hear very well; please fill in missing information. 

2.  BB:  ACTION:  GF and I will create a sample that describes what it is we'd like to do in a QT movie and ask GA to write a DFXP file that does what we want.

3.  GA:  ACTION:  Missing an example of set element in animation, so I will create such an example. 
=============================



Minutes from call:

DK:  Topic of the day:  dynamicFlow.  Geoff, discuss.

GF:  Concerned that broadcasters won't be able to use existing timing on roll-up captions (timed roll-up for pre-produced captions).  Can current timing model do this?  Also concerned that without timing on regions and origin/extent, authors can't move a region without going through animation.  No easy method to move captions or caption region out of the way to avoid blocking on-screen information.

BB:  Was just at a meeting of broadcasters, who were anxious that 608 functionality can easily be reproduced in the process of generating and streaming caption data.  Want to maintain the native or local functions that are required in U.S regulations.  This must be easily accomplished.  608 and 708 functionality is paramount.  Can this be accomplished with DFXP that ensures that players will be able to render data this way?

DK:  Should we be thinking about 608 or 708?  Which is more important to emulate?

BB:  Both are important.  There's a ton of 608 content already available; broadcasters want to repurpose.  608 is carried with 708, so 608 is always available.  608 is very important.  

DK:  So we should concentrate on 608 features initially?

BB:  Yes.  Perhaps create a 608 profile for DFXP to predefine elements that's dead simple for a player to implement for displaying 608 functionality.  Would like to see some sample DFXP files that emulate 608 features.  Broadcasters are writing all their own players, so they need examples like this.  

GF: (explains timed-coded roll-up captions and how they appear on the screen.)

BB: Timing of scrolling rows depends on the timing of the caption file.  Each row of text has a timecode; if there are to be no pauses between rows then each caption row simply contains an in-time and *no* out-time; rows just appear one after the other without pause.  The timing of each row's appearance affects when each row rolls in and out.

GA:  (breaking up, so material is missing...) There's a flow buffer that gets filled with active content.  There's ... The timing for the...

Dynamic text may be able to handle this with minor modifications... Will send more info to list.

(GA disappears into the void)

DK:  Can't we achieve this by overlapping in and out times?

GF:  Perhaps, but that might require more work on broadcasters to convert.

BB:  No one will want to implement this.  Process must be dead simple.

GF:  If captions are timed without out times, then each row of text simply follows one after the other until an out-time erases the display.

DK:  The conversion software could automatically insert out times that match the next row's in-times.

BB:  So then a player would have to discern, based on timing information alone, whether a block of text is roll-up?  Bad idea.  There must be a clear statement that a block of text is roll-up.

GA:  That's more complicated that what we have now.  Also more user-agent... (breaks up)... Must be precise about how timing and implementation models interact.  The current dynamicFlow is a thorough system; anything we would do to replace it would have to be equally precise.

DK:  Not clear that dynamicFlow can support what is required; may be lacking some features.

GA:  It's close; we need to analyze 608 behavior better.

DK:  How many different situations need to be handled?  How many examples of behavior do we need?

GF:  Examples that handle pre-timed material as well as untimed material.

GA:  Need examples that show variable rates over a period of time (fast, slow, fast), one that fast faster than you want to clear; one that fills slower than you want to clear.

BB:  I don't think those exist.  As fast as a row appears at the bottom, the top row disappears.  If you can't keep up with the reading, tough luck.

GA:  There's no enforcement of a minimum display time?

BB:  Correct.  That's why each line has a time stamped onto it.  

GA:  Seems like a simple algorhythm.  Now I understand.  Will investigate a new token called rollUp?

GF:  And that token would spit out text that timestamps already specify?

GA:  Yes, will look into it.

GF:  Summarizes need for timed roll-up support to make it possible for broadcasters to repurpose current 608-captioned material.

GF:  Describes moving text out of the way of lower thirds.

GA:  Can use animation to do this.  Must use predefined set... (GA please fill in here!)

BB:  So there must be corresponding set regions to move regions?

GA:  You can animate almost all the tts properties.  We already support discrete animation.  

BB:  ACTION:  GF and I will create a sample that describes what it is we'd like to do in a QT movie and ask GA to write a DFXP file that does what we want.

GA:  And look at the examples in the spec.

GF:  So that might be satisfied by what we already we have.

GA:  ACTION:  Missing an example of set element in animation, so I will create such an example. 

DK:  What about other 608 display modes?  

BB:  Paint-on mode is the other one.  Not widely used; sometimes at the beginning of a pop-on sequence where there's not time enough to pre-load all the data.  That operates a lot like roll-up.  GF and i will look at examples for this as well (ACTION).

DK:  Are these two modes (pop-on and roll-up; paint-on is a child of roll-up) sufficient to satisfy 608 emulation?  Have we covered everything now from the 608 point of view?

BB:  I think so.

DK:  Going back to the 608-708 point, does 708 require anything else?

GA:  I would argue that 708 is not being used as such.  No native 708-authored  captions yet.  Broadcasters aren't using 708 features yet.

BB:  Caption authors are not authoring native 708, but at data-encode time, encoders are transcoding 608 into native 708 captions.  Real 708 data are appearing on TVs, so firmware can increase and decrease font size/face/colors per 708 spec.  This is under user control.

GA:  But the content isn't using the new features.  The stuff you describe is user-invoked.

BB:  True, but authors will eventually be creating native 708 and using native functions and features.

GA:  For the current version of DFXP, if we support 608 behavior we're probably okay.

BB:  Probably true.

DK:  So what we support for 608 is adequate?  

BB:  Right.

GF:  So we can close the issues around DFXP/708 alignment?

DK:  Maybe.

BB:  Might be affected by delay in switching to digital in US.

DK:  Looking at issues list.  Many of those points (708-related) have already been closed.

AK:  Did we discuss the namespace issue last week?

GA:  No resolution except that the use of styling was erroneous and an implementation error.

AK:  It's just in the document before?

GA:  No, it was not.

AK:  Yes, it was.

GA:  That was not the spec, that was an error made by Thierry who modified the doc but didn't correspond to the spec.

AK:  There isn't a final one yet?

GA:  We do need to finalize the namespace.  By the time we go to PR, that will be the final one.  But do we want to choose one before the next CR?

AK:  Not a significant problem for Adobe so it works with both styling and style namespaces.

GA:  Was a clerical error; never got in the spec.  Can be corrected.  Only noticed recently.

DK:  Is that all for dynamicFLow for now?

GF:  Will upload the notes; GA will review and correct.

GA:  Did you see the corrected version of DFXP I uploaded today?

GF, DK:  Yes.

DK:  Other agenda items can wait until next week.  GA, able to deal with issues 9 and 11?

GA:  Now that I've finished the draft I can deal with this in the next week or two.

DK:  Leave issues tracker for next week.  Any simple resolutions we can make now?


-- meeting ends --

Received on Tuesday, 3 February 2009 11:47:11 UTC