HTML WG face to face, Santa Clara - video session -- 06 Nov 2009

<scribe> scribenick: timeless

<scribe> scribe: timeless

Video

Silvia: ...

Video Breakout Session

Silvia: What we're going to do is go through this document from top to bottom

<plh> http://esw.w3.org/topic/HTML/MultimediaAccessibilty/TPACSession#head-791e3205ef073305f38ecb15244f822545c6c051

Silvia: <http://bit.ly/3sHMcT>
... let's start with baseline codecs

Carlos Cardona:

Carlos Cardona: ... I was wondering what the intention was

Silvia: I think the right person is hiding

Dave Singer: from apple

scribe: I think the general consensus is we want a guaranteed fallback
... unfortunately it's been a one on one discussion
... we want something that's easy to deploy
... for mobile terminals
... we want to address royalty free IPR
... generally, we're looking for something a little boring
... i'm continuing to work with other companies
... and trying to convince them that there's value working with us
... i've seen movement
... but it's slow
... sam asked, what process do we propose to how we're going to resolve this issue
... it's really frustrating
... i'm as frustrated as everyone else in this room
... given the source fallback capability
... i think we're looking for the final fallback
... you can put your preferred format
... but then you can put the fallback codec

plh: is it worth spending our time on a codec
... that we know is only going to satisfy some portion of the audience

dsinger: I think it's very important
... and there's a large portion of the world who is just wants something that works

Adrian Bateman: microsoft

scribe: I agree with everything David said
... the only thing i question is whether it's feasible to describe a process

Adrian Bateman: ...

scribe: that goes about doing this
... given that it really involves one to one discussion
... the only way to have a process is when you have multiple options

Silvia: ...
... to talk about a process
... would be putting back a call for proposals
... for things which satisfy all requirements
... i'm not sure it's really workable
... i'm sure that behind closed doors, there's another ... that's being proposed

plh: about process
... i'm not going to create a group
... unless i know people will join the group
... and if the group of people who would join the group
... is different from the group of people in html5
... then i'm not sure if there's a point
... the amount of resources to create an open call
... from the w3c is very significant
... including closing it

syliva: hearing that
... it would have to come out of the html5 group?

David: I think you don't want to issue a question for which you don't want to hear the answer

Carlos: ...
... if we do find a codec, moving forward
... do we still intend to keep the <source> element that descends from <video> ?

silvia: Yes
... I think baseline codecs are likely to be lower level

Hixie: forget codec

<dsinger> people interested in this topic and who feel that they can help are welcome to contact me...

Hixie: we still need things for multiple resolutions, black and white, flicker/no flicker

<dsinger> or indeed work on it separately

silvia: ...
... next point
... Q-ranges
... about the requirements around these
... and how we satisfy the requirements around them
... i've heard the requirements are around multiple cases

[ UPS arrives ]

David: who can give a summary about cue ranges?

Hixie: I don't know that there's much to summarize
... we had things in the spec
... there were concerned raised
... i think it was safer to remove it

<frankolivier> cue ranges, not cue ranges

Hixie: i think there were other parts of the api

s/q-ranges/cue ranges/g

Silvia: ...
... i think there were questions about if it was sufficient

Hixie: for pausing it was (?) sufficient
... apart from that was the main reason was for time updates
... say you have a slide show
... and you're trying to keep the relevant slide showing
... and when you enter/exit a range you show/hide the slide
... it works for both backwards and forwards progression
... with cue ranges you get this for free
... if you use time elements, you have to do this yourself

David: ...

dsinger: one of the nice thing about cue ranges is that it's sensitive to processing power
... i'm not a fan of time updates
... i'm much more a fan of cue ranges as they're much more friendly to processing power

silvia: what was the problem?

dsinger: it wasn't implemented

Frank: Microsoft

Eric Carlson: ...

scribe: david made a proposal to the mailinglist
... a way to do cue ranges
... declaratively (it until then was javascript only)
... to the DOM
... the feedback that we got from the implementors at Opera
... was that they were also unhappy about a JavaScript only API as well

Silvia: was the proposal with attributes?

eric_carlson: no, it was with events, as opposed to callbacks

Hixie: when we use captions as opposed to in file captions
... there are two ways to do captions, in the video file, or completely separate with javascript
... the solution to this going forward, is supporting out of file captions
... and to have an API that binds to that

silvia: maybe we can leave cue ranges here
... or does anyone else have anything else on them?

[ topic: Accessibility Video/Audio, media ]

silvia: I've got the list of related bugs here

