- From: Francois Daoust <fd@w3.org>
- Date: Fri, 14 Oct 2011 09:31:46 +0200
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi,
The minutes of yesterday's Media Pipeline Task Force teleconference are available at:
http://www.w3.org/2011/10/13-webtv-minutes.html
... and copied as raw text below.
Quick summary:
- Requirements were reviewed against submitted HTML LC bugs to check for potential further gaps
- R1, R2 covered by bug #13359
- R3 covered by bug #13358, but Jan will dig into details on temporary removal of tracks (e.g. to insert commercials)
- R4, R7, and R9 are covered by bug #13333, provided that the bug gets reopened
- R5, R8, and R10 not covered but there needs to be a good rationale to justify the need
- Clarke will update the doc to reflect discussions
Thanks,
Francois.
-----
Media Pipeline Task Force Teleconference
13 Oct 2011
[2]Agenda
[2] http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_13th_October_2011
See also: [3]IRC log
[3] http://www.w3.org/2011/10/13-webtv-irc
Attendees
Present
Francois_Daoust, Clarke_Stevens, Kazuyuki_Ashimura,
Eric_Winkelman, Hiroyuki_Aizu, Shunichi_Gondo,
Franck_Denoual, John_Simmons, Steven_Wright, Duncan_Rowden,
Jan_Lindquist, Tatsuya_Igarashi
Regrets
Chair
Clarke
Scribe
Francois
Contents
* [4]Topics
1. [5]R1. Timed Text Cue Mapping
2. [6]R2. Key Metadata Types
3. [7]R3. Midstream Modification of Track Elements
4. [8]R4, R7, R9. Parameters for Content Authorization,
Adaptive Bit Rate, Security and Digital Rights Management
5. [9]R5, R8, R10. Feedback loop for Content Authorization,
Adaptive Bit Rate, Security and Digital Rights Management
* [10]Summary of Action Items
_________________________________________________________
<Clarke> requirements:
[11]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements
[11] 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:
[12]http://www.w3.org/TR/html5/video.html#error-codes
[12] 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]
Summary of Action Items
[End of minutes]
Received on Friday, 14 October 2011 07:32:19 UTC