Media Pipeline Task Force (Web and TV IG) Teleconference

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.

-> Slides deck for TPAC meeting with HTML WG

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 MarkW message for more info.

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 MarkW message for more info.