Media Pipeline Task Force Teleconference (Web and TV Interest Group)

<Clarke> requirements: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements

R1. Timed Text Cue Mapping

Clarke: took a first shot at updates to prepare TPAC
... If you scroll down to the actual requirements list, that's where I put things.
... I'll go down through it. Please speak up if you disagree.
... Timed Text Cue Mapping, I think, is covered by LC bug #13359.
... Makes it easier for the track to be repeatedly processed.
... Anyone has issues that think are not addressed by this bug?
... If I don't get comments or objections, I'll just assume you agree and move on. Of course, you can respond to the list later on.
... My assertion then is that Requirement 1 doesn't require us to add any change request to HTML5 that isn't already covered by the aforementioned bug.

R2. Key Metadata Types

Clarke: Next requirement is Key Metadata Types.
... I think it's the same as R1, covered by the same LC bug #13359.
... Any disagreement?

[none heard]

R3. Midstream Modification of Track Elements

Clarke: Requirement 3, Midstream modification of track element. I think that bug #13358 covers it, possibly with the addition Jan submitted this week.
... Suggestion that keeping the same list might help to manage indexes in that list, to allow for some persistence and consistency.
... The bug suggests that we get notified when a track leaves.
... One thing that is mentioned in the requirement which I'm not sure is covered by the bug is to know when a track "changes", that is goes away and comes back.
... If "changes" means something else, I'm not sure what the bug suggests is an appropriate way to deal with the requirement.

Jan: The proposal to make a separate bug was from Ian Hickson.
... Assuming it gets the same priority as the previous one, we could agree to add a comment to the second bug that clarifies.
... Here's an example. Audio characteristics might change as you're going from stereo to surround, I would assume that it is a completely separate track that is being added.
... Not the same one as before.

Clarke: So you're suggesting that it would be a new track?

Jan: Yes, even though both are "English", different characteristics, so different tracks.
... I would like to explore the possibility to detect characteristic changes.

Clarke: If you have a continuous stream, every time a program changes, you still have basic stereo English track. Would you add a new track for each new program? Or would you reuse the same stereo track?

Jan: If I'm not mistaken, the same is being reused.
... What could be useful is a hint as to which track has changed.

Clarke: Let's say you have program segments, advertising, five ads and then program segments. During that process, the list goes rather large with items that are rather dormant. Is it adequately dealt with with the last call bug or do we need something else?

Jan: I might be concerned about creating a long list that gets larger for months, but your interaction with the platform, you'd like to stick to English. The application does not need to do anything if it does not affect the default.
... I have not raised the "length" in the bug.

Clarke: There might be some sort of refresh mechanism where the user agent might say "My list is getting too long, let's refresh it".

Jan: It's a static list, not a dynamic one.

Clarke: I agree that the bug you posted addresses that.
... Another question is [@missed]?
... Let's say I have a program interrupted by several commercials, you could maintain that list, as you have commercial interruptions, you could remove but keep them in the background, and then reuse them.

Jan: I can see the problem, I'm not 100% sure that it's addressed here.
... should I add some more details or concerns along the terms of content using more than one signal cable?

Clarke: If we raise a concern, I would like us to raise a solution to it.
... such as "If the list grows, this can be dealt with the following..."
... Some mechanism. That's what I would prefer.

Jan: I may need to double check internally about what happens to different content, like going to a commercial.
... Temporary removal during commercial.
... The UA will know, I think.

Clarke: I'm going to suggest that, for R3, we think it's covered but would like you, Jan, to investigate whether it is really the case.

Jan: OK, I'll dig it up and send things to the mailing-list.

Clarke: Other comments on that one?

[none heard]

R4, R7, R9. Parameters for Content Authorization, Adaptive Bit Rate, Security and Digital Rights Management

Clarke: Based on discussions from last week, I tried to parallelize R4/R5, R7/R8 and R9/R10.
... My suggestion is that there are basically two gaps identified here:
... 1. identify parameters
... 2. provide feedback, either errors or info that needs to be fed back to the user agent.
... My suggestion is that in the first case, this is covered by #13333.
... It hasn't been officially denied, but we have some push to reconsider it.
... I think if we can specify the parameters, we can deal with the authorization/bitrate/security issues and do that in a way that is generic.
... My recommendation is that this can be covered by bug #13333 if we can have it reconsidered.
... Any comment?

[none heard]

