IRC log of media on 2011-03-19

Timestamps are in UTC.

15:49:42 [RRSAgent]
RRSAgent has joined #media
15:49:42 [RRSAgent]
logging to
15:49:50 [MichaelC]
rrsagent, do not start a new log
15:49:54 [MichaelC]
rrsagent, make log public
15:50:06 [MichaelC]
meeting: Media breakout, HTML Accessibility Task Force Face to Face
15:50:11 [MichaelC]
chair: Janina_Sajka
15:50:36 [Zakim]
Zakim has joined #media
15:50:42 [MichaelC]
zakim, this will be 21192
15:50:42 [Zakim]
ok, MichaelC; I see WAI_(A11YAF2F)11:30AM scheduled to start 20 minutes ago
15:51:42 [Zakim]
WAI_(A11YAF2F)11:30AM has now started
15:51:46 [Zakim]
WAI_(A11YAF2F)11:30AM has ended
15:51:47 [Zakim]
Attendees were
15:56:34 [MichaelC]
MichaelC has changed the topic to: HTML Accessibility Task Force Face2Face [Media Breakout] Day 1 2011-03-19
15:57:36 [oedipus]
oedipus has joined #media
16:03:01 [silvia]
silvia has joined #media
16:03:07 [silvia]
16:03:10 [JF]
JF has joined #media
16:03:11 [MikeSmith]
MikeSmith has joined #media
16:04:01 [silvia]
16:10:25 [silvia]
bug on text alternatives for video:
16:17:26 [Sean]
Sean has joined #media
18:09:32 [JF]
JF has joined #media
18:09:49 [Zakim]
WAI_(A11YAF2F)11:30AM has now started
18:09:56 [Zakim]
18:10:28 [MichaelC]
zakim, ??P0 is FtF
18:10:28 [Zakim]
+FtF; got it
18:11:44 [Sean]
18:12:03 [janina]
janina has joined #media
18:13:12 [mkobayas]
mkobayas has joined #media
18:13:24 [richardschwerdtfe]
richardschwerdtfe has joined #media
18:14:08 [janina]
zakim, agenda?
18:14:08 [Zakim]
I see nothing on the agenda
18:15:02 [eric_carlson_]
eric_carlson_ has joined #media
18:15:02 [silvia1]
silvia1 has joined #media
18:15:37 [silvia]
silvia has joined #media
18:15:50 [lwatson_]
lwatson_ has joined #media
18:16:00 [MikeSmith]
MikeSmith has joined #media
18:16:07 [dboudreau]
dboudreau has joined #media
18:16:09 [MichaelC]
MichaelC has joined #media
18:16:39 [frankolivier]
frankolivier has joined #media
18:18:03 [richardschwerdtfe]
richardschwerdtfe has joined #media
18:19:11 [silvia]
TOPIC: Review of Use Cases on ISSUE-152 multitrack media
18:19:55 [silvia]
18:20:10 [silvia]
18:20:19 [lwatson]
scribe: lwatson
18:21:03 [dboudreau]
18:21:26 [Sean]
Sean has joined #media
18:22:25 [eric_carlson]
eric_carlson has joined #media
18:22:54 [JF]
JF has joined #media
18:23:01 [silvia]
18:23:05 [JF]
+ 1. Review of Use Cases
18:23:07 [JF]
+ 2. JS API for in-band and manifests
18:23:08 [JF]
+ 3. HTML markup for external tracks
18:23:10 [JF]
+ 4. CSS and rendering
18:23:12 [JF]
+ 5. Error handling for multitrack and track (see
18:23:13 [JF]
18:23:15 [JF]
+ 6. Event handling for <track(see
18:23:17 [JF] and
18:23:18 [JF]
18:23:20 [JF]
+ 7. Navigation between tracks, see
18:23:22 [JF]
18:23:52 [lwatson]
SP: It is a collection of images that show how multi-track video can be displayed.
18:24:09 [lwatson]
SP: The question is what use cases do we want to support?
18:24:39 [lwatson]
SP: There are two videos in parallel, they are independent but synchronised. Is this is something we want to consider?
18:24:48 [janina]
janina has joined #media
18:25:00 [janina]
zakim, who's here?
18:25:00 [Zakim]
On the phone I see FtF
18:25:01 [lwatson]
SH: You may want to use this for duplicating content in sign language.
18:25:01 [Zakim]
On IRC I see janina, JF, eric_carlson, Sean, richardschwerdtfe, frankolivier, MichaelC, dboudreau, MikeSmith, lwatson, silvia, mkobayas, oedipus, Zakim, RRSAgent
18:25:31 [lwatson]
EC: If we want to support multi-track, it doesn't matter if it's co-related.
18:26:32 [lwatson]
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 [lwatson]
SP: There will be challenges. Should there be one set of controls or two?
18:27:41 [lwatson]
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 [lwatson]
SP: Except for the synchronisation part.
18:27:57 [lwatson]
SH: In this example, are they playing the same tune?
18:28:21 [lwatson]
SH: If you want it to ound good, it needs to be synchronised properly.
18:28:46 [lwatson]
SP: A solution for snychronisation would be good.
18:28:54 [lwatson]
SH: Is that an accessibility issue or not?
18:29:00 [lwatson]
JF: Yes, absolutely.
18:38:33 [silvia]
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 [silvia]
EC: I strongly believe we have to make it simple for authors to provide this a11y content
18:39:37 [silvia]
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 [silvia]
JF: we need both, in-band and out of band support
18:41:03 [silvia]
FO: can we solve the out-of-band with JAvaScript? how closely synchronized do things need to be?
18:41:31 [silvia]
SP: not good enough - I have an example that shows how stongly the elements go out of sync
18:41:53 [silvia]
EC: yes, not good enough - what about scrubbing etc
18:42:42 [silvia]
SH: you can do it in JS through the event, unless you want to do in-sync audio
18:43:35 [silvia]
audio-level synchronization cannot be done in JS, so we need a solution for it
18:43:50 [silvia]
EC: we need markup so we have combined controls
18:47:01 [silvia]
Summary of our use case discussion:
18:47:32 [silvia]
(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 [silvia]
18:48:28 [silvia]
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 [silvia]
(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]
lwatson has joined #media
18:51:52 [silvia]
guidance for developing the synchronization:
18:52:13 [silvia]
* video should be synchronized for sign language to 0.5sec accuracy
18:52:24 [silvia]
* audio should be synchronized for audio descriptions to 100ms resolution
18:53:32 [silvia]
* we want to achieve a consistent API between in-band and external audio/video tracks
18:53:51 [silvia]
18:54:50 [silvia]
* we want to be able to control the relative volume of a additional audio track by user and author
18:56:10 [silvia]
* 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 [silvia]
* we don't want to inflict more complexity on the <source> selection, which is based on choice of encoding formats, but we can replicate that somewhere else
19:01:52 [silvia]
* 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 [silvia]
* 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 [lwatson]
rrsagent, make minutes
19:06:13 [RRSAgent]
I have made the request to generate lwatson
19:07:08 [silvia]
ACTION 2. JS API for in-band and manifests
19:09:08 [frankolivier]
For our proposal: We're happy to have a generic JS API for enumerating/enabling inband and non-inband tracks
19:09:47 [lwatson]
JF: It seems that changing CSS is a bigger challenge.
19:10:25 [lwatson]
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 [lwatson]
EC: We'd be better off working with the CSS I think.
19:11:24 [lwatson]
SP: I agree that whe the tracks are inside the resource you already have the whole description.
19:11:54 [lwatson]
JF: Should we invite someone from CSS WG into the discussion?
19:12:06 [lwatson]
SP: Let's propose our suggestion and see what happens.
19:12:42 [lwatson]
EC: It's a way to style in band and out band tracks using pseudo selectors.
19:13:11 [lwatson]
SP: Can we agree we don't need extra markup for in band tracks?
19:15:01 [silvia]
* default track selection should come from the container in the in-band case
19:16:19 [silvia]
FO: when we talk about track, do we mean audio, video *and* text?
19:16:48 [silvia]
SP: basically anything time-synchronized data
19:18:02 [silvia]
FO: any additional content that supplements the main audio/video track in time-sync
19:43:50 [dboudreau]
dboudreau has joined #media
20:11:43 [silvia]
TOPIC 2: JS API for in-band and manifests
20:11:50 [janina]
scribe: janina
20:12:03 [silvia]
20:12:12 [silvia]
20:12:13 [janina]
ec: we want to end up with the same api for in and out of band media--eventually
20:13:12 [silvia]
interface HTMLMediaElement : HTMLElement {
20:13:12 [silvia]
20:13:12 [silvia]
// audio tracks
20:13:12 [silvia]
readonly attribute unsigned long audioTrackCount;
20:13:13 [silvia]
readonly attribute DOMString audioTrackLanguage[];
20:13:14 [silvia]
attribute unsigned long currentAudioTrack;
20:13:17 [silvia]
20:13:55 [silvia]
20:14:10 [silvia]
interface MediaTrack {
20:14:10 [silvia]
readonly attribute DOMString kind;
20:14:10 [silvia]
readonly attribute DOMString label;
20:14:10 [silvia]
readonly attribute DOMString language;
20:14:10 [silvia]
const unsigned short OFF = 0;
20:14:13 [silvia]
const unsigned short HIDDEN = 1;
20:14:15 [silvia]
const unsigned short SHOWING = 2;
20:14:17 [silvia]
attribute unsigned short mode;
20:14:21 [silvia]
20:14:23 [silvia]
interface HTMLMediaElement : HTMLElement {
20:14:25 [silvia]
20:14:27 [silvia]
readonly attribute TextTrack[] textTracks;
20:14:28 [silvia]
readonly attribute MediaTrack[] mediaTracks;
20:14:30 [silvia]
20:16:09 [janina]
fo: what does the author do with kind?
20:16:26 [janina]
ec: should be a defined list to select from
20:16:53 [janina]
sp: everything we make available we need also api for custom controls
20:18:27 [janina]
discussion of referring to external tracks inband
20:18:53 [janina]
mpeg4 supports this via manifest
20:19:36 [janina]
sp: api has onload and onerr ... keep? drop?
20:20:03 [janina]
fo: keep symetry between in and out of band -- to support authoring flexibility
20:20:52 [janina]
ec: authors shouldn't have to care
20:21:07 [silvia]
basing discussion on second interface pasted above since it is more generic
20:21:39 [silvia]
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 [silvia]
in particular events should be identical so registration would not depend on the type of track
20:22:14 [silvia]
add back in...
20:22:15 [silvia]
20:22:16 [silvia]
20:22:28 [silvia]
const unsigned short = 0;
20:22:28 [silvia]
const unsigned short = 1;
20:22:28 [silvia]
const unsigned short = 2;
20:22:28 [silvia]
const unsigned short = 3;
20:22:31 [silvia]
readonly attribute unsigned short;
20:22:51 [silvia]
readyState may not mean much and my be a reflection of the state from the main resource
20:23:17 [silvia]
we have complications on cues:
20:23:18 [silvia]
readonly attribute;
20:23:18 [silvia]
readonly attribute;
20:23:18 [silvia]
20:24:39 [silvia]
is there a need for audio and video for these?
20:25:54 [silvia]
ec: we may need to subclass similar to how HTMLMediaElement works
20:26:03 [Zakim]
20:26:35 [silvia]
20:27:53 [silvia]
FO: deriving from base class makes sense, but what if we have data that is different to audio/video/text?
20:28:03 [silvia]
… won't we restrict ourselves too much?
20:28:14 [silvia]
EC: no, because we'll have mediatrack and that is more generic
20:28:24 [silvia]
interface HTMLMediaElement : HTMLElement {
20:28:25 [silvia]
20:28:25 [silvia]
 readonly attribute TextTrack[] textTracks;
20:28:25 [silvia]
 readonly attribute MediaTrack[] mediaTracks;
20:28:25 [silvia]
20:29:08 [janina]
Thanks, Michael. Is your phone OK?
20:29:21 [silvia]
SP: does it make more sense to have audioTracks and videoTracks?
20:29:36 [silvia]
EC: we don't want a proliferation of attributes … so I'm torn
20:30:16 [silvia]
EC: I think I prefer mediaTracks, because the script can figure out what type it is
20:30:36 [silvia]
SP: do we need a mime type or something?
20:31:16 [silvia]
EC: we introduced mediaType into proposal 8
20:32:00 [Zakim]
20:32:06 [silvia]
FO: I'm concerned we need different interfaces for audio and video
20:32:14 [silvia]
EC: yes, I think we need more attributes
20:32:20 [Zakim]
20:32:55 [silvia]
EC: we have two levels - media is the parent, audio, video and text derive from that
20:34:28 [silvia]
SP: hmm, do we then even need textTracks?
20:34:44 [silvia]
EC: no, we only need tracks then as an attribute in HTMLMediaElement
20:35:54 [silvia]
silvia has joined #media
20:35:54 [eric_carlson]
eric_carlson has joined #media
20:36:00 [MikeSmith]
MikeSmith has joined #media
20:36:07 [silvia]
SP: are we replicating attributes from the parent?
20:36:12 [MichaelC_]
MichaelC_ has joined #media
20:36:14 [silvia]
EC: no we should not, only some select ones
20:36:19 [Sean]
Sean has joined #media
20:36:20 [JF]
JF has joined #media
20:37:18 [silvia]
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]
lwatson has joined #media
20:37:38 [silvia]
.. or playbackrate
20:38:29 [silvia]
SH: what about src and currentSrc - would you be able to change them?
20:38:42 [silvia]
SP: for in-band it doesn't make sense
20:38:54 [silvia]
EC: for out-of-band we shouldn't make this available either
20:38:58 [richardschwerdtfe]
richardschwerdtfe has joined #media
20:39:23 [silvia]
FO: we need src to provide the original url
20:39:45 [silvia]
EC: it should be read-only
20:40:24 [silvia]
.. can't be read-only because you need to set it once
20:41:06 [silvia]
FO: why would you ever want to change the src of a media track?
20:41:14 [silvia]
EC: for example if you have a playlist
20:41:37 [silvia]
SP: you could completely remove the video element and re-build the whole thing
20:42:03 [silvia]
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 [silvia]
.. the ready state is available to both
20:42:56 [dboudreau]
dboudreau has joined #media
20:43:06 [silvia]
FO: we should make the track elements behave a lot like the media elements
20:45:50 [silvia]
agreement in general that we should have only one tracks attribute to add to the HTMLMediaElement
20:46:43 [janina]
janina has joined #media
20:46:50 [janina]
zakim, who's here?
20:46:50 [Zakim]
On the phone I see FtF, ??P3
20:46:51 [silvia]
SH: we need a separate way to set volume - need an audioTrack element
20:46:52 [Zakim]
On IRC I see janina, dboudreau, richardschwerdtfe, lwatson, JF, Sean, MichaelC, MikeSmith, silvia, frankolivier, mkobayas, oedipus, Zakim, RRSAgent
20:47:06 [silvia]
SP: what to do with video that also has an audio track?
20:47:14 [janina]
zakim, drop ??P3
20:47:14 [Zakim]
??P3 is being disconnected
20:47:16 [Zakim]
20:47:37 [Zakim]
20:47:52 [silvia]
EC: I don't think we should offer flow control at the track level
20:48:09 [silvia]
SH: would audio and video behave independently?
20:48:11 [janina]
zakim, ??p3 is F2F
20:48:11 [Zakim]
+F2F; got it
20:48:20 [janina]
zakim, who's on the phone?
20:48:20 [Zakim]
On the phone I see FtF, F2F
20:48:45 [janina]
zakim, drop FtF
20:48:45 [Zakim]
FtF is being disconnected
20:48:46 [Zakim]
20:50:20 [silvia]
EC: they should behave like there are two separate tracks
20:51:06 [eric_carlson]
eric_carlson has joined #media
20:51:46 [silvia]
interface MediaTrack {
20:51:47 [silvia]
readonly attribute DOMString;
20:51:47 [silvia]
readonly attribute DOMString;
20:51:47 [silvia]
readonly attribute DOMString;
20:51:50 [silvia]
const unsigned short = 0;
20:51:53 [silvia]
const unsigned short = 1;
20:51:55 [silvia]
const unsigned short = 2;
20:51:59 [silvia]
const unsigned short = 3;
20:52:02 [silvia]
readonly attribute unsigned short;
20:52:05 [silvia]
20:52:08 [silvia]
20:52:13 [silvia]
const unsigned short = 0;
20:52:16 [silvia]
const unsigned short = 1;
20:52:19 [silvia]
const unsigned short = 2;
20:52:22 [silvia]
attribute unsigned short;
20:52:25 [silvia]
[these are the attributes from the TextTrack that make general sense]
20:54:39 [silvia]
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 [silvia]
we need to add the @default attribute in the IDL:
20:57:02 [silvia]
readonly attribute DOMString default;
20:59:18 [silvia]
SH: I would prefer to be able to turn multiple on by default
20:59:40 [Sean]
have a showing attribute, rahter than a default
21:01:38 [silvia]
mode="showing" is more flexible
21:04:15 [silvia]
SH: what we don't want is two attributes that influence the same IDL
21:05:40 [janina]
zakim, who's on the phone?
21:05:40 [Zakim]
On the phone I see F2F
21:07:08 [silvia]
SH: there is no way from markup to say "download this but don't show it"
21:07:28 [lwatson]
lwatson has joined #media
21:07:33 [silvia]
FO: you need two concepts
21:07:59 [silvia]
… for mobile devices you need to have some sort of preload attribute that says "don't download this data at all"
21:08:25 [silvia]
… similarly you need to have the concept of requiring download of all the necessary track data before you allow playbac
21:08:26 [silvia]
21:09:12 [silvia]
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 [frankolivier]
21:10:44 [silvia]
SP: do we need information on whether we want alternative data to be loaded before going to HAVE_METADATA?
21:11:08 [silvia]
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 [silvia]
s/HIDDEN or/
21:11:43 [silvia]
… HIDDEN would allow starting playback while in the background loading the resource
21:11:56 [silvia]
s/HIDDEN or//
21:12:56 [silvia]
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 [silvia]
EC: what if I just want one as the default?
21:13:43 [silvia]
SP: then just set the attribute on that to @mode="showing"
21:14:12 [silvia]
EC: what if the UA need something else as the default from settings - would it overwrite what the author set?
21:14:53 [silvia]
FO: are you allowed as the UA to overwrite the value of @mode ?
21:17:00 [silvia]
FO: same thing with the windows-wide setting for showing captions/subtitles
21:17:53 [silvia]
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 [silvia]
SH: we then also need an event onchangemode
21:19:58 [silvia]
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 [silvia]
SP: the 80% use case I think is that we have only one track of one type active at one time
21:23:28 [silvia]
… if we need more than one track active, we can always use script
21:24:37 [silvia]
FO: we can do multiple tracks through multiple @mode attributes already
21:24:59 [silvia]
SH: what if the UA can just turn on additional ones
21:25:19 [silvia]
.. then have to turn them off
21:25:47 [silvia]
SP: not really useful
21:26:57 [silvia]
JF: what if we have english and french tracks, but my UA settings are spanish
21:27:28 [silvia]
FO: if there is no track in my language, then nothing should be shown
21:27:38 [silvia]
EC: or the first track - it needs to be predictable
21:31:43 [silvia]
FO: only overwrite an author's settings if nothing is specified
21:35:56 [silvia]
EC: leave the default choice to the browser
21:37:47 [silvia]
FO: what if the controls attribute it set and the menu is showing - what then?
21:37:54 [silvia]
EC: right-click menu
21:38:29 [silvia]
FO: if the @controls is not set, is the user allowed to fiddle with the state of the media resource
21:38:47 [silvia]
EC: I think yes, and all the basic controls should be available in the context menu
21:39:10 [silvia]
FO: so my custom controls need to deal with it?
21:41:25 [silvia]
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 [silvia]
SP: no, I wouldn't provide @mode at all
21:42:42 [silvia]
EC: for audio and video it makes a big difference if hidden also means preloading
21:43:54 [silvia]
FO: so, there is no @default attribute, but the default mode on all tracks is OFF
22:05:40 [silvia]
SP: do we need src, currentSrc and load() next?
22:05:41 [silvia]
22:07:04 [silvia]
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 [silvia]
… load() is just used to reset state of the video element
22:08:36 [frankolivier]
frankolivier has joined #media
22:09:25 [silvia]
… nothing will happen until the script has gone back to idle
22:10:13 [silvia]
… resetting only needs to be available on main video
22:10:32 [silvia]
… but you can change the src
22:10:51 [silvia]
SH: video.load() should filter down to any tracks
22:10:53 [JF]
JF has joined #media
22:11:46 [silvia]
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 [silvia]
… so that is additional work to what is in the general media element load algorithm
22:13:20 [silvia]
… it is similar to setting startOffset on main resource, but that element should only exist on the main resource
22:13:24 [silvia]
22:14:52 [lwatson]
lwatson has joined #media
22:14:53 [JF]
JF has joined #media
22:14:59 [silvia]
SH: do we need canPlayType() on tracks?
22:15:21 [silvia]
EC: semantically it is only required by the media element
22:15:54 [silvia]
SP: it's only required to find out what codecs your browser supports
22:16:15 [silvia]
… so the same applies to tracks as well as <video>
22:16:30 [silvia]
EC: is it going to be legal to as canPlayType on text tracks?
22:17:23 [silvia]
22:17:45 [silvia]
EC: it would make sense to ask canPlayType on caption formats
22:17:54 [silvia]
… but you should not be able to set the video.src to it
22:21:25 [silvia]
SP: we already have that problem that we don't have a function that allows us finding out what text formats are supported
22:21:39 [silvia]
SH: maybe we should introduce a canPlayTrackType() function
22:23:10 [silvia]
FO: what about in-band tracks and their formats?
22:23:37 [silvia]
EC: some do, some don't use
22:23:57 [silvia]
… the question about formats for in-band is not particularly useful
22:24:08 [silvia]
… so mime types are sufficient
22:24:24 [silvia]
… I don't think there's a mime types for 3GPP captions for example
22:24:54 [silvia]
… and if there was, they would be in the codecs parameter
22:25:46 [silvia]
SP: are we all in agreement that we need canPlayTrackType()
22:25:53 [silvia]
… not sure I can come up with something more elegant...
22:27:02 [silvia]
SP: do we need networkState?
22:27:09 [silvia]
… not on in-band tracks
22:27:15 [silvia]
… but external ones...?
22:28:28 [silvia]
SP: am almost not sure if we need networkState for video from a script POV
22:28:49 [silvia]
EC: we argued a lot whether it makes sense to have both states, readyState and networkState .. it really is one state machine only
22:32:05 [silvia]
.. I don't really want to add readyState to tracks
22:32:50 [silvia]
SP: let's leave it out for now, until somebody can make a good case for it
22:33:39 [silvia]
SP: what about error
22:33:49 [silvia]
SH: we need some kind of error states
22:33:57 [silvia]
EC: we need exactly the same error staes
22:34:16 [silvia]
… need to add it to MediaTrackElement
22:34:23 [silvia]
readonly attribute;
22:36:43 [silvia]
interface HTMLMediaTrack {
22:36:43 [silvia]
  readonly attribute DOMString kind;
22:36:43 [silvia]
 readonly attribute DOMString label;
22:36:43 [silvia]
 readonly attribute DOMString language;
22:36:44 [silvia]
 const unsigned short NONE = 0;
22:36:46 [silvia]
 const unsigned short LOADING = 1;
22:36:48 [silvia]
 const unsigned short LOADED = 2;
22:36:50 [silvia]
 const unsigned short ERROR = 3;
22:36:52 [silvia]
 readonly attribute unsigned short readyState;
22:36:54 [silvia]
          attribute Function onload;
22:36:55 [silvia]
          attribute Function onerror;
22:37:00 [silvia]
 const unsigned short OFF = 0;
22:37:01 [silvia]
 const unsigned short HIDDEN = 1;
22:37:04 [silvia]
 const unsigned short SHOWING = 2;
22:37:05 [silvia]
          attribute unsigned short mode;
22:40:16 [silvia]
interface MediaTrack {
22:40:16 [silvia]
readonly attribute DOMString kind;
22:40:16 [silvia]
readonly attribute DOMString label;
22:40:16 [silvia]
readonly attribute DOMString language;
22:40:17 [silvia]
const unsigned short NONE = 0;
22:40:19 [silvia]
const unsigned short LOADING = 1;
22:40:22 [silvia]
const unsigned short LOADED = 2;
22:40:23 [silvia]
const unsigned short ERROR = 3;
22:40:25 [silvia]
readonly attribute unsigned short readyState;
22:40:27 [silvia]
attribute Function onload;
22:40:29 [silvia]
attribute Function onerror;
22:40:33 [silvia]
const unsigned short OFF = 0;
22:40:34 [silvia]
const unsigned short INACTICE = 1;
22:40:37 [silvia]
const unsigned short ACTIVE = 2;
22:40:38 [silvia]
attribute unsigned short mode;
22:40:40 [silvia]
attribute DOMString src;
22:40:43 [silvia]
readonly attribute DOMString currentSrc;
22:40:45 [silvia]
readonly attribute MediaError error;
22:40:47 [silvia]
22:40:50 [silvia]
.. UH… just use the bottom half of that
22:42:38 [silvia]
SH: which events then do we have?
22:43:27 [Sean]
DOM EventListener interface
22:43:45 [Sean]
var eventHandlers = {}; this.addEventListener = function (type, handler, bubble) { // Register an event handler of a specific event type on the EventTarget. } this.removeEventListener = function (type, handler) { //Removes an event listener from the EventTarget. - } this.dispatchEvent = function (event) { //Dispatch an event to this EventTarget.
22:44:10 [Sean]
s/var eventHandlers = {};//
22:44:48 [silvia]
EC: do we want an event interface for onload()?
22:45:33 [lwatson_]
lwatson_ has joined #media
22:45:35 [silvia]
… what do you do with an inband track? it will never fire onload
22:46:57 [silvia]
SH: we need two kinds of errors - a partial error and a full error
22:47:18 [lwatson]
lwatson has joined #media
22:48:11 [silvia]
… you need to be able to indicate that a set of cues has not been properly parsed for example
22:48:29 [silvia]
SP: but we don't have a visual presentation of such errors in HTML either, e.g. when a piece of HTML is not properly loaded
22:48:38 [silvia]
SH: if an image cannot load, something is shown
22:48:44 [silvia]
SP: yeah, but not for html text
22:49:06 [silvia]
SH: if something goes wrong, you may want to load a different resource...
22:49:43 [silvia]
EC: the MediaError state has these states: includes ERROR
22:50:18 [lwatson_]
lwatson_ has joined #media
22:50:24 [silvia]
SP: so partial and full errors would turn up in the error state
22:51:06 [silvia]
22:51:13 [silvia]
EC: agreed
22:51:17 [silvia]
EC: back to events
22:52:47 [silvia]
… if we are going to support streamed captions, we cannot require playback to be paused because captions haven't loaded
22:53:15 [silvia]
SP: what about just loading the first resource
22:53:19 [silvia]
EC: what if it comes really late
22:53:29 [silvia]
SP: what about just HAVE_METADATA related state?
22:53:36 [silvia]
EC: yes, that seems to make sense
22:54:32 [silvia]
SP: so let's replace the readyState with the proper ones from the media element:
22:55:17 [silvia]
const unsigned short HAVE_NOTHING = 0;
22:55:17 [silvia]
const unsigned short HAVE_METADATA = 1;
22:55:17 [silvia]
const unsigned short HAVE_CURRENT_DATA = 2;
22:55:17 [silvia]
const unsigned short HAVE_FUTURE_DATA = 3;
22:55:17 [silvia]
const unsigned short HAVE_ENOUGH_DATA = 4;
22:55:18 [silvia]
readonly attribute unsigned short readyState;
22:57:08 [silvia]
SH: make sure we change the parsing algorithm for TextTrack to throw an error on faulty parsing
22:59:08 [silvia]
MK: if a track element has an error, would that affect the parent?
22:59:32 [silvia]
FO: probably not because the tracks have their own error states
22:59:40 [silvia]
SP: would it stop playing?
22:59:55 [silvia]
FO: no, the main resource should continue playing
23:02:16 [silvia]
SH: we have an onerror event to allow the author to deal with error situations
23:02:24 [silvia]
EC: but we cannot have an onload event
23:03:30 [silvia]
SH: we need an information that the track is proceeding
23:04:46 [silvia]
SP: I think that unless we get an onerror on a track, we can assume that all tracks continue loading
23:04:56 [silvia]
.. and can be played
23:05:27 [silvia]
EC: yes, for progress and timeupdate events
23:06:08 [silvia]
SH: if we get an error from a track, then we know something stopped working
23:06:23 [silvia]
… we can register a single event handler for all tracks
23:06:47 [silvia]
EC: the target shows where it was raised from
23:09:31 [silvia1]
silvia1 has joined #media
23:09:40 [MikeSmith]
MikeSmith has joined #media
23:09:54 [Sean_]
Sean_ has joined #media
23:10:38 [eric_carlson]
eric_carlson has joined #media
23:10:52 [MichaelC]
MichaelC has joined #media
23:11:24 [silvia1]
SP: what do we do when external audio and video tracks stop buffering or fail half-way through
23:12:08 [silvia1]
… e.g. if audio descriptions suddenly fail - would we want to have the main audio continue playing?
23:13:05 [silvia1]
JS: I would want to react differently depending on the situation
23:13:23 [silvia1]
… with friends, it should probably continue
23:13:32 [silvia1]
… with a silent movie, probably not
23:14:05 [silvia1]
… if it continued playing, I might assume that something is wrong with my audio device
23:14:13 [silvia1]
EC: might be best to leave that problem to the UA to solve
23:15:51 [mkobayas]
23:16:13 [silvia1]
interface textTrack : mediaTrack {
23:16:55 [silvia1]
readonly attribute TextTrackCuesList cues; readonly attribute;
23:16:55 [silvia1]
23:18:20 [silvia1]
interface textTrack : mediaTrack {
23:18:20 [silvia1]
readonly attribute TextTrackCuesList cues;
23:18:20 [silvia1]
 readonly attribute TextTrackCueList activeCues;
23:18:20 [silvia1]
          attribute Function oncuechange;
23:18:20 [silvia1]
23:18:30 [silvia1]
(just look at the last half of this)
23:18:59 [silvia1]
FO: why do we need to fire events for every cue?
23:20:35 [silvia1]
… oncuechange is not helpful - it's better to know whether something has been added / removed
23:21:05 [silvia1]
… we could just add the cues that are going away and are starting to the cuechange handler
23:23:09 [silvia1]
FO: would inactive tracks still fire events?
23:24:04 [silvia1]
EC: if you want to render them yourself, then you don't want them showing, so what do you do?
23:25:14 [silvia1]
SH: what is the getCueAsText returning? should it return just innterHTML?
23:25:25 [silvia1]
23:25:55 [silvia1]
.. since that function already exists, maybe we just need getAsHTML and can then put getInnterText on it
23:26:09 [silvia1]
EC: but you may not be able to get on the text at all
23:26:16 [silvia1]
… it can display
23:26:32 [silvia1]
SH: the rules say that if the captions aren't coming from the same domain, you cannot display them at all
23:27:06 [silvia1]
EC: if it's only text, it shouldn't be a problem
23:27:35 [silvia1]
SH: because it throws all the events etc, so only turning off getCueAsHTML and getCueAsText is not sufficient
23:27:41 [silvia1]
SP: CORS is supposed to solve this
23:28:16 [eric_carlson]
eric_carlson has joined #media
23:29:05 [silvia1]
EC: there is some information leakage with video, but you can't get any video data out of it
23:29:17 [silvia1]
… it works for video, so it should probably work on captions
23:29:27 [silvia1]
FO: we need to have this discussion in the HTML WG
23:29:35 [silvia1]
… it's a security discussion
23:30:17 [silvia1]
23:30:34 [silvia1]
23:39:46 [silvia1]
SH: you want onenter and onexit on the track, not on the cue, because you only want one handler to deal with the changes
23:40:19 [silvia1]
SH: why don't we have cues show up in the DOM?
23:41:31 [silvia1]
SP: I think it had something to do with security
23:42:12 [silvia1]
… but seeing as it is same-site content only, I don't know how that makes sense any more
23:43:23 [silvia1]
FO: it would also be possible to load them all into the DOM and then you can just make them visible when the time is right
23:43:32 [silvia1]
EC: wouldn't work for streamed catpions
23:43:54 [silvia1]
FO: we like the idea of having captions in the DOM
23:54:36 [mkobayas]
mkobayas has joined #media
23:58:56 [richardschwerdtfe]
richardschwerdtfe has joined #media
23:58:58 [JF]
JF has joined #media
00:06:04 [mkobayas]
mkobayas has left #media
00:06:11 [mkobayas]
mkobayas has joined #media
00:09:08 [silvia1]
[group has a discussion on #whatwg about why putting cues directly into the DOM is a bad idea]
00:10:38 [silvia1]
00:18:43 [Zakim]
00:18:44 [Zakim]
WAI_(A11YAF2F)11:30AM has ended
00:18:44 [Zakim]
Attendees were FtF, F2F
00:39:08 [Zakim]
Zakim has left #media
00:39:13 [RRSAgent]
I see no action items