- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Fri, 10 Jul 2015 14:11:03 +0000
- To: "dom@w3.org" <dom@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-pfwg@w3.org" <public-pfwg@w3.org>
Dear WebRTC Group, Thank you for your response to my comment. I agree that the current WD does not deal with streams of data related to the media, so in that sense you have provided an accurate answer. However I am far from certain that this is acceptable. As far as I can see this constraint prevents WebRTC both from being augmented with accessibility data for example subtitles/captions and from being augmented with other data-based functionality such as the display of text or graphics not associated with accessibility. I note that the Working Group Charter lists a dependency on WAI Protocols and Formats Working Group: "Reviews from the WAI PF Working Group will be required to ensure the APIs allow to create an accessible user experience." I am not a member of WAI PFWG but have copied in public-pfwg@w3.org to this message to ensure they have visibility of my comment: at present I believe that the APIs do not "allow to create an accessible user experience." I would suggest it should be a matter of priority for the Working Group to consider adding this capability. You request a proposal for a specific solution for this. One possible solution would be to extend the MediaStreamTrack.kind attribute to permit the value "data" and to have a further more specific type so that user agents can process data tracks successfully. It may also be helpful or necessary to expose a common clock with which such data may be synchronised - further design work to establish the importance of this would be needed. An example of the usage scenario could be the provision of a sequence of TTML or WebVTT documents which, on presentation, provide subtitles/captions for the video or audio content. This could be achieved by having a MediaStreamTrack of kind "data" and subtype "ttml+xml" in the case of TTML. Kind regards, Nigel -- Nigel Megitt Executive Product Manager, BBC Engineering On 07/07/2015 14:14, "dom@w3.org" <dom@w3.org> wrote: > Dear Nigel Megitt , > >The Web Real-Time Communications Working Group has reviewed the comments >you sent [1] on the Last Call Working Draft [2] of the Media Capture and >Streams published on 14 Apr 2015. Thank you for having taken the time to >review the document and to send us comments! > >The Working Group's response to your comment is included below, and has >been implemented in the new version of the document available at: >http://w3c.github.io/mediacapture-main/archives/20150629/getusermedia.html >. > >Please review it carefully and let us know by email at >public-media-capture@w3.org if you agree with it or not before 17 July >2015. In case of disagreement, you are requested to provide a specific >solution for or a path to a consensus with the Working Group. If such a >consensus cannot be achieved, you will be given the opportunity to raise a >formal objection which will then be reviewed by the Director during the >transition of this document to the next stage in the W3C Recommendation >Track. > >Thanks, > >For the Web Real-Time Communications Working Group, >Dominique Hazaël-Massieux >Vivien Lacourba >W3C Staff Contacts > > 1. http://www.w3.org/mid/D1543486.1E5DD%nigel.megitt@bbc.co.uk > 2. http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ > > >===== > >Your comment on the document as a whole: >> Does this work include the capture of related streams of media and/or >> data >> with common timing references, such as captions or subtitles? > > >Working Group Resolution (LC-3013): >This document does not deal with streams of data related to the media. >Such >functions could be contemplated as further work once this document is >done, >but the Working Group does not suggest adding this functionality at this >time. > >The Working Group does not contemplate any change based on this comment. > >---- > >
Received on Friday, 10 July 2015 14:11:35 UTC