skynavga
commented
6 years ago regarding #embedded-audio, this is trivial to implement using a transformation step in your processing pipeline that extracts the embedded audio from the TTML document, uploads it to your server of choice, then rewrites the relevant TTML element, e.g., one of an audio, data, or source element as appropriate, to refer to the now server based resource;
regarding #audio-description, yes we can pare that down, though my (conceptual) model of speech processing is to convert text to speech as audio resources, at which point it looks just like the non-speech audio processing model;
regarding #speech, support means "support by any means possible"; you are over-thinking the significance of support here, and conceptually, we need something to allow an author to indicate they require text to speech functionality (in whatever way the implementation wishes to provide it); note that #speech is really not any different than #lineBreak-uax14 which uses identical language re: supports; if you want, we could add a note that indicates the support may be built-in or remoted
so, overall, I think you can positively report support for #embedded-audio (if you can do the above trivial transform - which may involve a human doing the transform) and #speech (if you can do any kind of TTS, local or remote)
if so, then that leaves only your third bullet above, which we can do without any significant impact (IMO)
nigelmegitt
css-meeting-bot
Having reviewed the BBC's ability to provide presentation implementations for the audio features, I would like to propose the following changes to at-risk features:
#embedded-audiofeature designator, because it requires playback of audio resources embedded in the TTML2 file which BBC does not expect to be able to demonstrate. I would not like to remove the syntactical possibility of embedded audio resources directly, but arguably we may need to do that also. If I can find a way for BBC to implement this in the next day or so then I will propose "un-removing"#embedded-audio- I'm merely taking a conservative line here given the limited amount of remaining time.#embedded-audioto#audioin#audio-descriptionto match the previous change.#embedded-audio,#gainand#panfrom#audio-speechbecause I do not think we can implement them all together straightforwardly, at least not so they are all applied at once to the same text using a combination of Web Audio API and Web Speech API, as they are in their current states; other implementation techniques could be made to work, such as making external asynchronous calls to a suitable text to speech service and playing back the resulting audio resource, but that requires a further degree of complexity.#speechbecause it is not clear what it means for an implementation to "support" a speech synthesis processor, for example must the implementation include one or merely access one remotely? If the implementation can successfully implement#speakand#pitchthen it has adequate support; further support is not required, in my view.