{minutes} TTWG Meeting 2016-07-07

Thanks all for attending today's TTWG meeting. Minutes in HTML format can be found at https://www.w3.org/2016/07/07-tt-minutes.html


In text format:


   [1]W3C

      [1] http://www.w3.org/


                Timed Text Working Group Teleconference

07 Jul 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/07/07-tt-irc


Attendees

   Present
          Harold, Pierre, Glenn, Nigel, Mike, Thierry

   Regrets
          Frans, Andreas

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This Meeting
         2. [5]TPAC 2016
         3. [6]Profiles Registry and IANA registration
         4. [7]TTML
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This Meeting

   nigel: We have stuff to discuss re TPAC, IANA registration and
   the BBC Safe Crop Area submission.
   ... Any other topics to cover, including AOB?

   glenn: There's a new issue on TTML2 to discuss

   group: No other business to discuss

TPAC 2016

   tmichel: Every year at TPAC we need to fill the form for
   requesting material we need for
   ... the meeting. Every room is equipped with projector and
   power, the question is do
   ... we want more: having a Polycom speakerphone for remote
   joining by Webex,
   ... or a flipchart.

   nigel: I think we normally ask for both. Does anyone on this
   call want to join remotely?

   glenn: Given the possibility of travel issues it's a good idea
   to have it as a contingency.

   tmichel: Ok I'll request both a Polycom speaker and a
   flipchart.
   ... Friendly reminder also: hotel reservations are open so if
   you plan to attend TPAC I
   ... invite you to make your hotel reservation.

   pal: There's one hotel ~300m from the conference centre; the
   next one is significantly further away.

   tmichel: The hotel is not very far from downtown I think.

   nigel: [10]https://www.w3.org/2016/09/TPAC/

   ... Accommodation:
   [11]https://www.w3.org/2016/09/TPAC/Hotels-Transportation.html


     [10] https://www.w3.org/2016/09/TPAC/
     [11] https://www.w3.org/2016/09/TPAC/Hotels-Transportation.html


Profiles Registry and IANA registration

   nigel: I think we're waiting on info about the IANA review
   period prior to making updates to the document.

   mike: We have no comments on the document. I'm not concerned
   about this and it's not

   nigel:
   [12]https://www.w3.org/2002/06/registering-mediatype2014.html

   ...
   [13]http://www.iana.org/assignments/media-types/media-types.xht

   ml

     [12] https://www.w3.org/2002/06/registering-mediatype2014.html

     [13] http://www.iana.org/assignments/media-types/media-types.xhtml


   mike: It's a little concerning that there's no status as it
   suggests that W3C hasn't made the
   ... request to IANA yet. I'll send plh an email asking for a
   further update.

