16:01:31 <RRSAgent> RRSAgent has joined #tt
16:01:35 <RRSAgent> logging to https://www.w3.org/2023/11/09-tt-irc
16:01:35 <Zakim> RRSAgent, make logs Public
16:01:36 <Zakim> Meeting: Timed Text Working Group Teleconference
16:01:54 <nigel> Agenda: https://github.com/w3c/ttwg/issues/268
16:02:05 <nigel> Previous meeting: https://www.w3.org/2023/10/12-tt-minutes.html
16:02:14 <nigel> scribe: nigel
16:02:14 <nigel> Chair: Nigel
16:02:23 <nigel> Regrets: Andreas, Atsushi, Gary
16:02:51 <pal> pal has joined #tt
16:03:02 <nigel> Topic: This meeting
16:03:27 <nigel> Present: Chris, Cyril, Matt, Nigel, Pierre
16:03:37 <cpn> cpn has joined #tt
16:04:22 <nigel> Nigel: Today, we have IMSC-HRM, DAPT and an AOB about 5G-MAG OSMART workshop
16:04:38 <nigel> .. Is there any other business, or points for us to make sure we cover within those topics?
16:04:52 <nigel> Present+ Mike
16:05:06 <nigel> group: no AOB
16:05:22 <cpn> scribe+ cpn
16:05:30 <mike_> mike_ has joined #tt
16:05:37 <nigel> Topic: IMSC-HRM
16:06:11 <cpn> Nigel: I think we set a timeline, where we'd be looking to transition to the next maturity stage about now
16:06:27 <cpn> ... which would be PR, so we'd need to meet CR exit criteria
16:06:50 <cpn> ... That requires evidence of implementation, either a validating or an authoring implementation (as demonstrated by content)
16:07:22 <cpn> ... I've had three organisations contact me that they'd run content through HRM with good results
16:07:37 <cpn> Pierre: One was 25,000 documents
16:08:34 <cpn> Nigel: If your validating implementation passes the tests, Pierre, we can demonstrate everything we need for CR exit?
16:08:49 <cpn> Pierre: I'm confident that we've demonstrated implementation experience
16:09:17 <cpn> Mike: At ATSC, we ran both positive and negative content, and it flagged every document
16:09:44 <cpn> Nigel: That shows the HRM conceptually is useful
16:10:06 <cpn> ... and also the effectiveness of the tool used to check it
16:10:21 <cpn> ... If we can say those files were generated with a different implementation from the ones that passed,
16:10:40 <cpn> ... we can say we have evidence with multiple pots of content, and the authoring application meets the requirements of HRM
16:10:56 <cpn> ... But if they're all produced by the same tool, it doesn't demonstrate effectiveness of HRM
16:11:11 <cpn> Mike: We used two encoders, hundreds of documents
16:11:44 <cpn> Nigel: So to demonstrate success, although the ones that failed demonstrate utility of HRM, we only want the ones that passed to demonstrate success
16:12:07 <cpn> Pierre: We want the ones we know pass to pass, and the ones that should fail, fail
16:12:20 <cpn> Mike: If everything passes, you don't really know anything
16:12:33 <cpn> Cyril: Discussed with Pierre last week, related to failures
16:12:59 <cpn> ... I ran 3000 Netflix content through, and none failed. More recently testing live content, a naive implementation of 608 conversion
16:13:27 <cpn> ... It failed. The reason, if you naively convert 608 to TTML, you can have two characters change every 33 ms, it was failing the HRM
16:13:43 <cpn> Mike: As it should. We had similar experience, the encoder was doing 608 conversion, badly
16:14:08 <cpn> Cyril: But why should it fail? If an implementation of 608 can refresh every 33 ms, why shouldn't a TTML implementation do the same?
16:14:25 <cpn> ... It means the HRM as configured today has some known limitations, but is that ok?
16:14:35 <cpn> ... I'm not convinced it's not too strict
16:14:50 <cpn> ... Our implementation of naive conversion, it plays fine in the Netflix players
16:15:20 <cpn> Mike: I have a different view. Where content was flagged as failiing, it was creating and tearing down content in a single document roughly every 20-30ms
16:15:41 <cpn> ... Decoders weren't built to do that. I think it's an unreasonable thing to expect implementations to handle
16:15:53 <nigel> q+
16:15:55 <cpn> ... If we want redesign HRM to handle those things, OK
16:15:57 <nigel> qq+ pal
16:16:07 <cpn> ... I'd be concerned about relaxing that, as there are TVs that can't display it
16:16:39 <cpn> Cyril: Not saying we should relax it. It's based on parameters, we chose one set. It doesn't necessarily mean the document can't be rendered, just on those parameters
16:17:19 <cpn> Pierre: TTML isn't 608, different data model, rendering model. 608 is a state machine
16:17:47 <cpn> ... The client is a state machine with a cursor, send commands to make the cursor do things. You have multiple channels you can go between ambiguously
16:17:59 <nigel> ack pal
16:17:59 <Zakim> pal, you wanted to react to a previous speaker
16:18:04 <cpn> ... TTML is a document with semantics, line breaks, regions. The two models are entirely different
16:18:32 <cpn> ... The idea of converting 608 to TTML and expecting the same thing, is nonsensical
16:19:14 <cpn> ... I think that was recognised early on. Regardless of performance, trying to convert 608 verbatim to a TTML document, there's no expectation you'd get exaclty what the 608 was
16:19:39 <cpn> Mike: I agree with that
16:19:44 <nigel> q+ mike
16:20:32 <cpn> Pierre: The second point is, at the time there was significant limitation in terminals
16:20:53 <cpn> ... Nothing close to Android on TVs. The model was created so all reasonable TVs would have a shot at rendering TTML
16:21:11 <cpn> ... No expectation that a TV could render 30 or 60 TTML documents a second, which is the rate 608 transmits data
16:21:46 <nigel> ack nigel
16:21:54 <cpn> ... In general, I'm not suprised it would fail on naive translation of 608 content
16:22:03 <cpn> Nigel: Don't disagree with any of the above
16:22:30 <cpn> ... 608 appends 2 characters per time period, should be something a modern renderer should easily achieve
16:22:44 <cpn> ... I think that mischaracterises the problem and the solution space. A couple of extra things need to happen
16:23:06 <cpn> ... With TTML you have to do layout again, you can't just append 2 characers at a know grid location, so additional processing to do
16:23:29 <cpn> ... Secondly, the 608 and similar models from that era are based on a stateful decoder, where they append to what's already there
16:23:43 <cpn> ... Intent of how we deliver TTML is the receiver shouldn't have to maintain state
16:24:20 <nigel> q?
16:24:27 <nigel> q+ cyril
16:24:31 <nigel> ack mike
16:25:00 <cpn> Mike: There's not a fundamental problem converting 608 to IMSC1 and fully meeting the HRM. I checked 3 encoding manufacturers, everything worked great
16:25:26 <cpn> ... One particular manufacturer, on one document. They reconstructed the screen 30x per second by adding 2 characters
16:26:09 <nigel> q+ to come back to CR exit, when this discussion is done
16:26:17 <cpn> ... Caused the TV render the whole thing again. It was horrible, so should die though HRM violation
16:26:22 <nigel> ack cyril
16:26:45 <cpn> Cyril: Don't disagree it's a bad idea to convert 608 to TTML where you refresh only 2 characters
16:27:40 <cpn> ... The one thing I think we should be careful about, if we'd defined a simple TTML profile to match 608, it would work
16:28:14 <cpn> ... The other features are there, make it more complex for the implemntation. That's how we should explain it, people currently do 608 conversion
16:28:20 <cpn> ... Not good for us to say that that's nonsense
16:29:08 <cpn> Mike: I agree, perhaps the HRM should have a number of dials. An expectation of complexity, rather than the W3C TTML group deciding what complex means for all time
16:29:16 <cpn> ... TVs are getting better at handling this stuff
16:29:26 <cpn> ... What should be prohibited today may be fine in a few years
16:29:47 <cpn> ... The concept of a profile, or adjusting the complexity, depending on the application is a good idea
16:29:54 <cpn> ... Need to put a stake in the ground today
16:30:19 <pal> q+
16:30:36 <cpn> ... Going forward, maybe we need to think of future HRM having dials for no. of characters per section, no. of changes, to serve needs multiple of applications
16:30:47 <cpn> .. It's good for today's technology, but make it smarter for the future
16:30:55 <nigel> ack pal
16:31:32 <cpn> Pierre: I think naive translation of 608 in TTML is a bad idea, you get TTML documents that aren't portable and you can't match the TTML feature set
16:31:49 <cpn> ... If the goal is to allow a straight translation from 608, we're far from that
16:32:10 <cpn> ... Assuming that's not the goal, does the current HRM prevent creation of captions that meet the needs of end users?
16:32:21 <cpn> ... If the answer is no, we don't need additional controls
16:32:34 <cpn> ... Goal is a caption experience required by end users
16:33:56 <cpn> Cyril: I'm not suggesting changing the HRM. We could add a note to say that the TTML and IMSC specs allow more complex features than previous technologies, so the parameters we've chosen don't allow for characters to change in every video frame
16:34:03 <cpn> ... Useful to have that in the spec
16:35:24 <cpn> Mike: I have 25 year old MPEG TS that exercises every 608 feature, 2 of 3 encoders get it right
16:35:42 <cpn> Cyril: But they don't refresh the screen every frame
16:36:49 <cpn> Mike: I'm ok with the principle, we need to agree what the HRM checks for at a high level, but need to be careful about 608, it can be done
16:36:54 <nigel> ack ni
16:36:54 <Zakim> nigel, you wanted to come back to CR exit, when this discussion is done
16:37:27 <cpn> Nigel: Add an issue to add an informative note on potential causes of HRM failure
16:37:43 <cpn> ... So pause CR exit until we've agreed wording
16:38:01 <cpn> ... We do need to be careful about the language and the reflection on the industry
16:38:25 <cpn> ... Aside from that, I think we have enough information to claim we've met CR exit criteria, so we need to write an implementation report
16:38:33 <cpn> ... An action for somebody
16:38:56 <cpn> Pierre: I'm happy to write the report, from the wiki page
16:39:39 <cpn> Nigel: Need to be careful about people who described implementations
16:40:18 <nigel> .. I'll take point on checking in with them to see if they're happy to be publicly named.
16:40:29 <nigel> Topic: DAPT
16:40:37 <cpn> Nigel: A few things on DAPT
16:41:13 <cpn> ... Horizontal review requests. APA has taken an action to do the review, hope to have response from them soon
16:41:31 <cpn> ... TAG has gone quiet, and no feedback on security
16:41:36 <cpn> ... I'll take an action to follow those up
16:41:59 <cpn> ... We sent liaisons, and some haven't responded yet. We'll proceed regardless, for the time being
16:43:00 <nigel> Subtopic:  Rework audio description original and translation languages w3c/dapt#179
16:43:07 <nigel> github: https://github.com/w3c/dapt/pull/179
16:43:28 <cpn> Nigel: This has gone through some iterations. Andreas has been actively reviewing
16:44:03 <cpn> ... The point to deal with is flagging in the best way the difference between content described that had an inherent language, and content that didn't
16:44:11 <cpn> ... I added a table in the issue with permutations
16:44:54 <cpn> ... It's clear if you're transcribing dialog or signing
16:45:17 <cpn> ... For content in the video image, it might be text or might not be. If text, can use lang source
16:45:38 <cpn> ... If it's a description of the image, or a sound effect, those things don't have a language
16:46:02 <cpn> ... The proposal is for any content with a language, use lang source to record it, and the language of the text transcripted in xml lang
16:46:19 <cpn> ... And omit lang source if there isn't a language
16:46:37 <cpn> ... Also the concept of original language doesn't serve a purpose any more, and could be removed
16:47:11 <cpn> Cyril: On the proposal to be clear on when lang source is present or not, that's fine
16:47:21 <cpn> ... Disagree that we don't need the original language
16:47:46 <cpn> ... It's to provide context on what the language was. When you're dubbing a show with multiple languages in the original source
16:48:10 <cpn> ... or a show translated to a pivot language to create a dubbing, knowing the orignal language can be useful
16:49:04 <cpn> Nigel: That's a change of status of the flag. There are normative statements around original lang to change: make it a list
16:49:25 <cpn> ... if someone creates a silent video with no dialog, then it's audio described, what use is orignal lang?
16:49:43 <cpn> Cyril: Doesn't have to be mandatory. The concept of original language should be preserved in the spec
16:49:59 <cpn> ... or original languages
16:50:29 <cpn> ... If the original languages are French and English, you can translate to English only, French only, or German
16:50:54 <cpn> ... If translation to German, you translate everything, but if translating to French you only translate the English parts
16:51:11 <cpn> ... It's complex, I need to continue to review. Seems going in the right direction
16:51:53 <cpn> Mike: I try to get people to conform to BCP47. If you constrain to that, it's good. Use the IANA codes
16:51:57 <cpn> Nigel: We do, yes
16:52:49 <cpn> Nigel: To summarise, the proposal seems OK. Original language still has a use, but we can relax some of its requirements: make it non-mandatory and allow multiple values, if that's the best reprsentation of the cotent
16:52:57 <cpn> s/cotent/content/
16:53:22 <nigel> SUMMARY: the proposal seems OK. Original Language still has a use, but we can relax some of its requirements: make it non-mandatory and allow multiple values, if that's the best representation of the content
16:53:46 <nigel> Subtopic:  Add inline Registry Section w3c/dapt#196
16:53:53 <nigel> github: https://github.com/w3c/dapt/pull/196
16:54:12 <cpn> Nigel: Thank you Cyril for reviewing. Please take a look
16:54:46 <cpn> ... We wanted registry tables in a few places, so this uses new features in W3C Process. They can be updated outside the normal Rec track process
16:55:10 <cpn> ... I've based this on the boilerplate text in the TTWG repo
16:55:47 <cpn> ... In doing this, I've had to raise a Process issue, but it's probably acceptable now to meet process requirements
16:55:55 <cpn> ... Please look, to see if it has any issues
16:56:11 <nigel> SUMMARY: Please review!
16:56:25 <nigel> Topic: AOB: 5G-MAG OSMART workshop
16:56:51 <nigel> Chris: I'll paste a link into IRC.
16:57:25 <nigel> -> https://lists.w3.org/Archives/Member/member-tt/2023Nov/0000.html Invitation on TTWG member list
16:57:38 <nigel> Chris: This came to me from Thomas Stockhammer, who I assume is part of the organising
16:57:54 <nigel> .. group for this conference. It's 5G-MAG with DVB and has been extended to other organisations
16:58:10 <nigel> .. like DASH-IF, CTA-WAVE, ATSC, 35PP, W3C and others.
16:58:20 <nigel> .. Open invitation to share in the workshop anything about reference tools that have been
16:58:26 <nigel> .. developed to support specifications.
16:58:34 <nigel> .. Intent is to foster collaboration between standards groups.
16:58:53 <nigel> .. I thought of two areas of interest: IMSC-HRM and its tooling, and the imscJS implementation,
16:59:03 <nigel> .. and some other things like in MediaWG sample code for WebCodecs,
16:59:08 <nigel> .. or similar for WebTransport WG.
16:59:18 <nigel> .. Thomas latched onto the IMSC and TTML parts more so than the others.
16:59:37 <nigel> .. If you would like to present on the tooling that you've developed around IMSC and TTML, and the HRM,
16:59:46 <nigel> .. this is an opportunity to present at that workshop.
16:59:59 <nigel> .. What I'd like to do is to go back to either confirm or politely decline depending on what you prefer to do.
17:01:19 <cpn> Nigel: It looks to me like it could be useful
17:01:36 <nigel> Pierre: I can follow up, it doesn't have to be a group thing?
17:01:40 <nigel> Nigel: No, I don't think so.
17:01:56 <nigel> Chris: If you wanted to frame this as an official TTWG thing we could go down the route of adding a logo,
17:02:03 <nigel> .. but we can maybe treat it less formally.
17:02:19 <nigel> Pierre: I can email Thomas and copy Chris and Nigel and gauge the interest by the response, then
17:02:23 <nigel> .. we can figure it out.
17:02:41 <nigel> Nigel: How soon do they need a response?
17:02:52 <nigel> Chris: It's planned for 8th December so quite soon.
17:02:59 <nigel> Pierre: I'll send something today.
17:03:27 <nigel> Topic: Meeting close
17:03:51 <nigel> Nigel: Thank you everyone, and Chris for scribing. Have a good rest of day, let's adjourn now. [adjourns meeting]
17:03:53 <cpn> s/8th/6th and 7th/
17:04:03 <nigel> rrsagent, make minutes
17:04:04 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/09-tt-minutes.html nigel
17:15:06 <nigel> s/the authoring application meets the requirements of HRM/some of the authoring applications meet the requirements of HRM
17:15:52 <nigel> s/it doesn't demonstrate effectiveness of HRM/it doesn't demonstrate implementation, but it does demonstrate effectiveness of HRM
17:17:27 <nigel> s/exaclty/exactly/g
17:18:28 <nigel> s/608 appends 2 characters per time period, should be something a modern renderer should easily achieve/A naive view would be that merely appending 2 characters every frame is something that a modern renderer should easily achieve
17:19:58 <nigel> s/potential causes of HRM failure/potential causes of HRM failure and their mitigations
17:22:52 <nigel> rrsagent, make minutes
17:22:53 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/09-tt-minutes.html nigel
17:25:41 <nigel> scribeOptions: -final -noEmbedDiagnostics
17:25:44 <nigel> zakim, end meeting
17:25:44 <Zakim> As of this point the attendees have been Chris, Cyril, Matt, Nigel, Pierre, Mike
17:25:46 <Zakim> RRSAgent, please draft minutes v2
17:25:47 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/09-tt-minutes.html Zakim
17:25:53 <Zakim> I am happy to have been of service, nigel; please remember to excuse RRSAgent.  Goodbye
17:25:53 <Zakim> Zakim has left #tt