See also: IRC log
<scribe> scribe: nigel
group: Introductions
tmichel: Thierry Michel, staff contact W3C
nigel: Nigel Megitt, BBC, chairing
glenn: Glenn Adams, Skynav, Editor TTML
dakim: Dae Kim, Netflix, observing
atai2: Andreas Tai, IRT
pal: Pierre Lemieux, Movielabs
courtney: Courtney Kennedy, Apple
nigel: Runs through planned agenda; topics and agenda.
pal: I have some comments to raise on TTML2 that I think overlap with the existing topic list
Courtney: I'd like to raise future work in WebVTT specifically Japanese script display
nigel: I propose spending day 1 on TTML2 and day 2 on IMSC 1 and WebVTT and future stuff,
... with some time at the end to revisit any topics that we want to.
group: Happy with that.
nigel: AOB?
group: No AOB
nigel: Actions - there's nothing to discuss here
... Issues - there's no work on open TTML2 issues since the last meeting
glenn: In the TTML2 ED there are Editorial Notes, Issues and "to be defined" things listed.
... I've put them into a spreadsheet and classified them as Editorial (no technical thought needed),
... Technical (requires technical effort) and "X" (needs example materials). There are 105 items
... in the spreadsheet.
... Out of those 105 around 2/3 are Technical, and 1/3 are mostly examples with a few pure editorial things
... This is forming my task list
<glenn> https://dvcs.w3.org/hg/ttml/raw-file/e2c51894b593/ttml2/spec/ednotes.xlsx
nigel: I suggest we go through the TTML2 change topics and call out these spreadsheet changes
... where needed.
... First topic is profiles - especially to support the registry of TTML flavours
glenn: There are some changes here in §5.2, §6 and Appendix D
... There are two issues Issue-351 and Issue-352
issue-351?
<trackbot> issue-351 -- Update IANA registration for TTML2 -- open
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/351
issue-352?
<trackbot> issue-352 -- Add Media Registration Annex -- open
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/352
glenn: The first of those listed is to restore and update the Media Type Registration
... That was Issue-352. The second is Issue-351, which is to define the syntax for processor profiles
... I don't believe there's anything needed for discussion here. I think we've done that.
<glenn> https://www.w3.org/wiki/TTML/CodecsRegistry
glenn: Syntax could be something to discuss
... You can express with this simplified syntax what can also be expressed in the profiles
... mechanism that's in TTML2
... Stepping back a little, I want to check that we have an understanding that this parameter is
... specifying what processor is required in the mind of the author to be able to process this document
... as opposed to making a declaration about the content profile that is followed. Is that a shared understanding?
... The content profile states what features have been used whereas the processor profile can be potentially
... inferred from the content profile, and says 'this is what I need the processor to be able to support'.
tai: They're not the same.
glenn: No, you might say that a processor that is a superset or even a subset is adequate.
tai: From a different perspective, people approached EBU and TTWG with a requirement to distinguish the
... different documents with respect to which specifications the document conforms to, and want a mechanism
... to describe this. I saw this more as a content profile not a list of processor requirements. More to say "this
... document I guarantee conforms to SDP-US, IMSC or whatever"
glenn: That's orthogonal to what the processor needs to support. The only reason I can see for declaring a
... content profile is for validation processing. For non-validating processors it's therefore not relevant. The
... only potential relevance is to infer a processor profile from it. If a document only has a content profile
... declaration but no processor profile declaration then it's possible to infer a maximal processor profile.
nigel: My recollection from the previous discussion is that the main use case is for MPEG-4 signalling of what
... processor is needed, which I think came from David Singer.
tai: Will this also work for TTML1 derivatives too?
glenn: The higher level syntax to allow operators and combinations, but if you ignore that and make it a simple token value
... e.g. "stpp.C", when we discussed this codecs registry what we said is that it would be a mapping from a set
... of small identifiers to their corresponding designators that are externally defined. I had seeded the table
... on the wiki page with the original TTML1 profiles and the SDP-US profile. The identifier in the left column
... was the short value in place of e.g. "C" above it could be "tt1p". Notice I included the version number in the
... short identifiers. So if you want an implementation that at least supports the original TTML1 profile as
... originally defined then you could use the short code in there. What we haven't done yet is to add the new
... TTML2 profiles, which there are 3 of, and we haven't added any industry profiles like EBU-TT-D etc.
... All of these profiles do go back to TTML1 so from that perspective this solution will be valid.
tai: When can this be used?
glenn: The only thing we need to update in the registration is the extra parameter.
tai: What we need to be able to say is when people can use this.
glenn: The syntactic aspect of it is something that has to involve IANA. The values used within it can be
... offloaded to the registry on our wiki.
... It's somewhat complicated by the optional parameter in the original registration of "profile"
... We used the term "document profile" to mean processor profile, which is confusing.
... ttp:profile takes as its argument an xs:anyURI value that can be relative or absolute.
... There are two things that are different in the new proposal. 1) The syntax and 2) to use short codes not URIs
... This allows for shorter labels and a public registry for people to register mappings between identifiers and
... URIs, and therefore to make known publicly specifications of profiles.
tai: So the ttp:profile could be used already?
glenn: Right, and it needs to match the URI syntax of ttp:profile.
tai: To use this existing profile, that's a debate that's been used several times in the past. Do you need a
... complete profile document or...
glenn: It can be prose only.
tai: So we can use this mechanism already?
glenn: That's correct. In TTML1 it may be "any URI that feasibly dereferences a profile definition document."
... That means its potential but not necessarily. Also that document can have no content other than its URI.
... It could be a one line profile that is a formal profile definition document with no child elements that refer
... to any features. All of the definition could be in prose in that document. In that sense it's just a pointer.
tai: This is what people are looking for at the moment. We could use it already for EBU-TT-D?
glenn: You could use that today if you don't want to do combination.
tai: And there's no need to register any designator?
glenn: The only requirement is that it doesn't use the TT namespace as a prefix. Other than that it can be any URI.
nigel: Two other requirements that were raised before are to be able to signal multiple processors that can
... process, and also to use short codes.
tai: It's good to know what we can use now.
glenn: You can signal a forward path using the current profile parameter and moving to the new mechanism.
tai: That sounds good.
glenn: There's already a note in TTML1 that says that processors do not need to be able to dereference the URI.
nigel: Stepping in with a bit of chairing, I'm hearing that there's no technical objection, the editorial requirements
... are clear and that there's a forward path for TTML1 profiles. Is that fair?
group: agrees.
nigel: Let's take a short break.
nigel: Glenn has a couple of entries in the spreadsheet here.
pal: see my email at https://lists.w3.org/Archives/Public/public-tt/2015Jan/0114.html
... basically, what is the relationship between the timings and the media?
glenn: There are lots of issues here! There are lots of potentially different clocks at work.
... Also there may be no related media object.
pal: Okay let's start with that.
nigel: Media timebase?
pal: Let's start with that as the simplest most common example
glenn: Terminology is an issue here obviously.
nigel: I have quite a clear view of what the current spec means, so I'm interested in exactly what questions arise that are maybe not so clear.
tai: I agree that there are questions that keep arising.
pal: So nigel could you draw a diagram showing the relationship between media offset, root temporal extent, etc.?
nigel: I'd rather not because I object to using mediaOffset!
glenn: That's a separate topic.
... We have made some progress in clarifying what we brought in from SMIL. Appendix M is one such attempt,
... but falls short of nailing down everything. What we need to do is to nail down exactly what you asked in
... your question. Recently I've had questions about the computed body duration vs the implicit body duration.
... Does the computed time become the time of the related media object's duration? If there's no related media
... object is the computed time of the body related solely to the timestamps in the document?
... The reason for mediaOffset in my mind was to address the condition where content is authored for
... arbitrary or dynamic differences between the timeline of the related media object. This comes up with SMPTE
... timeBase especially e.g. should people put begin="0" and offset of 10 hours to get to "10:00:00" as a start
... and there's another example with negative times.
tai: What I think would be helpful would be for readers to have this picture.
... Appendix M is a good start but some images might be helpful.
nigel: Draws a picture. Question arises as to the impact/meaning of Root Temporal Extent.
... My interpretation is that the root temporal extent begins at the earliest computed begin time and ends at the
... latest computed end time.
"RTE" is shorthand for Root Temporal Extent. Calculation on left shows computed duration in this example is 4-1=3.
glenn: For media timelines I would begin every root temporal extent at zero [looks at spec] ... but the spec
... has it more like your interpretation nigel.
pal: The next question is what is the implicit duration?
nigel: I generally don't have a usage for this, but there is a specific case where it comes in. Consider a body
... with a dur attribute but no begin and end attribute, and simple, untimed content. The resolved begin time
... is whenever you make the document active and the resolved end time is that resolved begin time + the dur
... attribute.
glenn: Part of the problem is that we also have to deal with an event based model.
<tmichel> SMIL Descriptive terms for times http://www.w3.org/TR/SMIL/smil30.html#smil-timing-Timing-ImplicitDurPar
glenn: What's the difference between implicit duration and active duration?
... TTML 1 says that the implicit duration is indefinite, in §10.4, and that's in TTML2 §12.4.
nigel: For me this is a feature of par timeContainers where the begin and end times of a descendant element
... relate to its parent, and that nesting construct applies both to content elements and to TTML documents
... themselves relative to some external playback.
glenn: Under the SMIL 3 timing and synchronisation module there's a table defining the simple duration
... We don't have repeatDur and repeatCount so in TTML they're always unspecified.
... Then there's an algorithm for computing the active duration which defines some maths, and then
... the "active duration algorithm". I've implemented all this in code.
tmichel: Also there are some descriptions in §5.7 of SMIL 3.
pal: It already helps to know that "implicit duration" has a meaning in SMIL. Maybe it's just a matter of
... condensing in one place in the spec exactly how the TTML attributes apply to the SMIL model.
glenn: We originally based the timing syntax and semantics on SMIL taking into account the SMIL specific way
... to include SMIL in other specifications. We overrode some aspects of it. We didn't want text to have an
... implicit duration of zero for example - we made it indefinite so that untimed text expands out to its
... container's duration. That's what TTML1 §10.4 and TTML2 §12.4 do.
... You have to go back to the SMIL timing model to define the timing model as we intended it. If we were
... to pull it out it would take quite a lot of work, i.e. to remove the dependency on SMIL.
tai: It made it difficult for the EBU group for example to look into SMIL, and it's a generally difficult task to
... read and understand SMIL. I think this is a generally difficult topic to understand. It would make it easier if we
... can allow people to understand the timing model without reading SMIL.
glenn: A similar thing arises with formatting semantics - we did the same thing there where we reused XSL.
pal: If the document says "all the semantics of SMIL apply except where specifically stated" and then we
... highlight SMIL terms and where there's a difference then at least it helps a reader to figure out where to look.
... I share the concern that SMIL is difficult to implement and that timing is central to TTML.
glenn: I can't disagree with any of that - people have been put off by SMIL, which is hard to get your head into.
... We did what you suggested part way, e.g. on the definition of begin, end, dur and timeContainer, where
... we say that the semantics are based on SMIL.
pal: Maybe provide a nice diagram like the one Nigel has drawn to show this.
nigel: I don't mind drawing some pictures here, but they should be non-normative.
glenn: We need to consider what is currently broken, e.g. mediaOffset which I thought was needed. Also a
... reader education effort to explain the model in a more accessible way to understand the complexity without
... having to dive into SMIL. The first is necessary for us to get into the spec right away. The second part
... technically doesn't need to be in the spec but if we can make a straightforward improvement in out time
... frame then let's do that.
pal: It would be useful even to clarify the meaning of Root Temporal Extent in terms of SMIL for example.
glenn: If RTE is the difference between the latest and the earliest resolved time coordinate in the document
... then we can state that.
nigel: I don't think that would cause any difference, for RTE = resolved begin -> resolved end
pal: Is that an action to change the spec?
glenn: I would like to have a few diagrams. You can overdo them - the question is what do you want to
... communicate. Since we've been focusing on media timeBase, at a minimum we probably want to have a
... diagram that shows some of this working in the media timeBase. The diagram may look different for other
... timeBases.
nigel: It does, and I can show how. For smpte you have to look for specific timecode values.
glenn and nigel: some discussion about mapping smpte discontinuous into a continuous mode and mapping
... smpte into media; need to be careful in case smpte is being used so the TTML document survives media edits
glenn: If we think we can translate the other timeBases into media then having diagrams for media time
... gives the most value.
tai: The media timebase view would be helpful.
glenn: We don't need it normatively.
tai: Exactly. Also, it helps readers to understand the context operationally, and why different models might be useful.
... If you can do this trick and connect to daily operation then it will be easier for them to understand.
nigel: I'm happy to take an action to create some diagrams, but I'm not sure what the set of concepts is that
... need to define on that picture.
pal: I'd also like to clarify all the SMIL time references.
... The example you've drawn is incredibly useful because it helps point to a problem with containers, that
... say "start playback 5 seconds into the media" where the media is TTML with no begin and end values.
... There's an unresolvable infinite loop.
nigel: We can solve that with a normative statement I think. It could be to require a begin attribute on something, for example.
pal: That could help for IMSC 1 for example.
Courtney: It might be a nice simplification.
pal: If a document has a body with no time attributes and a p that begins at 10 hours, and the intention is
... to start playback at the beginning of the media then you'd better have a container that says 'start playing
... 10 hours in'.
nigel: Right.
glenn: That's why I wanted a mediaOffset parameter.
nigel: That's a container issue not something that should be in the TTML, IMO.
pal: It would be useful to clarify that in the media timeBase time 0 always corresponds to the beginning of the
... media.
... [draws a typical containment scenario where the media container defines relative offsets between video and TTML]
glenn: In my mind the mediaOffset was metadata to indicate some information in the absence of external
... container information. I would still resolve that example as saying that the document contents begin at
... 10 hours, and the timed text timing model doesn't care about how the synchronisation works.
... If you want to allow negative times and apply some arbitrary time in TTML in addition to the container
... offset then that's another thing.
nigel: I would say that we should not do that. It's actively unhelpful to have this information potentially in two
... places.
pal: The ultimate synchronisation/resolution of the timing is set by the container.
nigel: And that's unavoidable.
pal: Right. It's only when you bring it back in with a container that you can actually combine this stuff.
glenn: So if you had a way to say "in this TTML we think the related media object starts 1 hour in"...
pal: I think that would be ignored.
nigel: You have to think about the encoder/packager.
pal: You could just look at the first time value?
nigel: No, because the intent might deliberately be that the first subtitle begins 5s into the media.
pal: Okay then you do need that.
Courtney: You need this in order to create the container and package it up.
glenn: We could include this as metadata then.
nigel: Yes you could do.
pal: I think that metadata could be useful but you can't normatively apply it because there may be cases where
... after creating the TTML the video is edited or further offset.
nigel: +1
glenn: If you see an arbitrary TTML document and the first resolved begin time is 1 hour in you can't tell if
... that's intentional or not.
nigel: Exactly. It could be the second 1 hour long sample of TTML for a longer thing.
glenn: Yes.
tai: Does this happen in real workflows, that the video is edited or offset?
Courtney: You might have a late delivery scenario where the video sent to the caption author isn't the same
... version as what's played out, exactly.
pal: You can't guarantee that the end point video is exactly the same.
tai: So you have to define in an external context what the offset is.
Courtney: I agree. Whoever is packaging it up has to make those adjustments.
pal: So you might require in a workflow that the relative offset compared to the media originally supplied is
... indicated.
... And then you have the other challenge that the package indication of frame rate might differ from what
... was used when the document was authored, e.g. a 23.98 fps video referred to as 24 fps.
nigel: Right, and we resolved that with metadata in EBU-TT-D to indicate exactly that scenario, so that at least
... there's a heads up for the packager that there could be a problem, because the time expressions don't
... necessarily use frames.
... I've created an issue for this.
issue-381?
<trackbot> issue-381 -- Clarify timing concepts in relation to SMIL -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/381
reopen issue-381
<trackbot> Re-opened issue-381.
nigel: let's break for lunch.
... and we're back...
pal: I like the idea of defining root temporal extent in terms of resolved begin and end times
issue-381: Also define the root temporal extent in terms of resolved begin and end times
<trackbot> Notes added to issue-381 Clarify timing concepts in relation to SMIL.
issue-382?
<trackbot> issue-382 -- Require a computed non-indefinite begin time -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/382
reopen issue-382
<trackbot> Re-opened issue-382.
nigel: For reference, the issues regarding media offset and media begin are issue-361 and issue-270
... There's one more point on timing I wanted to raise before we move off, which is the reference clock
... when timeBase="clock" and clockMode="local".
glenn: It's obvious what the intent was here - it's whatever clock is on the wall. It's the real time in the local time zone.
tai: So if someone sends you a document with local time then you don't know which local time they mean.
pal: What's the use case?
nigel: For example you have a reference clock source that's used to time media playback and you want to
... capture subtitles with times using the same clock source. Your definition of local time is independent,
... and you need some kind of identifier e.g. a PTP server, to be able to connect the recorded media with the
... TTML document.
glenn: That sounds application specific. Are you also saying you want to know the local time offset relative to UTC?
pal: If you know the UTC offset then why can't you just specify times in UTC?
glenn: So to be clear the intent is for playback only not recording time. So the idea is to say here's some timed
... text that doesn't have a related media object, or if it does then the synchronisation is out of scope.
nigel: But you can't detect that intention from any wording in the spec. It looks symmetrical regardless of
... whether times are captured times of recording or of intended times for presentation.
pal: So if something is synchronised locally with a local clock then it will work fine. The second you export the
... TTML document with a local timestamp I have no idea what that means - is it a local time against your watch,
... an atomic clock, or what. If you want to send it to me you need to convert the timestamps to UTC.
glenn: In SMIL the syntax for time expressions includes wallclock sync value. We modelled our local, utc and gps
... timebase on that wallclock value. Local in this case means the same as wallclock in SMIL. We extended it
... by adding UTC and GPS. If you change local to wallclock maybe that's clearer what it means.
nigel: That restates the ambiguity but doesn't resolve it.
glenn: It's easy enough for us to add something normatively about this, to say it's intended to mean the commonly understood wallclock value.
nigel: I don't want to do that though. Would you add a new clockMode e.g. "reference" and some metadata
... to identify the clock source?
glenn: We could do that.
nigel: I don't think we need that though. We could just add an interpretation of local that allows it to be
... parameterised with a reference clock source for example.
glenn: Since we were vague about it I don't see why we shouldn't constrain it to mean what we mean it to mean.
nigel: I'll add an issue to add this then.
tai: We (in EBU) have a need to define a local parameter localTimeOffset. There has been discussion and a use
... case identified for that. Another issue I could imagine is when you have two files relating to the same source
... media that's recorded and you put timeBase="clock" and clockMode="local" and then there's a summer time
... shift part way through the document, how can you translate to media time without knowing the timezone.
... For IRT we don't have that specific scenario but I think there are use cases from broadcasters in Europe that
... would need that extra information. We will define it in EBU, the question is if its useful in TTML more generally.
nigel: I would argue that it is, of course.
tai: We don't have an official request from EBU to add this, but we seem to be the main group member that
... thinks its useful.
pal: So you have two documents created by the same closed system one before a summer time shift the other after.
... When you export those, convert them to UTC! Don't send me a document with local times in.
... As a data point, in digital cinema local times have been a big source of confusion. My advice is just use UTC.
... The timezone adds nothing. It's just an offset relative to UTC, which changes locally in strange ways.
tai: You can still do that if you specify the offset correctly.
pal: My recommendation is just use UTC because then we definitely agree. Otherwise you have to keep track of DST.
nigel: But if you send qualified ISO 8601 times then the offset is clear regardless of DST.
pal: Yes, you can do that but my recommendation is don't even add offsets.
tai: I'm not sure if I agree because if for example you use the xs:date and xs:time schema formats in XML
... which define this kind of information that would be easy and does allow offsets to be included. It's easier
... not to make exceptions.
nigel: But we don't use XML date and time formats in the schema.
glenn: No we didn't define a schema with respect to date and time expressions.
tai: It's the same. If you put local and put this time zone then it would be the same as using UTC.
nigel: I've added issue-383 for this.
issue-383?
<trackbot> issue-383 -- Clarify the application specific usages of clockMode="local" -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/383
reopen issue-383
<trackbot> Re-opened issue-383.
nigel: We have ttp:pixelAspectRatio and ttp:storageAspectRatio as well as the new tts:position attribute.
pal: The reason I brought this up is that IMSC 1 has some language that we should make sure is consistent
... with TTML2, and also because there are lots of TBDs in TTML2. Maybe we're not ready for this yet?
... Last time I looked this wasn't well enough defined in the spec to come up with a conclusive interpretation.
glenn: [goes to the whiteboard]
... In TTML1 we have tts:extent and tts:origin on regions. We have extent also on the root element tt:tt.
... We defined an implicit origin for the root element in the absence of external information. What this didn't
... do very well was to situate the extent of the document inside of a media element since it defaulted the
... root region to the top left without any considerations of aspect ratio or centering at all. In IMSC you define
... some default extent and origin sets to center the root and allow it to be contained within the related media
... object's extent while maintaining a certain aspect ratio.
pal: There's another mode, if you don't specify ittp:aspectRatio, which is to fill the entire region. If you do
... specify it then it fills the root container while preserving the aspect ratio.
... This is defined in IMSC 1 §6.7.1 (in the ED)
... It says preserve the aspect ratio and do it to make the width or height equal to that of the media object.
glenn: In this case the aspect ratio is effectively the display aspect ratio not the storage aspect ratio.
pal: I think that's right.
glenn: In TTML we have the pixel aspect ratio (PAR), and the display aspect ratio DAR is the PAR * SAR where
... the SAR is the storage aspect ratio. So in TTML2 I introduced a number of new features:
... Some extensions to the extent value which can now take "cover" and "contain" which relate to the tts:extent;
... The tts:position attribute;
... The ttp:storageAspectRatio parameter.
... The intention of "contain" is to allow the root container region to be computed so that the display aspect
... ratio is preserved without extending outside of the extent of the media object.
... "cover" also maintains the aspect ratio but does so without any margin, in other words it can compute the
... extent so that the root extent can extend beyond the media object, without necessarily centering. It also
... preserves the display aspect ratio.
... The extent has the same DAR as in the document root container region and completely covers the media object.
... This isn't written in the spec yet - they're proposals from CSS. It may be that we don't need "cover". I
... included it for completeness. These are also useful for background image sizing.
... The second part of this is tts:position. I've defined that in TTML2 then if tts:position and tts:origin are present
... and a processor understands tts:position then tts:position takes precedence over tts:origin. The default
... for position is "center center".
pal: So position is an enumeration?
glenn: It is a complex expression that can have 1 to 4 terms two of which can be linked.
tai: Position relates to the root container region?
glenn: Look at the <position> definition. I defined it a bit more than CSS which is more prose-based.
pal: Can I check what the use cases are for this level of flexibility? Aside from preserving aspect ratio.
glenn: For example this simplifies the definition of regions. Let's say I want a 2 row region that is 1 row from
... the bottom of the screen regardless of the root container region, and I want it 80% of the width of the screen.
... What I can do is say tts:position="center bottom 10%" tts:extent="80% 20%" [draws picture]
pal: So we couldn't just do that with origin 70%?
glenn: It gets problematic when you want an offset but you're using extent="contains" for the root container region.
pal: So in IMSC you could specify origin 70% down and height 20%.
glenn: So that would yield the same percentage.
pal: So if you don't specify an aspect ratio it would still be true regardless of being square or cinemascope.
... Now if I specify an aspect ratio say 4:3 in a 4:3 container it would still work. If I specify 16:9 in a 4:3 container
... then it would end up 10% up still. So I think I can achieve the same already. I'm trying to see what we're
... missing in IMSC 1.
nigel: Can I throw in the definitions of vw and vh?
glenn: A better example would have been not using %age but position="center bottom 10vh" and extent="80vw 20vh"
... because I neglected that percentage is computed in an unusual way in the position construct. It would align
... the 70% point in the container with the 70% point in the box being contained. This makes center=50%.
nigel: There's now a picture of this in the section on tts:position.
https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#style-attribute-position
glenn: You don't have to use the percentage system. You can use pixel or vh values, and they can be negative.
nigel: The percentages can be negative too?
glenn: Yes it looks that way. I just adopted this from CSS to support backgroundImage in the image element
... to have an adequate set of style properties and CSS has an image position property defined in these terms,
... which I thought we could reuse in this context.
nigel: I'm not sure but I think this might make TTML <--> WebVTT mapping easier because I have the
... impression that WebVTT uses the same mechanism. Can anyone confirm?
tai: I was thinking something similar, but it's a very different model from the current one, which may be a problem.
... From the usability perspective, the benefits of this are accompanied by additional complexity because it
... adds a new mechanism for something that is already present.
glenn: The extent and origin model in TTML was good when you knew fixed pixel values and were not
... concerned with maintaining fixed aspect ratios. It began to get difficult when we added auto extent computation
... and the need for positions like "center". So we already had a problem to specify the IMSC 1 behaviour as
... written. It's easy in this model - you just say tts:position="center".
... I've implemented this already and it wasn't complex.
... It was also more convenient authoring-wise rather than pre-computing values.
nigel: You raised the question of if "cover" is needed. I think it may be needed because for non-full screen
... video the user research I've seen suggests that placing the subtitles beneath the video is preferred.
pal: I think you need to make the distinction between the related media object and the viewport.
nigel: That's right.
glenn: I did mean to express whether the viewport is the related media object or the display. I think we need
... a way to define this.
... ttp:storageAspectRatio is a natural follow-on from ttp:pixelAspectRatio.
pal: You have to define 2 out of the 3 to derive the third. I think defining DAR is better because it has more
... applicability and reduces the need for a calculation. This is supposed to be resolution independent.
... What about defining DAR and PAR but not SAR?
glenn: The thing is we defined extent on tt as basically the SAR. It has to be defined in logical pixels with the
... PAR pixel sizes.
nigel: So have we just defined SAR twice?
glenn: We didn't use those words specifically but the extent is the equivalent of the SAR.
... It's true that the goal is to maintain DAR, and I could have picked DAR or SAR.
... We didn't mean SAR to be sample aspect ratio.
... In principle I don't see any reason off hand not to use DAR if that would be less confusing.
pal: My argument is that if we're trying to get to DAR we should just specify it. And also say you can calculate
... storage aspect ratio by dividing DAR by PAR.
glenn: The other thing I need to define for what a pixel means is the coordinate space. There are three that
... I've identified as relevant:
... 1. The document coordinate space;
... 2. The presentation context coordinate space;
... 3. The authoring context coordinate space (which may not be needed).
... From the perspective of presentation the first two are needed. The presentation context coordinate space
... may or may not be the display (glass) pixel coordinate space.
pal: So let's go to 'what is a pixel'. As soon as you define tts:extent in pixels then it's well defined. The
... definition of pixels is only an issue if you don't use tts:extent.
... If you define an extent in pixels e.g. 640x480, then whenever you use the measure pixels in the document
... you can always translate it to a percentage of the root container. We can always render it.
glenn: For TTML1 unfortunately we adopted the XSL definition of pixel, but I don't think anyone took any notice
... of it, and everyone just interpreted it as you said, as a logical definition.
pal: So I think we're trying to solve the case where there's a measure in pixels when tts:extent is not defined.
... I propose that we forbid the use of pixels when tts:extent is not defined.
... Or say if you do it then results are undefined.
glenn: That's one option. I'm not sure if I'm ready to accept it.
tai: I agree that it would be simpler to restrict something than to add something else. In the EBU group we
... spent 2-3 days discussing it and I'm not sure everyone had the same understanding at the end. We brought
... all these terms together.
glenn: Even if you use cover or contain and you have a viewport that you can resolve then eventually all the
... coordinates end up in some space in that viewport.
nigel: The question is do you need to?
pal: The world is heading towards resolution independence.
glenn: When I map TTML into SVG for example, SVG has a notion of a width and height on its root element and
... of its view box which defines a mapping between the extent of its coordinate space onto some other
... coordinate space. For example hxw = 100x100 and view box = 200x300 and it would multiply the coordinates
... by 2 and 3 to get to the same coordinate space. I think we can define something similar in this case so that
... there is a definition of a coordinate but the resolution of that coordinate may depend on some external
... context.
pal: I'm okay to allow it but have a weak definition and a hint or recommendation not to do it.
glenn: I've got a couple of these coordinate space terms.
... The document coordinate space is only really used in extent and position. I haven't folded it in anywhere else.
... There's an issue to define pixels in a concrete way.
nigel: As a devil's advocate straw man why do we not just say DAR is extent * pixelAspectRatio?
pal: So if you specify extent and pixelAspectRatio then you'd better make sure they multiply to DAR.
nigel: So we've created an over-constrained system by adding DAR.
pal: In IMSC 1 tts:extent is not used to compute DAR. It's only used to define what the px measure means.
nigel: We have a much bigger problem - tts:extent is defined in terms of <measure> which has been changed
... and can now have for example the value "available" - I don't know what that would mean here!
glenn: The changes to <measure> were in response to Sean's shrink fitting proposal.
... I pulled them in from CSS.
nigel: What does it mean if tts:extent uses those keywords in <measure> on the root element rather than
... scalar values?
glenn: I was also trying to satisfy the sizing of images.
nigel: It seems as though we need special care for the use of tts:extent on tt:tt, and many of the <measure>
... values don't have a clear meaning.
... Apologies I see that the wording "If tts:extent is specified on the tt element, then the width and height must be expressed in terms of two <length> specifications, and these specifications must be expressed as non-percentage, definite lengths using pixel units."
... is already present.
... I'm struggling to see how we have not therefore already defined display aspect ratio.
glenn: That wording pasted above means that we can't specify "contain" and "cover".
nigel: It seems to me that "contain" and "cover" on tt:tt are orthogonal to the pixel extent.
glenn: They are.
nigel: But we don't have a way to specify both. Maybe the way out here is to allow DAR to be specified if
... extent on tt is "cover" or "contain" but not otherwise.
glenn and pal: discussion re the over-constraint of DAR, SAR and PAR if extent on root is in pixels and DAR is
... specified.
pal: I'd prefer to deprecate PAR and be done with it, but we could mandate the behaviour in the specific case
... where all three are specified and don't agree.
glenn: I'd rather put the wording in to define a single normative interpretation of the over-constrained but
... disagreeing scenario, so it's testable and consistent across implementations.
nigel: Do we have an issue for this?
glenn: The request is reasonable, to add DAR and remove SAR, but we don't have an issue for it.
nigel: Okay let's create an issue.
glenn: We already have issue-201
issue-201: [TTWG meeting 2015-04-09] Agreed to remove ttp:storageAspectRatio, add a display aspect ratio parameter and deal with overconstrained inconsistent extent in pixels on root, DAR and PAR.
<trackbot> Notes added to issue-201 How to specify aspect ratio to understand positioning that may apply for display or video..
glenn: This came about from my interpretation of the SMPTE Digital Cinema requirement for inline space.
pal: Yes, we wanted to be able to specify an inline space, positive or negative.
glenn: So there's already a width and a height property in CSS that are used for the same purpose, but the
... problem with those is their names. They're interpreted in a writing mode relative way, so for vertical
... writing modes width means height and height means width. I wanted to avoid that conundrum because we
... use them in their absolute meanings throughout the document. In XSL-FO there's already the concept of
... the inline progression dimension and the block progression dimension.
pal: So ipd allows a blank space to be defined in the inline direction?
glenn: No, it allows a size to be expressed, e.g. on a span, to define its size regardless of the content that it contains.
Courtney: What does this do if you have vertical text?
glenn: In vertical modes inline means vertical. bpd is the counterpart to that in the opposite axis, e.g. to allow
... a strut to be defined to separate lines by a specified amount.
pal: In TTML extent can only be applied to region...
glenn: Right, if you put extent on a div say then it is shorthand for an inline region.
pal: If you don't specify ipd on a div what's its computed value?
glenn: It's equal to its containing block's ipd minus border and padding if they apply.
pal: So it's a bit like padding for a content region by allowing them to be stretched until they reach that ipd?
glenn: [draws on whiteboard] showing how a div will use all of the width of its parent's content rectangle
... after taking into account the border and padding.
pal: That's all specified in CSS?
glenn: Right, except they use the terms width and height. The height of a div will be the minimum needed to
... hold its content. It will shrink in the block progression dimension to be the minimum needed to hold its
... children. If you specify ipd and bpd explicitly instead of allowing your layout engine to calculate it then
... things change. If for example you specify an ipd that's less than what would normally be present then it would
... be constrained to be narrower than it would normally be (horizontal writing mode). If you make it wider
... then you have an overflow condition - I need to check CSS as it may constrain the maximum allowed width.
... The original reason to have an ipd was to allow spacing to be created without using space characters
... for example by creating a <span tts:ipd="5em"/>.
tai: If you have a background color on all the spans the same...
glenn: then you'd have <span tts:backgroundColor="red">A<span tts:ipd="5em"/>bad<span tts:ipd="5em"/>boy</span>
... for example. The background colour is drawn behind the extent even if it doesn't have any content in it.
... You could have <span tts:ipd="5em" tts:backgroundColor="blue"/>
... That's how they came about. The request was just for ipd but I added bpd for symmetry.
nigel: And last time we discussed this some folk were unhappy with the attribute names.
... I'm not sure if that's still true. How about an alternative like "inlineSize" and "blockSize"?
... The issue with the term 'dimension' is that it's used as a direction in some places in TTML.
glenn: In XSL it's used as a size as distinct from inline progression direction.
<glenn> ACTION: glenn to ensure consistency in TTML2 w.r.t. inline progression dimension vs direction [recorded in http://www.w3.org/2015/04/09-tt-minutes.html#action01]
<trackbot> Created ACTION-384 - Ensure consistency in ttml2 w.r.t. inline progression dimension vs direction [on Glenn Adams - due 2015-04-16].
nigel: Will that resolve it for everyone?
group: no objections to this approach, and keeping the names ipd and bpd.
pal: I've not found a technical defect with this condition structure, but I think it's incredibly complex.
... It forces people to build a parser for the condition language. It's additive and people are already having
... trouble just rendering TTML. I think it adds a lot of complexity for what originally were a small set of use
... cases.
glenn: There's a trade-off between expressiveness and complexity. If you look at e.g. media query, which people
... might quite likely want to conditionalise content based on, it often generates situations where you need
... at least logical expressions AND, OR, NOT etc and pretty soon want to compare parameters to others, like
... is width or height < or > some value, then you've got numerical comparisons as well as logical ones. Then
... soon you want arithmetic too! Just adding conditions that have named parameters and combinatorial logic
... for logical expressions doesn't seem very different to me than adding something that satisfies the more
... general case, and from a parsing perspective it's really straightforward. To write a parser for what is there
... now vs a subset is going to have almost the same complexity. The syntax now will require a lot of test content though.
... I didn't want to reinvent media queries. To implement the expression language I'd estimate as a day's work.
nigel: You may want to conditionalise XML attributes on the tt:tt element but I can't see how you'd do that.
... For example you might want the extent to be dependent on whether the media is being viewed fullscreen
... or not fullscreen.
glenn: There are limits to it. The precedent for this is the switch element in SMIL and SVG.
... What that system did was to limit the locations where switch is permitted, e.g. you can't use it to switch
... between definitions based on conditions. In TTML we have a number of definitional mechanisms like the
... region and style elements. So far I've permitted condition to be used on those, but the only one it can't
... apply to is the tt element itself. Is there any way to express the information on tt in a conditional way?
... I haven't thought about that.
... I did put condition on tt:tt but that may be overly aggressive.
nigel: You'd have to duplicate the whole tree.
glenn: I'm not sure condition is going to work at all on the tt element.
nigel: It's also unclear to me when the evaluation time is for conditions - is it any time during the presentation?
glenn: My intention was to evaluate once before presentation and not again, but I guess implementations could
... offer on-the-go reevaluation. That could be implementation dependent.
nigel: In terms of the spec it's not clear when the evaluation time should be.
glenn: Certainly adding a note that needs to be defined would be prudent.
nigel: You could also take an approach of using XML Query or other syntax and re-use existing techniques
... as a single evaluation before presentation.
glenn: If you're suggesting throwing this out and using XML Query instead I think that would be overkill.
... I think what's in scope of our discussion is 'is there a testable implementable use case' that this meets, rather
... than complexity of implementation. Complexity is a profile issue. Let's say you want a profile that uses
... condition and limits the form of the expressions, such as 'the only permitted functions are bound parameters'
tai: I have recently been wondering if there will ever be a complete TTML implementation.
... You always need something like IMSC to be an implementable thing.
... One proposal for this conditional mechanism: a complete example and use case in the spec would make it
... easier to understand.
glenn: I agree it needs some examples.
nigel: What's the list of use cases we have for this so far: forced display, ...?
glenn: languages
Courtney: I get asked for functionality to present translated subtitles as a licence requirement in some countries, tied to the audio language.
... e.g. if audio language == spanish then you must display subtitles in language XYZ. This is very similar
... to forced subtitles.
tai: I thought of a use case that may or may not work, where you have a complete style set that is in use or
... out of use depending on the condition, to select predefined style sets.
nigel: That could help meet the MAUR requirements
pal: It wouldn't work for regulation.
Courtney: full customisation at the terminal is a requirement for FCC
pal: We don't need to put that functionality into TTML - it's a receiver thing only.
nigel: Maybe it wouldn't work in the US but based on the feedback I see to BBC I think it would really be
... appreciated if broadcasters could offer different style sets, and not outrageous for broadcasters to provide
... them.
tai: In Germany I can see that a useful option might be to put this in the document. We have discussions
... with TV manufacturers too and they don't see it as their business to provide configuration options.
... It's unclear how customisation works now - it has to be done by content provider apps.
Courtney: Whatever layer is doing the rendering is where the options have to be evaluated.
nigel: You could have some content provider provided transformations to allow for some styling.
... There's a problem with any kind of declarative styling which is that to style specific content you need to
... know how it's identified so that you can target (or select) it. Only the document author knows that, because
... it's document dependent.
... That makes customisation always difficult.
Courtney: It could be interesting to investigate whether pre-defined transformations can meet all the user
... requirements for accessibility but there would be lots of work to do on it.
glenn: We have to leave complexity until we've seen the implementations, unless someone can say what
... doesn't work about it.
... Obviously conditionalisation on the tt element is a limiting factor. Can we mitigate that and should we mitigate that?
... If the solution is very complex to specify and hard to understand then that could count against it.
... My main criteria are: is it specifiable, is it usable, is it implementable? Equally important.
... By the way we need to take out stereoLeft and stereoLeft.
<scribe> ACTION: glenn remove stereoLeft and stereoRight from <bound-parameter> [recorded in http://www.w3.org/2015/04/09-tt-minutes.html#action02]
<trackbot> Created ACTION-385 - Remove stereoleft and stereoright from <bound-parameter> [on Glenn Adams - due 2015-04-17].
glenn: Are there any other bound parameters that folk want?
nigel: You could add full-screen and then we can see how that plays out.
... The difference would be that for full-screen you want extent="contain" but if not then "cover" because
... there's more display to use.
glenn: Let me think about that bigger level question there. I've already got a thought process in train for
... how to handle conditionalised parameters. In TTML2 we also allow all the style attributes to be added onto
... the tt:tt element and have them inherited by the region elements. They would maybe also need to be
... conditonal.
nigel: But what's the difference between that and the initial element?
glenn: I guess if you specified initial differently and did not specify them on a region then region would pick
... them up. Yes, maybe its redundant to put them on tt.
<glenn> ACTION: glenn to investigate whether region style inheritance from tt is necessary given the ability to redefine initial values [recorded in http://www.w3.org/2015/04/09-tt-minutes.html#action03]
<trackbot> Created ACTION-386 - Investigate whether region style inheritance from tt is necessary given the ability to redefine initial values [on Glenn Adams - due 2015-04-17].
nigel: We've covered a lot today. Tomorrow we'll use the 'spare' time available to go over the remaining
... TTML2 topics as well as everything else we have planned - let's prioritise based on time available and what
... everyone wants to do.
... We're restarting in the morning at 8:30.
... Thanks everynone! [adjourns meeting]