TTML

   action-474?

   <trackbot> action-474 -- Thierry Michel to Publish current
   github errata document for ttml1 to include dropntsc time
   expression semantic -- due 2016-07-07 -- OPEN

   <trackbot>
   [14]http://www.w3.org/AudioVideo/TT/tracker/actions/474


     [14] http://www.w3.org/AudioVideo/TT/tracker/actions/474


   tmichel: I think that's done...

   nigel: This: [15]https://www.w3.org/2013/09/ttml1-errata.html

   doesn't seem to have it.

     [15] https://www.w3.org/2013/09/ttml1-errata.html


   tmichel: I missed that, sorry, I will do that.

   nigel: No other update on any of the actions in Tracker.

   <glenn> [16]https://github.com/w3c/ttml2/issues/165


     [16] https://github.com/w3c/ttml2/issues/165


   glenn: There's this new issue.

   <glenn> [17]https://github.com/w3c/ttml1/issues/213


     [17] https://github.com/w3c/ttml1/issues/213


   glenn: We had previously added an issue to deal with the use of
   offset time expressions
   ... in smpte timebase, which the SMPTE timing semantics in
   TTML1 Annex N.3 did not
   ... treat fully (or at all). Recently Netflix pointed out that
   there's a second type of
   ... expression that's not dealt with, which is the fractional
   seconds component of a
   ... clock time expression, which appears not to be prohibited
   in SMPTE mode, but is not
   ... dealt with in the annex or the formulas for counted frames.
   I need to tweak the
   ... formulas to address the potential presence of fractional
   seconds components.

   pal: In SMPTE mode why would you ever use something other than
   a timecode expression?

   glenn: That's a separate issue - I have no idea why you would
   want to, but the current
   ... syntax does not prohibit it.

   pal: But do we want to permit that or encourage people to do
   that?

   glenn: In the generic TTML language I don't see any reason to
   prohibit it because it is
   ... semantically interpretable in a reasonable fashion. I don't
   have an issue with a profile
   ... excluding it. That might argue that we should define a
   feature in TTML2 that does
   ... not require support for fractional seconds component.

   pal: I'd go further and add a note that you should not do that
   unless we can think of a
   ... use.

   glenn: Semantically I think it's clear what it would mean.

   nigel: I have doubts about what it would mean.

   pal:
   [18]https://www.w3.org/TR/ttml1/#parameter-attribute-timeBase

   §6.2.11 says:
   ... "If the time base is designated as smpte, then a time
   expression denotes a [SMPTE 12M] time coordinate with which the
   content of a Document Instance is to be synchronized."

     [18] https://www.w3.org/TR/ttml1/#parameter-attribute-timeBase


   glenn: If you're using discontinuous markerMode then I would
   completely agree - in that
   ... case it does not have defined semantics. But in continuous
   mode it does have well
   ... defined semantics.

   nigel: What are they?

   glenn: In the formula called countedFrames, the variable called
   seconds would be determined
   ... from the seconds and the fractional seconds component.

   nigel: I think that's strange - the fraction of seconds is
   indicated both by a decimal fraction and frames.

   glenn: I agree that it's strange, but there is a well defined
   interpretation, which is to say
   ... that seconds is a real number as opposed to an integer
   number. It still comes out.

   <tmichel> Nigel; the action 474 was assigned to me during last
   week telecon on june 30th, but I was not attending this
   telecon. that explains why I wasn't aware of it ;-) will look
   into it.

   pal: Regardless whether it is allowed and there's an
   interpretation of it, unless there's a
   ... reason to encourage it I would prefer not to. We should not
   use things in SMPTE timebase
   ... that do not look like SMPTE time expressions.

   glenn: Right now in TTML1 it is permitted, so we cannot say it
   is not being used somewhere.

   pal: My point is not that we can forbid it but that we can
   discourage it through a note.

   glenn: Your comment would also have a reading on offset times
   in SMPTE continuous mode.
   ... Let's say we have a time like 5.4s - that would also have
   to be intepreted according
   ... the countedFrames formula. So we have to take account of
   this in countedFrames in any case.
   ... I view the tweak to cover both of these cases equally.

   pal: But my point is that if someone uses this it seems prone
   to a mistake.

   glenn: I have no problem adding a recommendation that raises
   that point, for example
   ... an informative statement that points out that SMPTE mode
   should be congruent to
   ... SMPTE12M expressions, which do not permit decimal fractions
   of seconds then it is
   ... not advised to use those.

   pal: I think that would be good.

   mike: There's another complication - SMPTE12M has been
   deprecated. Effectively SMPTE
   ... does not have a timecode representation other than the
   binary. It was always intended
   ... to be a marker only. There are all kinds of pitfalls!

   glenn: I should also mention that I recall reading some SMPTE
   specs in the past regarding
   ... timecode where there was a fractional subcomponent of the
   binary timecode. I don't
   ... recall if it was ever used and what it was precisely.

   mike: You could define a mapping to the binary 12-1. I think we
   went too far in
   ... engineering this because it wasn't intended to be anything
   more than a marker.
   ... There is a SMPTE spec that represented one manufacturer's
   way of representing timecode.
   ... You won't get to that specification from any of the
   references in TTML1.

   glenn: Of course we did not reference the binary form and it
   has no direct exposure in
   ... TTML however conceptually there is a mapping certainly in
   discontinuous mode. Whatever
   ... the binary representation is it will have components to
   represent seconds, frames etc.

   mike: There is a reference to 12M in TTML, and the only thing
   in there is the binary representation.

   glenn: I use SMPTE12M as an adjective for the phrase "time
   coordinate". That wasn't
   ... intended to be a binary equivalent for example.

   nigel: It would be reasonable to expect the fractions of
   seconds and frames, if both present, to be alternative rather
   than additives.

   glenn: I would like it to be well defined, even if the
   definition is absurd, and I'd prefer to make it additive.

   pal: In TTML1 all we can do is make a recommendation, but in
   TTML2 we should go further and deprecate it.

   glenn: I would prefer not to make TTML1 documents
   non-compatible with TTML2.

   pal: Deprecating is not obsoleting here.

   glenn: Before I wrote this issue I reviewed the text in TTML1
   §10.3.1
   [19]https://www.w3.org/TR/ttml1/#timing-value-timeExpression

   ... Underneath this in the first paragraph it states "If a
   <timeExpression> is expressed in terms of a clock-time, then
   leading zeroes are used when expressing hours, minutes,
   seconds, and frames less than 10. Minutes are constrained to
   [0…59], while seconds (including any fractional part) are
   constrained to the closed interval [0,60], where the value 60
   applies only to leap seconds."
   ... Originally before I reviewed this text I thought maybe we
   had some prohibition in place
   ... against using fractional components, but when I read this I
   realised that it actually
   ... includes the fractional part.

     [19] https://www.w3.org/TR/ttml1/#timing-value-timeExpression


   mike: I'm leaning towards this being unintentional because 12M
   has no concept of fractional seconds.

   glenn: If we're talking about SMPTE continuous then we're
   bridging the semantics between
   ... 12M and media time. We're postulating a continuous time
   interval that doesn't apply
   ... in the true SMPTE discontinuous mode. We did that to be
   able to interpret durations
   ... and offsets that were not possible in the discontinuous
   mode.

   pal: §6.2.6
   [20]https://www.w3.org/TR/ttml1/#parameter-attribute-markerMode

   note 2 advises: "Due to lack of industry consensus on the
   utility and interpretation of the continuous marker mode,
   authors are advised to avoid its use."
   ... The more we can do to simplify this the better.

     [20] https://www.w3.org/TR/ttml1/#parameter-attribute-markerMode


   glenn: For TTML2 we discussed deprecating it and our conclusion
   was not to deprecate it.

   pal: Do you recall the reason for it?

   glenn: I'd have to look that up.

   pal: there's a note in TTML1 saying we are considering
   deprecating markerMode.

   glenn: After TTML1SE was published we had a further discussion
   here that basically concluded we probably could not deprecate
   it.
   ... And that there were valid reasons for continuing to define
   it so that there is a mapping to media time.
   ... SMPTE timecodes are sometimes used not as labels.

   mike: A clarification: when we're talking about deprecation do
   we mean smpte or markerMode?

   nigel: markerMode.

   glenn: In annex N it turned out to be mathematically useful to
   retain continuous for mapping dropMode to an unambiguous
   timeline.

   mike: But that came about so we could map media times with
   frames to a continuous time.
   ... Hopefully we made it unambiguous and potentially useful but
   that does not mean that anyone is using it.

   harold: As far I've seen we don't have any source document that
   has this issue. We noticed this when we were going through the
   spec.

   pal: My suggestion is to deprecate but not prohibit.

   nigel: I'm considering using SMPTE discontinuous right now for
   live subtitling in EBU-TT, where I need to be able to issue a
   document with a subtitle that begins at a particular time but
   that ends after a duration has elapsed if no other new data has
   arrived to replace it. To permit addition of begin and dur I
   need to use continuous mode.

   glenn: One thing I haven't got around to is mapping
   discontinuous to continuous. I find many use cases where
   continuous is useful.

   mike: SMPTE continuous - in what situation is that used?

   nigel: For me, when there's some knowledge that the timecode
   for media is linear for some period.

   mike: So it's media time with an offset?

   glenn: Yes

   mike: You could just use media time with hh:mm:ss:ff
   expressions.

   glenn: You could certainly convert the labels to continuous
   times but there are complex situations where you have to
   effectively replay the media and run a clock alongside.
   ... Right now we don't have any mapping from labels to
   continuous time values in TTML.

   mike: I don't understand why you want to solve that problem.

   nigel: A use case is to issue a document for a live subtitle
   and have a dur to limit the end point. Then you have to use
   continuous to add the dur to the begin.

   pal: Why not just use media time?

   glenn: [scribe lost ability to recall due to being behind]
   ... Even if we discourage use we still need a well defined
   meaning. There are other
   ... issues we have discussed, and we can spend more time
   discussing SMPTE continuous mode.

   mike: I don't think there was ever any intention for the SMPTE
   timebase to permit both fractional seconds and frames.

   glenn: The history was we started with SMIL 1 time expressions,
   and we introduced frames. It may be that when we did that we
   did not consider the repercussions fully.

   mike: I understand. Or remove it. We need to think about this
   more. In the context of 12M (which we need to update because it
   has been deprecated) there is no concept of a mapping from
   seconds to frames.
   ... We could create one but the point is that if you start with
   12M you would never have fractional seconds.

   nigel: §10.3.1 does not permit fractions and frames together!

   glenn: You're right. Now I have a better solution, for
   clock-time.
   ... Sorry I didn't notice that before.

   nigel: Well that was a fun discussion. Thanks everyone, we're
   out of time. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [21]scribe.perl version
    1.144 ([22]CVS log)
    $Date: 2016/07/07 15:22:01 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

     [22] http://dev.w3.org/cvsweb/2002/scribe/