See also: IRC log
<JF> shall we start?
<JF> anyone volunteer to scribe?
<scribe> scribe: allanj
jf: issues from JB, needs statement
<silvia> is there a phone number to call?
<JF> 1 617 761 6200 (USA)
jb: We need a requirements
document for work in the media area.
... sees there are some requirements. are they vetted? are they
comprehensive?
... concern about technical and accessibility representation.
wants WAI to have participation. requirements would help
getting the right folks
jf: sylvia has done work for
Mozilla, and put lots of information on the wiki
... are we missing something? who else should we contact?
<silvia> https://wiki.mozilla.org/Accessibility/Video_a11y_requirements
<silvia> http://wiki.whatwg.org/wiki/Timed_tracks
jb: impression from months back, was concerned about vetting and input, if they have been addressed, I'm Ok
sylvia: documents posted have had
lots of input.
... requirements captions, transcript, audio description
<JF> http://www.w3.org/html/wg/wiki/MultimediaAccessibility
sylvia: basic requirements are
not a problem. all agree. Issues are how to realize the
requirements in practice on the web.
... doesn't feel need for additional requirements. Please
review, comment as necessary.
... standstill, at the moment is the technical
implementation
... one issue is synchronization of multiple video types
(multiple angles, etc)
jb: 0there is a role for the requirements document., will review the pieces. wonders why not a whole.
js: may need a resolution that are requirements are at URI.
<silvia> this is our media accessibility requirements document: http://www.w3.org/WAI/PF/HTML/wiki/Multimedia_Q%26A
js: perhaps wiki page. that way we have a starting point, and the problems we solved
jf: jb talked about other groups to review. do we have to chase after other groups, or say here is the info - review at will.
jb: looks like lots of groups have been approached. would like to know who, so I can use my contacts to forward the work of the group. need a single requirements. will commit to review these documents.
jf: in minutes of this meeting
are lots of URI. could combine all requirements into one
... there are several technologies referencing similar
things
... smile, etc. lots of overlap, hard to look 5 years in
future.
... getting a sense of scale and timeline for a deliverable has
not yet been done
... /s/smile/smil
dick: have been pointing out
challenges. getting responses of 'too far down path a'
... long term vs short term. want to know constraints
... guidance on input needed,
sylvia: 'too far down the
path'... only the implemented video element in html5.
... that is fixed. trying to make that accessible (captions,
audio description)
... smil is out of scope.
... still a need to develop a larger picture, need to solve the
short term problems
jf: having a requirements
document may help focus efforts.
... smil and daisy have legitimate concerns.
... video is being used now. how do we solve that problem.
js: daisy should be on call
kenny: yes daisy is here.
jb: requirements would be good
jf: would help set timelines also
?? if something violate a longterm need but meets a shortterm need, how do we resolve.
dickbolterman: activation of embedded content tracks, this api meets this need.
resolution: the media sub team recommends the multitrack API at @@
db: also related to item 3
... main concern - current vido and audo objects have multiple
functions.
... content, selection, and time containers
... all are being integrated into one object
... tried to integrate SMIL processing model with
'switch'
... proble: introduction of time contaiiner. secheulde
independent objects.
... we are not just choosing from among available tracks
... we are gathering different tracks from different
places
... also links in captions
... pairing audio w/ video, should be same as pairing captions
w/ video, or audio description w/ video
jf: technology is browse window.
they are reaching the point that they can't do everything that
a standalone player can
... do we focus on browsers as they are now, or what they can
do in the future
db: absolutely browser window.
reasonable that captions can be place on, above, below, etc the
video. we are adopting old TV model. TV now is moving away from
old model
... extended functionality can work in the current object.
sylvia: disagree with this model.
mentioned video with time containers. in html5 video is only
audio and video with one timeline. slideshows are a different
thing.
... source selection with only 1 time line.
... switch element is out of html5
... tracks for captions and audio descriptions are not
independent time ines.
... they are dependent on the one AV timeline. this is a big
difference.
... need to solve accessibility first. other proposals are
after this.
db: is one selection with one
timeline can agree.
... if fetching a track comes in late then what happens.
... need to match time if things are coming from separate
files.
... if you don't want this, then must define captions as
embeded within video.
... could have many track, karoke, etc. they are real problems.
and here now.
sylvia: map all timelines to the
base video timeline. multiple files will not break this simple
algorithm
... soucing from different servers. if things don't arrive at
the same time, too bad. can't hold the video.
db: if you need the captions to get the information, then throwing them out is not a good plan.
sylvia: video won't start until captions are there.
db: if you have small device with long video. need to support the simple soulution first, but address the complex one in the future.
eric: media engine composed media
files on demand.
... need to define specific rules about timing. all media must
be there before it starts.
... not sure how this is different from what we have now.
db: is inside the video element the proper place to do the time composition.
eric: must agree with sylvia. already have this situation. media file is time container. and can reference external media
db: if you have embedding media, the rendering engine...
eric: not the case. the mdia
samples may come from external file.
... there is one master timeline in the container. controled by
the browser
db: hyperlinks in a text file, to link to other objects or navigate within a media. so the subbordinate textfile is controlling the parent object
sylvia: it doesn't matter. just points to an offset in the video
db: if in same file and point 20 sec into the future......
sh: that is not how timetext works.
db: author has to know what video encoding is being use.
sh: whichever is playing controls the clock. can sample forward or backward
Discussion of intricacies of timedtext and smil timing model
sh: what does a hyperlink actually do in a caption file. none of it has been defined.
jf: do we need to bring up
hyperlinks in the requirements documents
... srt, dxfp, and styling of textfiles.
... accessibility, changing style is need.
<gfreed> just for the record, i think we do need to look at hyperlinking when the time is appropriate.
jf: can't do this with srt. then
do we look a timedtext or dxfp
... but browsers say it is too complex.
db: need to keep options
limited.
... text association models have different semantics
?? correction, srt will use the browser default style sheet, modifiable by the user.
jf: what about the author having some control?
eric: basic srt does not have this (styling by author)
jf: styling could allow placement of captions, above, below, bubbles, etc.
eric: need a solution to allow
the author to style. otherwise, not going to fly.
... problem with dxfp is how stylse is expressed.
sh: xsfo has css properties through xsl.
gf: one model about styling on
captions is repurposing captions from other media.
... may have colors fonts, etc so they can transfer to the
web.
sylvia: dxfp problems, no support for ruby and i18n.
sh: not ruby markup but can display ruby text.
jf: srt doesn't support ruby either
sylvia: srt is simplistic
solution. determining the requirements on whatwg
... ... what format exists to support stylihg requirement.
currently, none.
jf: yikes!
... requiring ruby is a good thing.
sylvia: ian is mashingup and
format to meet requirements. need feedback and comments.
... it will likely be the format speced
jf: this covers item 4 also
... time is ticking. htmwg is looking to solve or they will be
closed.
... need to get a requirements document, need to focus on that,
and try to set timeline
... and get started on the work
... html5 video is already on the web.
jb: number if a11y issues. media
is an important issue. TF chairs wre working with html5 to move
things along.
... coordination calls ongoing.
... this is a complicated area. discussion today reinforces the
need for requirements.
... it comes up in every topic. reaching consensus on
requirements is needed
... need one document
... htmlwg chairs understand that media needs to be done right,
and will take some time.
js: underscore doing it 'right', timeline must be realistic.
regular telecons. have scheduled 10.
scribe: post one set of
requirements. set short term goals, then see where we are
... need to get to a consensus
jf: need a single concensed requirements document. short term and long term. will create soon.
<scribe> ACTION: jf to create requirements a11y media accessibility document [recorded in http://www.w3.org/2010/04/28-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-27 - Create requirements a11y media accessibility document [on John Foliot - due 2010-05-05].
UNKNOWN_SPEAKER: will ahve conference call for next few weeks, then reassess frequency of calls
rssagent, make minutes
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: allanj Inferring ScribeNick: AllanJ Default Present: John_Foliot, Eric, Judy, +31.65.159.aaaa, Jim_Allan, Geoff_Freed, Janina_Sajka, +61.2.801.2.aabb, +61.3.986.4.aacc, +61.2.801.2.aadd Present: John_Foliot Eric Judy +31.65.159.aaaa Jim_Allan Geoff_Freed Janina_Sajka +61.2.801.2.aabb +61.3.986.4.aacc +61.2.801.2.aadd WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 28 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/28-html-a11y-minutes.html People with action items: jf[End of scribe.perl diagnostic output]