Meeting minutes
This meeting
Nigel: Today, we have IMSC-HRM, DAPT and an AOB about 5G-MAG OSMART workshop
… Is there any other business, or points for us to make sure we cover within those topics?
group: no AOB
IMSC-HRM
Nigel: I think we set a timeline, where we'd be looking to transition to the next maturity stage about now
… which would be PR, so we'd need to meet CR exit criteria
… That requires evidence of implementation, either a validating or an authoring implementation (as demonstrated by content)
… I've had three organisations contact me that they'd run content through HRM with good results
Pierre: One was 25,000 documents
Nigel: If your validating implementation passes the tests, Pierre, we can demonstrate everything we need for CR exit?
Pierre: I'm confident that we've demonstrated implementation experience
Mike: At ATSC, we ran both positive and negative content, and it flagged every document
Nigel: That shows the HRM conceptually is useful
… and also the effectiveness of the tool used to check it
… If we can say those files were generated with a different implementation from the ones that passed,
… we can say we have evidence with multiple pots of content, and some of the authoring applications meet the requirements of HRM
… But if they're all produced by the same tool, it doesn't demonstrate implementation, but it does demonstrate effectiveness of HRM
Mike: We used two encoders, hundreds of documents
Nigel: So to demonstrate success, although the ones that failed demonstrate utility of HRM, we only want the ones that passed to demonstrate success
Pierre: We want the ones we know pass to pass, and the ones that should fail, fail
Mike: If everything passes, you don't really know anything
Cyril: Discussed with Pierre last week, related to failures
… I ran 3000 Netflix content through, and none failed. More recently testing live content, a naive implementation of 608 conversion
… 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
Mike: As it should. We had similar experience, the encoder was doing 608 conversion, badly
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?
… It means the HRM as configured today has some known limitations, but is that ok?
… I'm not convinced it's not too strict
… Our implementation of naive conversion, it plays fine in the Netflix players
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
… Decoders weren't built to do that. I think it's an unreasonable thing to expect implementations to handle
… If we want redesign HRM to handle those things, OK
… I'd be concerned about relaxing that, as there are TVs that can't display it
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
Pierre: TTML isn't 608, different data model, rendering model. 608 is a state machine
… 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
<Zakim> pal, you wanted to react to a previous speaker
Pierre: TTML is a document with semantics, line breaks, regions. The two models are entirely different
… The idea of converting 608 to TTML and expecting the same thing, is nonsensical
… 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 exactly what the 608 was
Mike: I agree with that
Pierre: The second point is, at the time there was significant limitation in terminals
… Nothing close to Android on TVs. The model was created so all reasonable TVs would have a shot at rendering TTML
… No expectation that a TV could render 30 or 60 TTML documents a second, which is the rate 608 transmits data
… In general, I'm not suprised it would fail on naive translation of 608 content
Nigel: Don't disagree with any of the above
… A naive view would be that merely appending 2 characters every frame is something that a modern renderer should easily achieve
… I think that mischaracterises the problem and the solution space. A couple of extra things need to happen
… 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
… Secondly, the 608 and similar models from that era are based on a stateful decoder, where they append to what's already there
… Intent of how we deliver TTML is the receiver shouldn't have to maintain state
Mike: There's not a fundamental problem converting 608 to IMSC1 and fully meeting the HRM. I checked 3 encoding manufacturers, everything worked great
… One particular manufacturer, on one document. They reconstructed the screen 30x per second by adding 2 characters
… Caused the TV render the whole thing again. It was horrible, so should die though HRM violation
Cyril: Don't disagree it's a bad idea to convert 608 to TTML where you refresh only 2 characters
… The one thing I think we should be careful about, if we'd defined a simple TTML profile to match 608, it would work
… The other features are there, make it more complex for the implemntation. That's how we should explain it, people currently do 608 conversion
… Not good for us to say that that's nonsense
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
… TVs are getting better at handling this stuff
… What should be prohibited today may be fine in a few years
… The concept of a profile, or adjusting the complexity, depending on the application is a good idea
… Need to put a stake in the ground today
… 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
… It's good for today's technology, but make it smarter for the future
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
… If the goal is to allow a straight translation from 608, we're far from that
… Assuming that's not the goal, does the current HRM prevent creation of captions that meet the needs of end users?
… If the answer is no, we don't need additional controls
… Goal is a caption experience required by end users
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
… Useful to have that in the spec
Mike: I have 25 year old MPEG TS that exercises every 608 feature, 2 of 3 encoders get it right
Cyril: But they don't refresh the screen every frame
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
<Zakim> nigel, you wanted to come back to CR exit, when this discussion is done
Nigel: Add an issue to add an informative note on potential causes of HRM failure and their mitigations
… So pause CR exit until we've agreed wording
… We do need to be careful about the language and the reflection on the industry
… 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
… An action for somebody
Pierre: I'm happy to write the report, from the wiki page
Nigel: Need to be careful about people who described implementations
group: I'll take point on checking in with them to see if they're happy to be publicly named.
DAPT
Nigel: A few things on DAPT
… Horizontal review requests. APA has taken an action to do the review, hope to have response from them soon
… TAG has gone quiet, and no feedback on security
… I'll take an action to follow those up
… We sent liaisons, and some haven't responded yet. We'll proceed regardless, for the time being
Rework audio description original and translation languages w3c/dapt#179
github: w3c/
Nigel: This has gone through some iterations. Andreas has been actively reviewing
… 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
… I added a table in the issue with permutations
… It's clear if you're transcribing dialog or signing
… For content in the video image, it might be text or might not be. If text, can use lang source
… If it's a description of the image, or a sound effect, those things don't have a language
… 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
… And omit lang source if there isn't a language
… Also the concept of original language doesn't serve a purpose any more, and could be removed
Cyril: On the proposal to be clear on when lang source is present or not, that's fine
… Disagree that we don't need the original language
… It's to provide context on what the language was. When you're dubbing a show with multiple languages in the original source
… or a show translated to a pivot language to create a dubbing, knowing the orignal language can be useful
Nigel: That's a change of status of the flag. There are normative statements around original lang to change: make it a list
… if someone creates a silent video with no dialog, then it's audio described, what use is orignal lang?
Cyril: Doesn't have to be mandatory. The concept of original language should be preserved in the spec
… or original languages
… If the original languages are French and English, you can translate to English only, French only, or German
… If translation to German, you translate everything, but if translating to French you only translate the English parts
… It's complex, I need to continue to review. Seems going in the right direction
Mike: I try to get people to conform to BCP47. If you constrain to that, it's good. Use the IANA codes
Nigel: We do, yes
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 content
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
Add inline Registry Section w3c/dapt#196
github: w3c/
Nigel: Thank you Cyril for reviewing. Please take a look
… 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
… I've based this on the boilerplate text in the TTWG repo
… In doing this, I've had to raise a Process issue, but it's probably acceptable now to meet process requirements
… Please look, to see if it has any issues
SUMMARY: Please review!
AOB: 5G-MAG OSMART workshop
Chris: I'll paste a link into IRC.
Invitation on TTWG member list
Chris: This came to me from Thomas Stockhammer, who I assume is part of the organising
… group for this conference. It's 5G-MAG with DVB and has been extended to other organisations
… like DASH-IF, CTA-WAVE, ATSC, 35PP, W3C and others.
… Open invitation to share in the workshop anything about reference tools that have been
… developed to support specifications.
… Intent is to foster collaboration between standards groups.
… I thought of two areas of interest: IMSC-HRM and its tooling, and the imscJS implementation,
… and some other things like in MediaWG sample code for WebCodecs,
… or similar for WebTransport WG.
… Thomas latched onto the IMSC and TTML parts more so than the others.
… If you would like to present on the tooling that you've developed around IMSC and TTML, and the HRM,
… this is an opportunity to present at that workshop.
… What I'd like to do is to go back to either confirm or politely decline depending on what you prefer to do.
Nigel: It looks to me like it could be useful
Pierre: I can follow up, it doesn't have to be a group thing?
Nigel: No, I don't think so.
Chris: If you wanted to frame this as an official TTWG thing we could go down the route of adding a logo,
… but we can maybe treat it less formally.
Pierre: I can email Thomas and copy Chris and Nigel and gauge the interest by the response, then
… we can figure it out.
Nigel: How soon do they need a response?
Chris: It's planned for 6th and 7th December so quite soon.
Pierre: I'll send something today.
Meeting close
Nigel: Thank you everyone, and Chris for scribing. Have a good rest of day, let's adjourn now. [adjourns meeting]