[ screen, url, scribe doesn't have ]

silvia: we had a big discussion sunday

Accessibility Video/Audio, media

silvia: i'll call on john Foliot to give this

John: on sunday everyone had an opportunity to say what they were looking for
... we didn't get an opportunity to work things out
... there's an issue about time line
... in terms of controlling time line
... the time stamping format needs to be further discussed
... at this point, we need to move forward with discussion

silvia: i think what we need to do here
... is move to a list of requirements
... people are encouraged to start experimenting and propose solutions

dsinger: what we're trying to do here is get things on the wiki

<Laura> Multimedia Accessibility <Audio> <Video>

dsinger: there were two actions I took away

<Laura> http://esw.w3.org/topic/HTML/MultimediaAccessibilty/TPACSession#head-791e3205ef073305f38ecb15244f822545c6c051

dsinger: one was using media queries to select a source
... there seemed to be general consensus on this
... the css wg seemed to agree
... they suggested working with the PFWG WG
... that's an action item
... to look at the accessibility
... to have the accessibility in the media files
... the other item
... was looking at non type fallback
... e.g. warning about "could induce seizures"
... i'm going to work with Ian on working on what to put into the spec
... i suspect this might relate to what do you do when you print a page on a media surface that doesn't support things
... the third item
... was there was general consensus that we should use ARIA to link to a transcript
... James Craig said he would take an action to come up with text on that
... what I want to do is come up with a best practices
... there's stuff you should be aware of in CSS and ARIA
... so that someone interested can go to a single place
... because right now it's spread across multiple specifications

silvia: if i could go on from there to the more general accessibility task force
... within the accessibility task force, we would create a general document about video accessibility

John: ...
... the task force hasn't had enough time to figure out logistics
... I haven't had a discussion within the task force
... we will probably have a space within the wiki

silvia: Janina(?)

Janina: there's an html-wg, we're operating under this for IPR
... we should have a process and resources set up fairly quickly

Glen Goldstein: from MTV networks

scribe: before we move on to video ...
... we want to have a way to suggest multiple audio tracks
... for things like secondary audio programming

Janina: similar to an earlier discussion about ipv6
... there's both a problem and an opportunity
... about how you provide access to types of content
... there's a lot of opportunity
... i'm also excited about this
... as people mentioned, you don't need to be in a wheel chair to appreciate a curb cut

Glen: is there enough support in the spec
... to support sources from multiple files

eric_carlson: no, there is not
... it's technically very hard

Doug: that problem is addressed by SMIL

silvia: though people on sunday said it isn't really solved by SMIL
... it's just declared by SMIL
... synchronizing files from multiple servers
... is hard

Glen: at least there's a start

Janina: you can't guarantee success, but you can provide an opportunity

Doug: Time containers let you try to solve that
... solving it at a network level is another issue

Silvia: if we rely on a separate file, then SMIL ....
... if the description of how to compose the media experience
... is in a separate file
... then it's a further indirection

doug: you could simply bring the syntax into HTML, as we did for SVG

Glen: there's a similar discussion, as with multi rate streaming
... the same theme will keep coming up

Silvia: coming from the point of view
... there is a solution for doing multi track
... with multiple controls
... with multiple time lines
... which has been standardized by the w3c
... not looking at the actual requirements
... and just trying to push it in
... there have been multiple people saying that SMIL is too compicated
... and that we shouldn't push it into HTML

eric_carlson: not if you want multiple implementations in reasonable time

Silvia: the question is whether it could be a profile of SMIL
... there are all kinds of issues relating to that
... who specifies it
... or do we look at it from the requirements

Doug: sync based v. event based timing
... are already being put into Mozilla, Safari and Opera
... are being done for SVG

eric_carlson: having an implementation of those that works for non time based media
... is much less challenging than making it work for time based media
... maintaining sync

Doug: there is an animation timeline
... is that different from the media timeline?

eric_carlson: yes

silvia: moving on in the agenda
... looking at it from what other work
... what are other requirements for solving accessibility
... was caption and subtitle support
... and how to do that with SMIL
... i encourage people who want to solve it with SMIL to propose a solution
... maybe it's possible to do it straight out of HTML
... I encourage people to make proposals
... People are probably aware of the itext(?) specification
... I think we all agree at the need for a declarative syntax for linking external files into html

Cynthia Shelley: Microsoft

scribe: I was wondering if that includes audio description and sign language

Silvia: I think that's later in our agenda
... then there is the option with the declarative syntax
... in the itext element, there's a reference to an external file
... that doesn't get loaded into the DOM
... but provides a javascript API

<frankolivier> itext, not itext

<kford> We should think about whether accessibility settings should be called accessibility. Many segments of the population wh

Silvia: but we could provide a way to load it into the DOM

<frankolivier> itext spec: https://wiki.mozilla.org/Accessibility/HTML5_captions

<kford> who could benefit don't think in terms of accessibility.

[thanks to frank for dropping the link]

silvia: an action item to me is to put stuff relating to itext into the wiki
... i have multiple versions, and i'll describe it into the wiki

frankolivier: re itext
... you're describing all of the external bits of a file into an html document
... this is similar to what we do for an actual video itself
... so if you're a user agent, you don't have to open the file to get the info

<Laura> User Roles and Cases

<Laura> http://esw.w3.org/topic/HTML/MultimediaAccessibilty#head-c5d0ca60246df93bceaca431df464168bfa0e0af

frankolivier: this is similar to how video is handled

[ silvia shows an example of an itext document ]

[ silvia describes it ]

silvia: ... charsets ...
... what formats should we support for captions and subtitles
... what formats are important
... beyond the tree i've already listed
... requirements, and reasons for choosing each one
... we'll get into a similar discussion as with baseline formats for codecs

Glen: timed text in general
... DFXP is one possible profile
... SMPTE ...
... motion picture television ...
... SMPTE is one possible, it's compatible
... the broadcast industry is looking to embrace this
... Shawn Hayes from microsoft is leading the effort
... he says it has minor differences from DFXP
... there's internal work at this point
... and i think that will put the major domestic broadcasters into one format

plh: there's a minor time issue

silvia: i don't think we'll have completely solved our caption issues by the end of the year

frankolivier: the other thing about DFXP is
... they support picture overlays
... existing binary, like flash, support DFXP already today

silvia: i look at these issues from two perspectives
... from the professional community
... and also from the web community
... people out there, exchanging data
... it might be that within html we might propose implementing two
... SRT ...
... the free tools covert SRT

glenn: there's no reason not to support it

silvia: exactly, it's trivial to implement
... SRT as a baseline format
... I have nothing against DFXP
... if there are enough people to write tools
... it might be the right thing for a professional level
... for things like Color and Italics
... these are things that SRT does not support
... there's also been a suggestion of SMIL TEXT
... I don't know how SMIL TEXT differs from the other

glenn: I would say W3 timed text support

silvia: when I say DFXP, I mean W3 timed text

glenn: ... and however many profiles come out of it
... it's a subset of timed text
... it will recreate enough to recreate timed captioning

silvia: open captions should be a thing of the past
... and we don't want to talk about it anymore
... i'm surprised we don't have a more lively discussion about baseline text
... even DFXP is comparatively is much simpler compared to video

Matt May: ...

scribe: I'll say that SRT is basically a subset of Timed Text
... it satisfies the basic requirements
... it has what to do when a caption enters and exits
... I wouldn't recommend that SRT be the lingua franca
... I wouldn't object to it existing
... in the flash implementation there are a number of SRT solutions

eric_carlson: I'm not sure it makes sense to mandate SRT
... It's common enough, but underspecified
... someone would have to write a spec for SRT

silvia: there's actually a proper web site for it
... there isn't a spec
... what we really need is a registered mime type
... i don't think srt would be a major issue

dsinger: I think it would be a great thing that XIPH take over

silvia: so, Apple ...

frankolivier: and Microsoft

silvia: are here

frankolivier: I would say that SRT and DFXP are .., things that could be supported

Hixie: Google ...
... as we support OGG and MPEG
... will go for a superset

glenn: there's also text as image
... where all you've got is a rasterized format

silvia: that's the bitmap overlay that frank mentioned

plh: i don't think the accessibility will be appeased

dsinger: if your choice is nothing at all or open captions

Matt May (adobe):

Matt May (adobe): ...

scribe: i'll give an example
... that's what's in most DVDs
... it doesn't work for translations

glenn: the good thing, is that this won't be burned in

Janina: the accessibility will be that it's not specified in such a way that you can easily cheat

Matt: the motion picture industry will like to do that

Janina: no disagreement about supporting as many languages as we can

silvia: there was general agreement that bitmap captions that can be turned off
... that can be turned on and off, are better than no text
... there was violent agreement

Jim Allen: ...

scribe: general question, is the bitmap a single standard format?

s/Synthia/Cynthia/g

scribe: is there only one format?

<Hixie> correction to my statement above: i was just saying google would _probably_ support the union of the formats supported by the other vendors

scribe: so we have one tool

glenn: I believe it's BMP

silvia: something that would be supported by the browser and easily overlayed
... while we're talking about the browser
... i think we should also talk about security issues
... there are issues about html accepting markup external from the web page

eric_carlson: i'm not sure that's so much of an issue
... the security issue we'll have to deal with at some point
... is the case when we have a media file with captions from inside the file
... which is loaded from a different domain than the script
... and we won't be able to provide access to the information
... something could then override the information

Hixie: the issue I'm worried about
... is being able to link to subtitles from another domain

<foolip> is there a realtime log where I can catch up what I've missed?

RRSAgent: make minutes

scribe: but that's solvable by restricting domain and then using CORS to reenable it

eric_carlson: that's solvable
... but we'll have to apply cross domain rules
... there's possible that meta data in the page or loaded from a different domain
... is accessible from the script, but not the data that was in the video
... script won't have access to metadata within the media file
... the browser will want to ....render meta data
... but it will have to have rules, which wins, meta data in the file
... or meta data outside the file
... meta data tagged with the same language

Hixie: a video file with English captions, and an external file with English captions

eric_carlson: and when there's script, and only one of them is script accessible to the script

silvia: you can display the video, but not the meta data

eric_carlson: or useragent can render the metadata
... but it can't provide it to script

silvia: we had this discussion earlier
... the question about which wins
... is a rights issue
... when someone publishes a video with a subtitle track
... they expect it to be shown
... when someone else associated track
... from a legal issue
... but a user might want to use the other one

Janina: but a user might prefer that other one

Hixie: and we can't actually stop it, because javascript could overwrite it

doug: ... alternate sources of media
... i know we are loath to specify user interface elements

silvia: you're saying that the user could choose

doug: we pick one
... but the UA provides a way to indicate alternates

eric_carlson: that will work as long as author specifies the built in controls are available

Jim Allen: cochair User Agent WG

scribe: we have specific success criteria dealing with the user being informed about multiple forms of a file
... as opposed to a default
... now whether that ever is implemented in a player
... standalone players like quicktime do this

<foolip> 403 Sorry, Insufficient Access Privileges on http://www.w3.org/2009/11/06-video-minutes.html (yes, I'm logged in)

scribe: within a browser, the user agent should expose this, and the user should be able to pick an override

[silvia shows a demo ]

Matt: ...
... as far as copyright goes
... that's not a concern for the working group
... until there's a concrete example
... my greatest concern is that a content provider that makes an internal thing where the caption attribute is null
... and that locks out external captions

Doug: [nothing to say]

dsinger: what do we need to specify so it's possible for a user to link their own choices
... to a video
... do we need to specify it
... the other question, is what do we do about language accessibility
... mostly punted by html

<MikeSmith> foolip, please try again

<foolip> MikeSmith: thanks, work fine now

RRSAgent: make minutes

Display Activation Issues with Caption Subtitles

silvia: we have a need to manage display activation, somehow
... there is a need for people to be able to specify whether they want captions automatically
... that could be done by adding user preferences in the browser
... that could mean that a user could automatically see subtitles by default
... i see general nodding

Jim: UA Accessibility requirements already have that

Matt: Legal requirements by next year will mandate that

Silvia: languages
... browser vendors already have a setting for default language preferences
... we can reuse that to specify preferred language / subtitles
... is this an acceptable approach

Adrian: ...
... Microsoft ...
... having the browser setting as a sensible default
... is a fine idea

<foolip> no, browser language settings are next to useless

Adrian: but we know that lots of people have it set incorrectly
... so we know that isn't sufficient
... I don't have a specific proposal
... web sites that deal with content available in multiple languages
... they typically start with the language provided as a default
... but they typically have a menu that lets the user override it
... and then they use a cookie to store the user's expressed choice
... we know that lots of people use a language install of a browser which doesn't match their preferred content language

<foolip> If we want to use browser language, use just one resource with http content negotiation. otherwise, let the page choose the default

Adrian: they might have English as a browser, but not their preferred content language

<foolip> i.e. I agree with Adrian

<foolip> no, I'm in Sweden

Adrian: provided the user agent lets the user choose

<foolip> maybe commenting via IRC is going to be messy

[ we're trying to fix foolip 's access ]

[ action to MikeSmith to solve ]

Cynthia: ...

<foolip> It's already been fixed, no problem

Cynthia: relying on the web content authors to solve this won't work
... we need the browsers to provide a solution

silvia: the web page author will have the possibility to provide an alternative

Janina: we discovered there's an api for basic controls
... accessibility will look at this
... we have a concern about a standard way to do basic controls

<SCain> +1 to that

Janina: as opposed to a hand wave
... you might want controls on multiple monitors / splitting video output from control display

glenn: MTV
... we've encountered places where regional locations are important
... we went with ISO lang_region
... we chose es_MX
... we detect we're your coming from
... and we try to do the right thing

silvia: language technologies being the main part
... but also regional variants need to be considered

frankolivier: we still need to add ...

<JF> timeless can post that link of the demo?

<JF> K

frankolivier: we have some way to add itext elements for the user

<MikeSmith> note that foolip is Philip Jägenstedt, who is working on the video implementation in Opera

frankolivier: we have no way to show the user that a video track as caption information

RRSAgent: make minutes

- DRAFT -

HTML WG face to face, Santa Clara - video session

06 Nov 2009

Attendees

Contents

Video

Video Breakout Session

Accessibility Video/Audio, media

Display Activation Issues with Caption Subtitles

Summary of Action Items

Scribe.perl diagnostic output