See also: IRC log
Clarke: action from co-chairs to
draft statement on HTML5 LC bugs
... Kaz, status?
Kaz: Discussed with co-chairs. But in the end, we won't need comments sent by the IG since comments have already been sent.
Clarke: so we won't send an endorsement from the Media Pipeline TF?
Kaz: for HTML5 LC bugs,
endorsement is not really needed. What's important is to fill
out the bugs, which was done.
... I'll point the interest of the IG to Paul Cotton.
Clarke: so the result is that anyone here should be encouraged to send comments themselves.
Jan: If I wanted to get further clarification about proposed solutions, should I take it in bugzilla or discuss it here?
<Clarke> So those interested in the outcome of LC bugs should join the LC discussion directly to make specific comments
Clarke: That was 13333. Been escalated as an issue, I think.
Jan: The solution makes reference to objects. I'd like to work with what they initiated. I don't want to be detrimental to the comment.
Kaz: There is likely to be a second LC period. The working group will accept further comments.
Jan: your proposal is to go to the mailing-list directly.
Kaz: not 100% sure about the procedure. I can investigate if you prefer.
<Clarke> Kaz to check on preferred procedure to address "closed" bug
<scribe> ACTION: kaz to check on exact procedure to submit comments to HTML5 LC bugs [recorded in http://www.w3.org/2011/08/11-webtv-minutes.html#action01]
<trackbot> Created ACTION-70 - Check on exact procedure to submit comments to HTML5 LC bugs [on Kazuyuki Ashimura - due 2011-08-18].
<kaz> issue-18?
<trackbot> ISSUE-18 -- Video tag support of MPEG2-TS -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/18
<inserted> VideoTagSupportMpeg2-ts
Jan: [scribe missed beginning of
discussion because of echo]
... Trying to map what was done in Open IPTV Forum. It's
possible that most of it is covered.
... One issue was identified.
... The ability to retrieve which components are available and
if there's any change to components that are available.
... Right now, you only get "change" events on the default
track, but not on others.
... That's highlighted in point number 1.
... The second one is fairly well covered. I don't think there
is any issue.
... The third one, there are two aspects. What you set the
system preferences, and the playout preferences.
... [example given with subtitles]
... There may need to be something to be done here. If we thing
it's at the system level, we may not need to do anything in the
browser.
... Fourth point: I haven't been able to map precisely what's
available. Something to do here, I think.
... Fifth point is similar to fourth point.
... Sixth point is that I'd like to explore something similar
to the video tag in SVG.
... so that you don't need to embed an HTML video tag. What can
we expect W3C to do here?
[Bob seems muted]
Jan: I made a reference to the
DAE spec where we have an appendix that explained what was
available. Now the video tag is more complete, should be
updated.
... Shall we first conclude ISSUE-18?
Bob: I had a couple of comments
and questions. In general, we take a deep look at requirements
at American requirements for multi-video and multi-audio. I
think they are covered, now. Don't have any problem with a use
case even if it's covered.
... I filed 3 bugs for HTML5, and one of the bugs covers what
you describe.
Jan: missed that, could you reply on the mailing-list and send a pointer?
Bob: yes, will do that. Last point is that I don't know what it means for the video tag to be in SVG, could you clarify?
Jan: I'd like to have the same
semantics for SVG as well.
... SVG has its own video tag, but it's not the same.
Bob: Oh, I see.
... From a use case perspective, if you want to use SVG as part
of the UI, you could use that separately, right?
Jan: yes, but then you're
embedding, not using SVG natively.
... Maybe W3C has a plan to merge both video.
Bob: the more global issue is
we've identified, at CableLabs, that it would be valuable to
take advantage of new media rendering capabilities in the user
agent, but have all the API and infrastructure provided by the
video tag.
... One example is content protection via a plugin
mechanism.
... You'd still have support for tracks, etc.
... It sounds that this concept could also apply to SVG.
Jan: I'm wondering how
transparent we can make this.
... There might be an advantage to make the video tag a child
of your object in order to capture what is not covered by the
video tag.
... I'm just exploring this possibility, to see if it might
work with browser manufacturers.
... I suspect it might be preferable for them.
... I haven't checked, so that's why I'm still in exploring
phase.
Bob: OK. One other thing the
group could be interested in. A comment from Philipp from Opera
where he references an experience in the WhatWG about streaming
and Peer2Peer media
... It introduces a local stream that can be associated with a
media element such as a video tag.
<Clarke> Bob to send out link to MediaStream object
Bob: Will provide a pointer.
Jan: Can we allocate time in the third workshop to do some brainstorming about it?
Jan: For the technical discussion, useful to exchange ideas.
<Zakim> kaz, you wanted to ask if we want to meet with SVG WG during TPAC2011 and to
Kaz: We'd like you to send a
position paper around that to hold a panel session around
that.
... Preparing agenda with OC right now, good topic.
... Also, why don't we hold a joint meeting with SVG during
TPAC?
... SVG will hold a F2F meeting there, so might be useful to
hold a joint meeting.
Clarke: could be interesting. By that time, we might have a better idea to bring the two tags together.
Kaz: there is no plan to hold a
Web and TV IG F2F meeting during TPAC since we have one in
September, but it still makes sense to hold joint meetings with
other groups.
... TPAC is last week of October.
fd: 1) Situation on different video tags in SVG and HTML well known in W3C but I'm not aware of a concrete plan to merge the two right now, so recommend keeping a use case that requires that. 2. To exchange ideas on technical topics, the workshop is one place, but the F2F IG that follows the workshop might be even better, because there will be fewer people and people will be around the table. The workshop is Sep. 19-20, the F2F IG is Sep. 21-22 workshop.
<kaz> [ kaz will send out an announcement about the f2f and ask you all for agenda idea, etc. ]
Clarke: the table we have for discussion today may address some of your needs, but we should address Duncan's point before.
Duncan: lots of discussion on the mailing-list.
<kaz> issue-37?
<trackbot> ISSUE-37 -- View-Port support for Video Window -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/37
Duncan: One way is to have a
canvas tag around a video tag and then do all sorts of
tricks.
... There was one comment that is was not dynamic though.
... Also use of SVG was mentioned linked trough a metadata
track.
... Standardization possible around use of metadata to
incorporate SVG to manipulate video.
<kaz> ViewPort-Supprot
Duncan: The background for merging SVG and HTML video tags was completely different, but some overlap.
<Clarke> Issue 34 is adaptive video. the e-mails used the wrong issue number
<kaz> ok :)
Duncan: wondering if anyone has any other thoughts on this.
Bob: Continuing to refer to it as
"viewport" issue is good. There seems to be general agreement
that the use case is valid.
... That's my personal feeling.
Clarke: In one of the email
discussions, it's linked to ISSUE-34, so maybe we need to
recapture that as part of ISSUE-37
... What I would really like is if we could test some of these
and see if they really work so that we can clean up whether
that's covered or whether it generates new requirements.
Duncan: yes, we'll try.
Bob: Two of the subcases have
predominated. One if to extend map to video. The other is to
take a subportion of a mosaic and manipulate as you could with
the full video stream.
... Perhaps worth documenting.
Jan: When referring to SVG, it seems that we embed, shouldn't we highlight that it would be better not to have to embed SVG in your HTML?
Duncan: which way do you embed?
Jan: well, the point is not to
embed, but do it natively
... and then it's supported more natively instead of working
around it.
Duncan: sounds like a separate issue in itself, probably worth calling for a separate issue.
francois: SVG in HTML5 is not really "embedding" anymore. It's included.
<Clarke> Table under discussion: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions#Other_Discussions
Bob: We've taken a look at
various events and application data are carried in media
transport.
... looking at different common formats used throughout the
world.
... [going through the table]
... e.g. Play an advertisement in the middle of a stream,
ability to have a descriptive audio track designed for the
visually-impaired.
... could be added as an audio description track. Closed
captions for similar purpose.
... This data is transported in-band.
... It's up to the user-agent to expose this data in different
ways to the video tag.
... The first three would be application data that comes
in-band.
... They would be acted on only by script.
... The others would be exposed as additional audio/text
tracks. They are handled well, I think, described in some
details in the HTML5 spec.
... The columns list the different media transports we may have
to deal with.
... There is MPEG TS2, MPEG4 ISOBMFF, the DASH work, or other
manifest files.
... The question is: how do the user agent recognizes a
secondary audio track or a DTV trigger as part of application
data?
... There are a number of aspects that need to be defined. One
is for the various transport formats how the data is carried
upon.
... Then there's what formats need to be supported, and third
issue is how you expose the information in HTML5 to the
application.
... The HTML5 alludes to that when they talk about in-band
tracks.
... This work needs to be done.
... One of the questions raised: how should this be considered
within the context of W3C?
... We had some discussion with Ian Hickson and WhatWG. He
seems to be supportive of this.
Jan: Do you expect to, as an
exercise, maybe create an annex to a W3C document, make a
mapping?
... I would think it's a good implementation guide.
Bob: I don't have much insight as
to how this should be specified in a W3C spec. We would welcome
working with W3C in a broader context to work on this.
... We'd be very supportive of that if W3C wants to take this
on.
Kaz: Several options. HTML WG is
one of them. Another group named MMI working group, working on
EMMA, which includes several different types with strong
support for extensions.
... Another possibility could be creating a Business group or a
community group for the discussion on the mapping.
... The venue is important, but the discussion on the possible
mapping is much more important.
... Do you think it makes sense to continue discussion in the
Media Pipeline TF?
... Other options will take more time.
Bob: We can do that. Over the
lifetime of this TF, we are going to fill out some of the
cells.
... As we get more details, I would like to come back to the TF
and share more insights as to what needs to be done.
Clarke: we'll try to update the table as we move along.
Francois: I'd like to emphasize that one of the main goals of the task forces and the IG in general is to discover topics that would require standardization. That table sounds like a very valuable topic. In parallel to continuing the discussion in the task force to refine the scope, note you can already start drafting a charter proposal for a potential working group if you already have support for this idea. Kaz and I would be happy to help you, there.
Bob: Yes, we'd looking for
broader input than the group of companies that started this
effort. To the point of starting working on a standard, we do
need the technical work of this table to be reflected in a
standard.
... There are a variety of places where this could be
done.
... Both discussions are good to help making this standardized.
IETF could be an option as well, for instance.
Clarke: good. Running out of time, so suggest to close the call.
[Call adjourned]