- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 12 Dec 2019 17:14:08 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <A1B1B8AF-63E2-495A-9057-2E1163425B43@bbc.co.uk>
Thanks all for attending today's TTWG call. Minutes can be found in HTML format at https://www.w3.org/2019/12/12-tt-minutes.html
Apologies from me that the agenda issue was not updated to reflect the summary agenda I sent out on Tuesday until the beginning of the meeting.
Please note that we took the unusual step of making resolutions on 3 issues as noted in the minutes, and made a proposal for a 4th, even though the proponent of the issues was not present. This was not ideal but I decided this was the best thing for making progress purely on the basis that our Decision Policy allows a 10 working day review period. I encourage all members not present on the call to take a look at the minutes and the issues and raise any concerns with those resolutions as soon as is practicable.
Our call on 19th December will be the final meeting of this calendar year: the first one in 2020 will be on Thursday 9th January.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
12 December 2019
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2019/12/05-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/82
[4] https://www.w3.org/2019/12/12-tt-irc
Attendees
Present
Andreas, Cyril, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
* [5]Meeting minutes
1. [6]This meeting
2. [7]IMSC Issues
3. [8]Usage pattern for specifying an image's alternate
text. imsc#490
4. [9]tts:position should be permitted in image profile
imsc#492
5. [10]itts:forcedDisplay should apply to image element
in image profile imsc#493
6. [11]Potential semantic conflict between ttp:profile
and ttp:contentProfiles. imsc#506
7. [12]IMSC requirement query - lineShear
8. [13]AOB: (Re-)join to timed text WG after charter
renewal
9. [14]Use of TTML in ATSC and timestamps
10. [15]Meeting close
* [16]Summary of resolutions
Meeting minutes
Log: [17]https://www.w3.org/2019/12/12-tt-irc
[17] https://www.w3.org/2019/12/12-tt-irc
This meeting
Nigel: Iterates through agenda. IMSC, WebVTT
Gary: No updates today on WebVTT
Nigel: Any other business, or points to get to?
Cyril: Question on IMSC 1.2, possibly a new feature. Can cover
during IMSC or AOB
Nigel: Will cover at end of IMSC part.
group: [no other business]
IMSC Issues
Nigel: Most of the issues we're about to cover were raised by
Glenn but he's not on the call right now.
… I think we should try to cover them anyway and see if there
is a consensus amongst the rest of the group.
… This will hopefully allow us to make some progress.
Usage pattern for specifying an image's alternate text. imsc#490
github: [18]https://github.com/w3c/imsc/issues/490
[18] https://github.com/w3c/imsc/issues/490
Nigel: This has been in IMSC since 1.1 hasn't it?
Pierre: Correct, and it follows the pattern for when
smpte:backgroundImage is used, which is why we ended up here.
… Another data point is we should really refrain from making
changes to image profile unless absolutely necessary.
… Maybe in the future there will be some new requirement for
the image profile that will give us an opportunity to
… correct these things. At this point I don't think it would be
worth the trouble and it would be particularly disruptive.
… I'm happy to close it or deschedule it and defer it to a
backlog so we don't forget about it.
Nigel: That was going to be my suggestion.
Pierre: I propose moving to the backlog.
Nigel: Any other views on this? Any problems saying we may deal
with it one day but not right now?
Pierre: An advantage of doing this is that if someone runs into
this and starts raising an issue they should be able to
… find it in the open issues list fairly quickly, and comment
on it.
Nigel: I'm hearing no objections - obviously Glenn is absent
but he has the opportunity to comment during the review
… period as per our Decision Policy.
Resolution: We will not address this in IMSC 1.2 but leave on
the backlog for potentially fixing in some future version.
tts:position should be permitted in image profile imsc#492
github: [19]https://github.com/w3c/imsc/issues/492
[19] https://github.com/w3c/imsc/issues/492
Pierre: I think this falls into the same bucket as #490. It is
important to note but not worth a substantive change.
Nigel: At this time?
Pierre: Yes.
Nigel: Any other views? The proposal is to not address in IMSC
1.2 but leave on the backlog.
group: [no objections]
Resolution: We will not address this in IMSC 1.2 but leave on
the backlog for potentially fixing in some future version.
itts:forcedDisplay should apply to image element in image profile
imsc#493
github: [20]https://github.com/w3c/imsc/issues/493
[20] https://github.com/w3c/imsc/issues/493
Pierre: This is a direct parallel to #490. forced Display
applies to div and not image.
… This is fine in Image profile because there's a 1:1 mapping
between images and divs, so I suggest the same
… disposition, which is not to address in IMSC 1.2 but leave on
the backlog.
Nigel: I took the step for this one of checking in with Glenn
on the driver for the issue and it seems
… to be one of semantic asymmetry and inconsistency. I take the
view also that this inconsistency is not great
… but is not enough of a motivation in itself to make a change
at this time.
PROPOSAL: We will not address this in IMSC 1.2 but leave on the
backlog for potentially fixing in some future version.
Nigel: Any objections?
group: [no objections]
Resolution: We will not address this in IMSC 1.2 but leave on
the backlog for potentially fixing in some future version.
Potential semantic conflict between ttp:profile and
ttp:contentProfiles. imsc#506
github: [21]https://github.com/w3c/imsc/issues/506
[21] https://github.com/w3c/imsc/issues/506
Pierre: I think this is literally not an issue.
… I think it is not impossible to fulfil the IMSC document at
the top of the issue with an empty document.
… It's a silly document but not impossible.
Cyril: When we have this situation with non-overlapping
profiles, what should a validation processor do?
Pierre: TTML2 is very clear. Theoretically the validator knows
about all the profiles being flagged.
… For instance processor profile is Image and document
conformance is Text. A validator should flag the document
… as non conformant unless it is empty.
Cyril: but how? It will validate against the rules for Image or
for Text and some might fail?
Pierre: The processor profile lists features the processor must
support.
… In the thread there's a specific example.
… The processor profile is Image and the content profile is
Text.
… That means the processor is only required to support those
features supported by Image profile but the document
… must conform to Text profile.
… Let's say the document conforms to Text profile and is not
empty, it contains some spans that are forbidden in Image
Profile.
… A smart validator would recognise that, and see that a
processor has no chance of processing that document
… accurately.
… It should flag it.
Andreas: But the document would still be conformant.
… The validator might warn but from the spec side it is not
forbidden.
Pierre: That's correct.
Nigel: We should separate the two questions of a validator:
… 1. Is the document conformant to its declared content
profile? (in this case, yes)
… 2. Would a processor that meets the requirements of the
effective processor profile as computed from the document
… be able to process it successfully?
… The two questions are distinct.
Pierre: Andreas pointed out that from a validation standpoint
the document would validate correctly because it does
… conform to Text profile. A smart validator might point out
that the processor profile is only a subset and therefore
… it is unlikely that the document would be correctly rendered.
… That's my understanding of profiles in TTML2.
Cyril: It could also say the document is not valid for the
processor profile.
Pierre: In TTML2 the way it is stated is if a feature is in a
processor profile then the processor must support it but
… it does not say that the processor must not support other
features.
… So the best thing a validator could say is a warning that on
the requested type of processor the document might
… not present the document correctly.
Cyril: There's already a recommendation in the spec to use
contentProfiles signalling unless backward compatibility
… with TTML1 is needed.
Pierre: [checks what it says]
… It already says either use Image or Text but not both. The
only reasonable way to do both is an empty document.
… But yes IMSC says contentProfiles _should_ be present.
Cyril: We want to catch as much as possible at validation. I
wonder how we can improve...
Pierre: It's a TTML2 issue that a TTML2 validator should flag
this kind of stuff.
Nigel: We could say that if processor profiles is present and
says one of Image or Text but not both and says
… the opposite of contentProfiles then that should generate a
warning.
Pierre: We designed IMSC to be a superset of profiles like
EBU-TT-D so I don't know how we'd write that.
Nigel: We would have to express it in terms of the computed set
of features supported by the processor and enabled
… by the content profile. The set of features that may be
present in the document should all be in the set of features
… supported by the processor, or generate a warning.
Pierre: That should be in the generic TTML2 validation
processing not in IMSC though.
… Exactly what you suggested Nigel would be a good TTML2
addition. That's useful everywhere really.
Nigel: I can raise that as an issue then.
Pierre: One thing we could do is put that as a proposed
resolution and move the issue into TTML2 instead of opening
… a new issue.
… See if Glenn has a reason why this is not a good idea.
Proposal: Add a normative SHOULD statement to TTML2: The set of
features that may be present in the document should all be in
the set of features supported by the processor, or generate a
warning.
Nigel: I suggest we don't resolve this now but leave it open
for Glenn to respond.
Pierre: That would be my preference.
SUMMARY: proposal listed above to add a normative SHOULD
statement to TTML2, left open for further consideration before
resolving.
Pierre: I'm reading what "validate a document" does and it does
not do that at all at the moment today.
… I don't think this is covered in TTML2 today.
IMSC requirement query - lineShear
Cyril: We don't have lineShear in IMSC 1.1 because it is not
implementable in CSS at the moment.
… Reminder: We have fontShear, lineShear and shear.
… lineShear applies to lines, shear to blocks, fontShear to
glyphs.
… In IMSC 1.1 we only have shear.
… It is a problem for Netflix because we want the lineShear
behaviour.
… The issue is that with multiple lines sheared then the second
or third lines are shifted up or down for vertical lines.
… That is not the desired rendering so we are forced to break a
multi-line paragraph into multiple
… single line paragraphs. That is painful but there are side
effects for ruby position and boutens.
… We rely on the outside value of textEmphasis position.
… With two back to back paragraphs with single lines then it
doesn't behave as expected because
… the position acts on lines within the paragraph not outside.
… It's more of a burden to author.
… My question is how would the group feel about adding
lineShear in IMSC 1.2
Pierre: I think that summary is correct.
… The challenge with adding it to IMSC 1.2 is the same as
existed before.
… Until it is supported by browsers, it's going to be hard to
get enough implementations.
Cyril: I understand that. I would suggest adding it to the WD
and discussing with the CSS WG and maybe put the
… feature at risk and if we can't implement then remove it.
Pierre: We did that in IMSC 1.1 so we can do it again here.
… We have to convince the browser people. They don't support
shear at all.
Cyril: Yes, you can do it with transforms.
Pierre: Yes, the problem is doing transform per line because
you can't tell what a line is, then you have to wrap
… a line into a display:block etc. A polyfill is a lot of work
but probably possible.
Cyril: I'm reopening it. I'm not hearing any objection.
Pierre: That's a good idea, and I don't have a strong objection
to putting it in as at risk just like with IMSC 1.1.
Nigel: Does the new CSS writing modes Rec say anything about
this?
Cyril: No, nothing to do with shear.
Pierre: Some folk from the CSS WG and JLReq group from the
print industry don't think shear should ever be used, so
… we have to overcome that I think.
… [apologies I have to drop off in a moment]
… I don't object to raising this with the browser community.
… There are errata to cover at some point; we can do that next
time?
Nigel: Sure.
Pierre: To go over the errata next meeting.
Nigel: Anything more on this topic?
AOB: (Re-)join to timed text WG after charter renewal
Nigel: Atsushi sent an email around. Quick poll: has anyone had
any issues rejoining?
Cyril: No but I'm confused. I asked my AC rep to join Netflix
again, and that happened. Do I have to do something
… individually.
Nigel: It's hard to tell. I had the same issue. Atsushi was
able to check for me.
Cyril: I'll send him an email.
Nigel: Any other queries about this?
group: [no other queries]
Use of TTML in ATSC and timestamps
Cyril: I've had discussions with multiple people that in ATSC
with DASH it is not very clear how,
… in TTML in MP4 files, what the time values inside the TTML
documents should be.
… Should they be relative to the ISOBMFF file in which they're
carried, or the DASH period or something else?
… It seems that some people have been using UTC timestamps. I
wanted to know the group's opinion.
Nigel: I've looked at this in some detail.
… I think Cyril, you, me and Romain published something a few
years ago!
… BBC does publish DASH MPDs where the track timeline begins on
1 Jan 1970.
… The TTML times within any single sample ISO BMFF need to fall
into that sample's period on the timeline
… otherwise the content won't be presented by a client - it
will be temporally clipped.
… This is clear.
… Then it is a separate decision for e.g. ATSC if they think it
is useful to specify some common track timeline across
… all services. They can do that but from a client perspective
if all they are doing is receiving a DASH MPD and playing
… the content then it doesn't matter what that timeline is, as
long as the TTML payload content has appropriate times
… within it.
[22]TTML in MP4 and MPEG-DASH guidelines
[22] https://github.com/rbouqueau/TTML_in_MP4_DASH_statement
Cyril: Ok, thank you - it would be worth reminding ATSC about
this I think.
Meeting close
Nigel: Thanks everyone, we've completed our agenda for today.
Next week's meeting will be the final call of 2019.
… [adjourns meeting]
Summary of resolutions
1. [23]We will not address this in IMSC 1.2 but leave on the
backlog for potentially fixing in some future version.
2. [24]We will not address this in IMSC 1.2 but leave on the
backlog for potentially fixing in some future version.
3. [25]We will not address this in IMSC 1.2 but leave on the
backlog for potentially fixing in some future version.
Minutes manually created (not a transcript), formatted by
[26]scribe.perl version 104 (Sat Dec 7 01:59:30 2019 UTC).
[26] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 12 December 2019 17:14:15 UTC