Clarke: We may want to have some agreement on parameter names. If you have some arbitrary adapting streaming file, or some arbitrary authorization system, there's a common way to specify the identity that needs to be authorized
... and maybe some common way to specify the credentials that need to be passed.
... Perhaps not critical to reach that agreement, but probably useful.
... Do you think that there are precedents that we could follow?
... Any opinions?

John?: I follow your reasoning. I'm going to look at bug #13333 to understand where it is. Not familiar with the process here. What you say makes sense.

Clarke: There is some feeling that the video tag gives you some advantages over the object tag. You can specify parameters on objects but not on video. That sounds like a natural feature.
... Based on that, I want to suggest that we take the same course for requirements 7 and 10.
... Any objection to consolidate down those requirements into bug #13333

[Clarke updating Mark on on-going discussions]

MarkW: I made some comments on bug #13359, we'll see how they get responded to.

Clarke: Then, we're suggesting that bug #13333 be re-considered. We think we can cover content authorization, adaptive bit rate, and security parameters with that.

<kaz_> [ this should be a good candidate topic for the joint meeting with the HTML WG, shouldn't it? ]

R5, R8, R10. Feedback loop for Content Authorization, Adaptive Bit Rate, Security and Digital Rights Management

Clarke: I think that we agree that there is a gap here.
... Feedback such as you dropped x% of your last packets for instance.
... Authorization may be something that has to do with parental control. I'm not opposed to the idea that it is the same thing as buying license [@scribe unsure he got that right]

MarkW: Not sure that there is a way to change the list of attributes and parameters without changing HTML5.

Clarke: yes.

MarkW: [scribe missed Mark's comment]

Clarke: Two categories. 1. you've asked to do something, and you're told "no". You want to know why. 2. you get a hint that something changed and you may want to modify how you're processing it.
... I'm not sure what's the best way to handle that. It seems better to have a specific feedback rather than a generic error mechanism.
... Any ideas?
... Let's say you want to play a video and it turns out that the file you're requesting to play is not available. How is that dealt with?

MarkW: quite limited on the media element. I think there are only 3-4 errors available. Network error for instance.
... You get an error on the MediaElement but not very helpful.

<franck> <video> error codes: http://www.w3.org/TR/html5/video.html#error-codes

MarkW: One rationale heard is that there's not a lot that a Web page could do with it, apart from saying "sorry, I could not play the video".
... It's a little hard to come up with a rationale.
... I guess that's what the HTML WG might say.

Clarke: I see your point. It's not clear what you would do with the more precise error.

MarkW: Yes, it's not clear what the Web page can do when playback is not authorized. It's not authorized, period.

Clarke: The challenge is that we either need to come up with scenarios that make this useful in the context outside of the user agent, or we can drop these requirements.

MarkW: I was just talking about authorization, actually.

Clarke: I understand, but if there's a case when we think that it would be useful to get feedback, then that would help all 3 of them.
... Any use case that would make this pretty much useful?

MarkW: Specifically, with network errors, you can really improve feedback and record what the error was to improve things on the backend.
... Also, from a remote monitoring perspective, it's useful to know when the bitrate changes.

Clarke: ok, that works for adaptive bit rate.

MarkW: With DRM, [@missed]

Clarke: Let me issue a generic action here to see if you can come up with feedback and events for example that would be generic to any of these requirements that we could specifically want to ask for.
... This would help us determine whether there's a gap.
... Last thing I urge you is that we don't really have a requirement for use case described in last call bug #13357.
... This is where we suggest a new kind (e.g. translation + description).
... It would be useful to add this as a requirement here to be complete on what we'd like to change.
... Any discussion on that?
... There's possibly one gap identified here related to feedback that may not be covered by existing last call bugs.
... That will make our request pretty concise.
... If there's no discussion, I'll try to capture what we discussed today and make that clear in the doc.

Kaz: Wanted to mention the possible joint meeting during TPAC. One with HTML and the other with DAP.
... We're also talking with SVG, PF, MMI.
... discussions about merging HTML video and SVG video.
... I can send a reminder to the IG, let me know if you're interested.

Clarke: yes. I think we're planning DAP on Thursday morning and HTML on Thursday afternoon.

Kaz: During the F2F, we concluded to create a captioning community group. If anyone interested in accessibility, it would be great to meet with accessibility guys during TPAC.

[Call adjourned]