15:49:42 RRSAgent has joined #media 15:49:42 logging to http://www.w3.org/2011/03/19-media-irc 15:49:50 rrsagent, do not start a new log 15:49:54 rrsagent, make log public 15:50:06 meeting: Media breakout, HTML Accessibility Task Force Face to Face 15:50:11 chair: Janina_Sajka 15:50:36 Zakim has joined #media 15:50:42 zakim, this will be 21192 15:50:42 ok, MichaelC; I see WAI_(A11YAF2F)11:30AM scheduled to start 20 minutes ago 15:51:42 WAI_(A11YAF2F)11:30AM has now started 15:51:46 WAI_(A11YAF2F)11:30AM has ended 15:51:47 Attendees were 15:56:34 MichaelC has changed the topic to: HTML Accessibility Task Force Face2Face [Media Breakout] Day 1 2011-03-19 15:57:36 oedipus has joined #media 16:03:01 silvia has joined #media 16:03:07 Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0131.html 16:03:10 JF has joined #media 16:03:11 MikeSmith has joined #media 16:04:01 http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0131.html 16:10:25 bug on text alternatives for video: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12228 16:17:26 Sean has joined #media 18:09:32 JF has joined #media 18:09:49 WAI_(A11YAF2F)11:30AM has now started 18:09:56 +??P0 18:10:28 zakim, ??P0 is FtF 18:10:28 +FtF; got it 18:11:44 test 18:12:03 janina has joined #media 18:13:12 mkobayas has joined #media 18:13:24 richardschwerdtfe has joined #media 18:14:08 zakim, agenda? 18:14:08 I see nothing on the agenda 18:15:02 eric_carlson_ has joined #media 18:15:02 silvia1 has joined #media 18:15:37 silvia has joined #media 18:15:50 lwatson_ has joined #media 18:16:00 MikeSmith has joined #media 18:16:07 dboudreau has joined #media 18:16:09 MichaelC has joined #media 18:16:39 frankolivier has joined #media 18:18:03 richardschwerdtfe has joined #media 18:19:11 TOPIC: Review of Use Cases on ISSUE-152 multitrack media 18:19:55 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API 18:20:10 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_Rendering 18:20:19 scribe: lwatson 18:21:03 test 18:21:26 Sean has joined #media 18:22:25 eric_carlson has joined #media 18:22:54 JF has joined #media 18:23:01 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_Rendering 18:23:05 + 1. Review of Use Cases 18:23:07 + 2. JS API for in-band and manifests 18:23:08 + 3. HTML markup for external tracks 18:23:10 + 4. CSS and rendering 18:23:12 + 5. Error handling for multitrack and track (see 18:23:13 http://www.w3.org/Bugs/Public/show_bug.cgi?id=8657) 18:23:15 + 6. Event handling for http://www.w3.org/Bugs/Public/show_bug.cgi?id=8659 and 18:23:18 http://lists.w3.org/Archives/Public/public-html-a11y/2011Mar/0018.html) 18:23:20 + 7. Navigation between tracks, see 18:23:22 http://www.w3.org/html/wg/tracker/issues/163 18:23:52 SP: It is a collection of images that show how multi-track video can be displayed. 18:24:09 SP: The question is what use cases do we want to support? 18:24:39 SP: There are two videos in parallel, they are independent but synchronised. Is this is something we want to consider? 18:24:48 janina has joined #media 18:25:00 zakim, who's here? 18:25:00 On the phone I see FtF 18:25:01 SH: You may want to use this for duplicating content in sign language. 18:25:01 On IRC I see janina, JF, eric_carlson, Sean, richardschwerdtfe, frankolivier, MichaelC, dboudreau, MikeSmith, lwatson, silvia, mkobayas, oedipus, Zakim, RRSAgent 18:25:31 EC: If we want to support multi-track, it doesn't matter if it's co-related. 18:26:32 EC: If we want to be able to support picture and picture/synchornising multiple video streams, the presentation issue a separate issue. 18:26:50 SP: There will be challenges. Should there be one set of controls or two? 18:27:41 EC: In the image, the side/side videos have their own controls. IMHO, we should not try to support this. This could be done through script... 18:27:47 SP: Except for the synchronisation part. 18:27:57 SH: In this example, are they playing the same tune? 18:28:21 SH: If you want it to ound good, it needs to be synchronised properly. 18:28:46 SP: A solution for snychronisation would be good. 18:28:54 SH: Is that an accessibility issue or not? 18:29:00 JF: Yes, absolutely. 18:38:33 EC: I think that having independent video elements on the page and synchronizing them through a mechanism as a solution to accessibility needs (audio description & sign language video) is too difficult to authors to deal with, e.g. having to write custom CSS and custom JS for it 18:38:49 EC: I strongly believe we have to make it simple for authors to provide this a11y content 18:39:37 SP: so we cannot provide a solution to a11y needs by providing multiple video elements on a page and synchornizing them to each other 18:40:33 JF: we need both, in-band and out of band support 18:41:03 FO: can we solve the out-of-band with JAvaScript? how closely synchronized do things need to be? 18:41:31 SP: not good enough - I have an example that shows how stongly the elements go out of sync 18:41:53 EC: yes, not good enough - what about scrubbing etc 18:42:42 SH: you can do it in JS through the event, unless you want to do in-sync audio 18:43:35 audio-level synchronization cannot be done in JS, so we need a solution for it 18:43:50 EC: we need markup so we have combined controls 18:47:01 Summary of our use case discussion: 18:47:32 (1) we need to support in-band multitrack media, e.g. sign language, audio description, language dubs provided in the same resource in-band 18:47:33 (2) 18:48:28 we need to support out-of-band mutltirack media which are tightly coupled, in that they require a single control, where the main resource is a master and the markup needs to be simple without requiring extra CSS to display them as though they were in-band 18:49:16 (3) we may want to support out-of-band multitrack media which are loosely coupled, in that they are separate elements on the page each with their own controls, but interacting with one means the other(s) follow 18:50:14 lwatson has joined #media 18:51:52 guidance for developing the synchronization: 18:52:13 * video should be synchronized for sign language to 0.5sec accuracy 18:52:24 * audio should be synchronized for audio descriptions to 100ms resolution 18:53:32 * we want to achieve a consistent API between in-band and external audio/video tracks 18:53:51 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API 18:54:50 * we want to be able to control the relative volume of a additional audio track by user and author 18:56:10 * we want to be able to control positioning of video tracks as picture-in-picture or side-by-side viewports in script by author 18:59:12 * we don't want to inflict more complexity on the selection, which is based on choice of encoding formats, but we can replicate that somewhere else 19:01:52 * the same source selection algorithm needs to be applied to all choices of media encoding formats, so it is predictable to the author 19:05:39 * we want to satisfy the 80% case - e.g. synchronizing an extended audio description with an un-extended original video is not what we want to do here (you can do that by also using a TimedTrack and JS) 19:06:13 rrsagent, make minutes 19:06:13 I have made the request to generate http://www.w3.org/2011/03/19-media-minutes.html lwatson 19:07:08 ACTION 2. JS API for in-band and manifests 19:09:08 For our proposal: We're happy to have a generic JS API for enumerating/enabling inband and non-inband tracks 19:09:47 JF: It seems that changing CSS is a bigger challenge. 19:10:25 EC: I think it woul be a mistake to do it in the markup. It's requiring more from the author, and it has the same issue that people complain about with having to keep markup in synch with the format of the external file. 19:10:38 EC: We'd be better off working with the CSS I think. 19:11:24 SP: I agree that whe the tracks are inside the resource you already have the whole description. 19:11:54 JF: Should we invite someone from CSS WG into the discussion? 19:12:06 SP: Let's propose our suggestion and see what happens. 19:12:42 EC: It's a way to style in band and out band tracks using pseudo selectors. 19:13:11 SP: Can we agree we don't need extra markup for in band tracks? 19:15:01 * default track selection should come from the container in the in-band case 19:16:19 FO: when we talk about track, do we mean audio, video *and* text? 19:16:48 SP: basically anything time-synchronized data 19:18:02 FO: any additional content that supplements the main audio/video track in time-sync 19:43:50 dboudreau has joined #media 20:11:43 TOPIC 2: JS API for in-band and manifests 20:11:50 scribe: janina 20:12:03 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API#.281.29_No_markup_in_HTML_-_leave_to_a_manifest_file 20:12:12 http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API#.289.29_Audio_Track_Selection_for_Media_Element_.2F_In-band_only 20:12:13 ec: we want to end up with the same api for in and out of band media--eventually 20:13:12 interface HTMLMediaElement : HTMLElement { 20:13:12 [...] 20:13:12 // audio tracks 20:13:12 readonly attribute unsigned long audioTrackCount; 20:13:13 readonly attribute DOMString audioTrackLanguage[]; 20:13:14 attribute unsigned long currentAudioTrack; 20:13:17 }; 20:13:55 == 20:14:10 interface MediaTrack { 20:14:10 readonly attribute DOMString kind; 20:14:10 readonly attribute DOMString label; 20:14:10 readonly attribute DOMString language; 20:14:10 const unsigned short OFF = 0; 20:14:13 const unsigned short HIDDEN = 1; 20:14:15 const unsigned short SHOWING = 2; 20:14:17 attribute unsigned short mode; 20:14:21 } 20:14:23 interface HTMLMediaElement : HTMLElement { 20:14:25 [...] 20:14:27 readonly attribute TextTrack[] textTracks; 20:14:28 readonly attribute MediaTrack[] mediaTracks; 20:14:30 }; 20:16:09 fo: what does the author do with kind? 20:16:26 ec: should be a defined list to select from 20:16:53 sp: everything we make available we need also api for custom controls 20:18:27 discussion of referring to external tracks inband 20:18:53 mpeg4 supports this via manifest 20:19:36 sp: api has onload and onerr ... keep? drop? 20:20:03 fo: keep symetry between in and out of band -- to support authoring flexibility 20:20:52 ec: authors shouldn't have to care 20:21:07 basing discussion on second interface pasted above since it is more generic 20:21:39 need to add back in all the IDL attributes and functions of the TextTrack API, because authors should not need to care where the data comes from 20:22:08 in particular events should be identical so registration would not depend on the type of track 20:22:14 add back in... 20:22:15 attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#function http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#handler-texttrack-onload; 20:22:16 attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#function http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#handler-texttrack-onerror; 20:22:28 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-none = 0; 20:22:28 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-loading = 1; 20:22:28 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-loaded = 2; 20:22:28 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-error = 3; 20:22:31 readonly attribute unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-readystate; 20:22:51 readyState may not mean much and my be a reflection of the state from the main resource 20:23:17 we have complications on cues: 20:23:18 readonly attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#texttrackcuelist http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-cues; 20:23:18 readonly attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#texttrackcuelist http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-activecues; 20:23:18 attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#function http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#handler-texttrack-oncuechange; 20:24:39 is there a need for audio and video for these? 20:25:54 ec: we may need to subclass similar to how HTMLMediaElement works 20:26:03 +??P3 20:26:35 http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#text-track-api 20:27:53 FO: deriving from base class makes sense, but what if we have data that is different to audio/video/text? 20:28:03 … won't we restrict ourselves too much? 20:28:14 EC: no, because we'll have mediatrack and that is more generic 20:28:24 interface HTMLMediaElement : HTMLElement { 20:28:25  [...] 20:28:25  readonly attribute TextTrack[] textTracks; 20:28:25  readonly attribute MediaTrack[] mediaTracks; 20:28:25 }; 20:29:08 Thanks, Michael. Is your phone OK? 20:29:21 SP: does it make more sense to have audioTracks and videoTracks? 20:29:36 EC: we don't want a proliferation of attributes … so I'm torn 20:30:16 EC: I think I prefer mediaTracks, because the script can figure out what type it is 20:30:36 SP: do we need a mime type or something? 20:31:16 EC: we introduced mediaType into proposal 8 20:32:00 -??P3 20:32:06 FO: I'm concerned we need different interfaces for audio and video 20:32:14 EC: yes, I think we need more attributes 20:32:20 +??P3 20:32:55 EC: we have two levels - media is the parent, audio, video and text derive from that 20:34:28 SP: hmm, do we then even need textTracks? 20:34:44 EC: no, we only need tracks then as an attribute in HTMLMediaElement 20:35:54 silvia has joined #media 20:35:54 eric_carlson has joined #media 20:36:00 MikeSmith has joined #media 20:36:07 SP: are we replicating attributes from the parent? 20:36:12 MichaelC_ has joined #media 20:36:14 EC: no we should not, only some select ones 20:36:19 Sean has joined #media 20:36:20 JF has joined #media 20:37:18 FO: eveything that has to do with loading and buffering need to be replicated, but anything to do with time should not 20:37:27 lwatson has joined #media 20:37:38 .. or playbackrate 20:38:29 SH: what about src and currentSrc - would you be able to change them? 20:38:42 SP: for in-band it doesn't make sense 20:38:54 EC: for out-of-band we shouldn't make this available either 20:38:58 richardschwerdtfe has joined #media 20:39:23 FO: we need src to provide the original url 20:39:45 EC: it should be read-only 20:40:24 .. can't be read-only because you need to set it once 20:41:06 FO: why would you ever want to change the src of a media track? 20:41:14 EC: for example if you have a playlist 20:41:37 SP: you could completely remove the video element and re-build the whole thing 20:42:03 EC: hmm, you already have to handle all the work when it's set the first time, so changing it on the fly should be similar 20:42:37 .. the ready state is available to both 20:42:56 dboudreau has joined #media 20:43:06 FO: we should make the track elements behave a lot like the media elements 20:45:50 agreement in general that we should have only one tracks attribute to add to the HTMLMediaElement 20:46:43 janina has joined #media 20:46:50 zakim, who's here? 20:46:50 On the phone I see FtF, ??P3 20:46:51 SH: we need a separate way to set volume - need an audioTrack element 20:46:52 On IRC I see janina, dboudreau, richardschwerdtfe, lwatson, JF, Sean, MichaelC, MikeSmith, silvia, frankolivier, mkobayas, oedipus, Zakim, RRSAgent 20:47:06 SP: what to do with video that also has an audio track? 20:47:14 zakim, drop ??P3 20:47:14 ??P3 is being disconnected 20:47:16 -??P3 20:47:37 +??P3 20:47:52 EC: I don't think we should offer flow control at the track level 20:48:09 SH: would audio and video behave independently? 20:48:11 zakim, ??p3 is F2F 20:48:11 +F2F; got it 20:48:20 zakim, who's on the phone? 20:48:20 On the phone I see FtF, F2F 20:48:45 zakim, drop FtF 20:48:45 FtF is being disconnected 20:48:46 -FtF 20:50:20 EC: they should behave like there are two separate tracks 20:51:06 eric_carlson has joined #media 20:51:46 interface MediaTrack { 20:51:47 readonly attribute DOMString http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-kind; 20:51:47 readonly attribute DOMString http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-label; 20:51:47 readonly attribute DOMString http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-language; 20:51:50 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-none = 0; 20:51:53 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-loading = 1; 20:51:55 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-loaded = 2; 20:51:59 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-error = 3; 20:52:02 readonly attribute unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-readystate; 20:52:05 attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#function http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#handler-texttrack-onload; 20:52:08 attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#function http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#handler-texttrack-onerror; 20:52:13 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-off = 0; 20:52:16 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-hidden = 1; 20:52:19 const unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-showing = 2; 20:52:22 attribute unsigned short http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-mode; 20:52:25 [these are the attributes from the TextTrack that make general sense] 20:54:39 it would be nice to unify the states in the "readyState" here, because they apply uniformly for audio, video and text tracks 20:56:39 we need to add the @default attribute in the IDL: 20:57:02 readonly attribute DOMString default; 20:59:18 SH: I would prefer to be able to turn multiple on by default 20:59:40 have a showing attribute, rahter than a default 21:01:38 mode="showing" is more flexible 21:04:15 SH: what we don't want is two attributes that influence the same IDL 21:05:40 zakim, who's on the phone? 21:05:40 On the phone I see F2F 21:07:08 SH: there is no way from markup to say "download this but don't show it" 21:07:28 lwatson has joined #media 21:07:33 FO: you need two concepts 21:07:59 … for mobile devices you need to have some sort of preload attribute that says "don't download this data at all" 21:08:25 … similarly you need to have the concept of requiring download of all the necessary track data before you allow playbac 21:08:26 k 21:09:12 EC: I think the description of tracks right now requires captions to be downloaded before playback - the element can't reach HAVE_METADATA before they have loaded 21:09:21 . 21:10:44 SP: do we need information on whether we want alternative data to be loaded before going to HAVE_METADATA? 21:11:08 FO: if we use mode, then we can do it: OFF means not to wait and HIDDEN or SHOWING would require to wait 21:11:30 s/HIDDEN or/ 21:11:43 … HIDDEN would allow starting playback while in the background loading the resource 21:11:56 s/HIDDEN or// 21:12:56 SP: so do we want to remove the @default attribute and instead have a @mode attribute with values in {off, hidden, showing} ? 21:13:33 EC: what if I just want one as the default? 21:13:43 SP: then just set the attribute on that to @mode="showing" 21:14:12 EC: what if the UA need something else as the default from settings - would it overwrite what the author set? 21:14:53 FO: are you allowed as the UA to overwrite the value of @mode ? 21:17:00 FO: same thing with the windows-wide setting for showing captions/subtitles 21:17:53 SP: if the author e.g. set the english track to @mode="showing", but my UA settings say to grab the french ones, then the UA should set the english track to @mode="hidden" and the french one to @mode="showing" 21:18:31 SH: we then also need an event onchangemode 21:19:58 EC: what if we have a situation where we need multiple tracks showing, or one always on, such as in a language lab? 21:21:40 SP: the 80% use case I think is that we have only one track of one type active at one time 21:23:28 … if we need more than one track active, we can always use script 21:24:37 FO: we can do multiple tracks through multiple @mode attributes already 21:24:59 SH: what if the UA can just turn on additional ones 21:25:19 .. then have to turn them off 21:25:47 SP: not really useful 21:26:57 JF: what if we have english and french tracks, but my UA settings are spanish 21:27:28 FO: if there is no track in my language, then nothing should be shown 21:27:38 EC: or the first track - it needs to be predictable 21:31:43 FO: only overwrite an author's settings if nothing is specified 21:35:56 EC: leave the default choice to the browser 21:37:47 FO: what if the controls attribute it set and the menu is showing - what then? 21:37:54 EC: right-click menu 21:38:29 FO: if the @controls is not set, is the user allowed to fiddle with the state of the media resource 21:38:47 EC: I think yes, and all the basic controls should be available in the context menu 21:39:10 FO: so my custom controls need to deal with it? 21:41:25 EC: if I as a conscientious author would mark them up so the UA chooses, would I mark up all tracks as @mode="off"? 21:41:35 SP: no, I wouldn't provide @mode at all 21:42:42 EC: for audio and video it makes a big difference if hidden also means preloading 21:43:54 FO: so, there is no @default attribute, but the default mode on all tracks is OFF 22:05:40 SP: do we need src, currentSrc and load() next? 22:05:41 http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-src 22:07:04 EC: don't think we need load() for changing the url, because the spec now says to run the source selection algo upon changing 22:07:20 … load() is just used to reset state of the video element 22:08:36 frankolivier has joined #media 22:09:25 … nothing will happen until the script has gone back to idle 22:10:13 … resetting only needs to be available on main video 22:10:32 … but you can change the src 22:10:51 SH: video.load() should filter down to any tracks 22:10:53 JF has joined #media 22:11:46 SP: so, if I change the @src on a track, then the UA should load it and jump to the time offset of video.currentTime 22:12:22 … so that is additional work to what is in the general media element load algorithm 22:13:20 … it is similar to setting startOffset on main resource, but that element should only exist on the main resource 22:13:24 s/element/attribute/ 22:14:52 lwatson has joined #media 22:14:53 JF has joined #media 22:14:59 SH: do we need canPlayType() on tracks? 22:15:21 EC: semantically it is only required by the media element 22:15:54 SP: it's only required to find out what codecs your browser supports 22:16:15 … so the same applies to tracks as well as