- From: Francois Daoust <fd@w3.org>
- Date: Thu, 27 Oct 2011 18:24:34 +0200
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi,
The minutes of the Media Pipeline Task Force weekly teleconference are available at:
http://www.w3.org/2011/10/27-webtv-minutes.html
... and copied as raw text below.
The task force reviewed the slides deck that will be presented to the HTML WG during TPAC next week (and, with fewer details, during the technical plenary day).
Thanks,
Francois.
-----
Media Pipeline Task Force (Web and TV IG) Teleconference
27 Oct 2011
[2]Agenda
[2] http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_27th_October_2011
See also: [3]IRC log
[3] http://www.w3.org/2011/10/27-webtv-irc
Attendees
Present
Clarke, Kaz, Duncan, Francois, Eric, Aizu, Mark_Vickers,
Mark_Watson, Franck, Jan, Bob
Regrets
Chair
Clarke
Scribe
Francois
Contents
* [4]Topics
1. [5]TPAC slides
2. [6]R1
3. [7]R3
4. [8]R7
5. [9]R8
6. [10]R10
7. [11]R11
8. [12]Summary slides
* [13]Summary of Action Items
_________________________________________________________
TPAC slides
Clarke: only thing on the agenda is to look at stuff we're planning
for TPAC.
... Planning to present the requirements we'll discuss in the
plenary meeting and we'll go through in more detailed with the HTML
WG.
... I prepared some slides, want to get your feedback for those
... Make sure that we're providing reasonable requests for the HTML
WG.
... I sent that out to the mailing-list a little earlier.
-> [14]Slides deck for TPAC meeting with HTML WG
[14] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Oct/0057.html
R1
Clarke: The requirements that we accepted, I reworded them in some
cases to clarify, that's something I'd like you to review.
... Looking at R1.
... entitled "combined main + description audio track".
... [going through the slide]
... In blue at the bottom, I list suggested changes.
... Any feedback on slide 2 R1?
Clarke: The deck we're looking at right now is intended for the HTML
group. I'll drop details for the plenary discussion.
Juhani: How do these requirements relate to the requirements doc?
Some differences.
Clarke: I haven't updated the online document on the Wiki yet. I'll
do that this week, and I'll send out a message to the mailing-list
once down.
... I wanted to ensure we agreed on the message first.
mav: It should be the same wording used in both cases.
R3
Clarke: Moving to slide 3 R3 "Handling of In-band Tracks"
... [going through the slide]
... 3 bugs relevant to this. One is 13358 which has already been
accepted, two others 13359 and 14492.
... Handles cases when tracks come and go and change.
Jan: note last bug is not currently set as a Last Call bug.
... I'm having major issues trying to raise this as LC1 bug,
although connection with 13358.
[discussions on exchanges with chairs and Ian Hickson about that]
Jan: We need to highlight that somehow that it should be an LC1 bug.
... Typically that 14492 provides more detailed examples of 13358.
... I don't know how easy it will be, because it takes some time to
understand the scenario.
Clarke: Two possible fronts: 1) is working through comments as you
did. 2) is to make our case clear to the HTML WG, making sure they
understand what we're trying to achieve.
Jan: Do we need to give them some context so that they understand
technologies we want to integrate (HbbTV and so on).
Clarke: Adding an example there would be good.
mav: I think I can prepare some text
MarkW: I think going into technical details of our technologies to
the HTML WG might not get the expected result.
... Need to extract general parameters and requirements
independently of underlying technology.
... I think that people are reluctant to requirements that say "we
have x in techno y, so need it here".
Clarke: yes, very good idea. As long as you drive from user
experience, it makes more sense.
mav: I think this issue overlaps with WAI group with which we have a
meeting scheduled, I think.
MarkW: It may be that we'll want to re-open the old bug instead of
trying to get the new one as a LC1.
Jan: that's what I'm trying to do.
... Perhaps support from other supports might be good.
Note added after the call
It seems that Bug 14492 will be an LC1 after all, provided nobody
objects to it before next Tuesday. See [15]MarkW message for more
info.
[15] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Oct/0059.html
Clarke: good idea.
... [going through the rest of the slide]
Jan: Do we have a reference to the mapping spec?
bob: I'll put something up.
... Good to have URIs, typically on W3C servers under the MPTF work.
Clarke: one of the questions is how to pursue this work in W3C.
... [going through suggested changes]
... Any other comment on this slide?
Kaz: Given that 13358 was LC1 and accepted, maybe we can simply
remove LC1 from here on the slide.
Clarke: I'm a little hesitant to do that, because I want to point
out that we need those bugs to be addressed.
Jan: perhaps highlight the fact that they are not LC1 bugs yet.
Kaz: exactly. Perhaps underline the words.
<kaz> ... I mean removing "LC1" just from 14492
Clarke: I can underline 14492 to put forward that status not settled
yet.
R7
Clarke: Moving on to slide 4 R7. "Adaptive Bit Rate Parameters"
... [going through slide]
... Two related things: one is ISSUE-179 and LC1 bug 13625. In that
case, we're suggesting an attribute to pass that information.
Jan: You're missing a bug, I think, bug 13333.
Clarke: right, it should be there.
mav: we can have the bug or the issue. The reason I put the issue is
that the bug was escalated as an issue.
MarkW: when raising this in the HTML WG, there's an underlying
assumption that [missed point]. I don't think that's accepted at all
in W3C.
Clarke: isn't this what the object element does?
MarkW: no, the object element allows you to embed plug-ins.
... Clearly, there's an architectural disconnect.
... From an HTML WG perspective, there isn't any room for non
defined parameters and behaviors to live under elements defined in
HTML5.
Clarke: we need the problem solved. We have some idea, but solving
the problem is left to the working group.
... As long as we're presenting it here.
Jan: should we refer to different technologies that will use it?
MarkW: yes, that will explain the differences of thinking.
... We have to find some common middle-way on that.
Jan: maybe a second slide on architecture.
Clarke: do you want to create a second slide, Jan?
MarkW: Not entirely sure what's the best way to do it.
mav: If there are specific parameters that are needed, then they
should be standardized. I agree with that. The following bug that
proposes parameters for adaptive bit rate control is an answer to
that.
... Bug 13333 is very much about whether the video is pluggable or
not.
... Essentially, in the big picture, a lot of comments can be
summarized by: "there are things done in HTML4 by plug-ins that are
not in the HTML5 video element, so we're trying to move them in a
standards area".
... The object element is extensible with the addition of custom
code. The video element is not.
MarkW: moving from the current model to one where elements provide
extensibility is a huge and tough move.
... That's not something that they've discussed and considered.
... I think even if the parameters are on the video elements, if the
user agent supports the codec, there's no need for parameters. The
only use case for parameters is if you have plug-ins, as far as I
can tell.
mav: that may be true. The overall point I want to make here is that
it needs to be solved in the group. We want to expose a set of
parameters and play content seamlessly.
... This could be solved with the two bugs listed here, or through
other means.
Clarke: I'll add things to that slide based on discussions.
R8
Clarke: [going through slide]
... Related to ISSUE-179, but we probably do not need any change to
the video element, only to extend existing error codes.
... with ones that are specific to adaptive bit rate.
Jan: I would suggest that in changes, we're not only suggesting
error code, but also statistics.
... Maybe add extensibility of error codes and [missed]
MarkW: Can people in the group suggest some more concrete idea of
what these would be?
Clarke: Percentage of packet drops for instance
MarkW: I mean taking examples from existing implementations and put
them in.
Jan: I think I sent once a list of potential candidates.
Clarke: could you send it again, and I'll try to add it here?
Jan: will try.
R10
Clarke: similar as R7 but for content protection.
... Whatever changes I make to R7 slide, I'll make them here as
well.
R11
Clarke: same here, equivalent to R8.
... I think there are some suggestions.
Jan: Is it ok to add references to Open IPTV Forum specs when I give
examples?
Clarke: I think that it could be ok.
... Please send comments to me, I'll be the editor.
Summary slides
Clarke: last two slides are summaries.
... It shows resolution of ISSUE-179 would enable many requirements,
so good to show.
... Last slide summarizes the requests
??2: second bullet, R8 and R10 should be R7 and R10.
Clarke: good point.
Juhani: discussing with my colleagues, I think editorial improvement
would be to add links so that people can just click to get more
details.
Clarke: Adding the links would be good, yes.
... Other questions, comments?
... Any question specific to TPAC?
... Hoping that several of you can be with us during the HTML WG
meeting.
Jan: question about observers
Clarke: you need to register online.
Jan: done that.
Kaz: seats will be served following a First Come First Served rule.
Jan: I am already registered. There is still a standby even when you
register.
??1: I received confirmation emails from the various groups I asked
for
... even today.
Jan: haven't received acceptance notifications from all groups.
Kaz: can send a reminder to different groups chairs.
... let me know about which groups you'd like to hear from.
Jan: Could you put something on the Wiki about current schedule?
Kaz: Yes, I'll put this on the wiki and send a message to the
mailing-list.
Clarke: anything else we need to discuss?
Jan: Please comment on bug 14492 so that I don't appear to be the
only one pushing for it.
mav: yes, I suggest people go read all bugs in detail and add
comments as needed.
Note added after the call
It seems that Bug 14492 will be an LC1 after all, provided nobody
objects to it before next Tuesday. See [16]MarkW message for more
info.
[16] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Oct/0059.html
Summary of Action Items
[End of minutes]
Received on Thursday, 27 October 2011 16:25:07 UTC