16:31:31 <RRSAgent> RRSAgent has joined #html-media
16:31:31 <RRSAgent> logging to http://www.w3.org/2015/04/15-html-media-irc
16:31:33 <trackbot> RRSAgent, make logs public
16:31:33 <Zakim> Zakim has joined #html-media
16:31:35 <trackbot> Zakim, this will be 63342
16:31:35 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:31:36 <trackbot> Meeting: HTML Media Task Force Teleconference
16:31:36 <trackbot> Date: 15 April 2015
16:32:03 <paulc> zakim, who is on the phone?
16:32:03 <Zakim> sorry, paulc, I don't know what conference this is
16:32:04 <Zakim> On IRC I see RRSAgent, paulc, trackbot, adrianba
16:32:25 <paulc> zakim, list conferences
16:32:25 <Zakim> I see no active conferences and none scheduled to start in the next 15 minutes
16:36:28 <BobLund> BobLund has joined #html-media
16:38:28 <ddorwin> ddorwin has joined #html-media
16:38:50 <ddavis> ddavis has joined #html-media
16:38:55 <cheslip> cheslip has joined #html-media
16:39:19 <cyns> cyns has joined #html-media
16:39:21 <geguchi> geguchi has joined #html-media
16:39:28 <wolenetz> wolenetz has joined #html-media
16:39:53 <MattWolenetz> MattWolenetz has joined #html-media
16:40:30 <paulc> zakim, who is on the phone?
16:40:30 <Zakim> sorry, paulc, I don't know what conference this is
16:40:31 <Zakim> On IRC I see MattWolenetz, geguchi, cyns, cheslip, ddavis, ddorwin, BobLund, Zakim, RRSAgent, paulc, trackbot, adrianba
16:40:36 <JF> JF has joined #html-media
16:41:11 <ddavis> zakim, this is 63342
16:41:11 <Zakim> sorry, ddavis, I do not see a conference named '63342' in progress or scheduled at this time
16:41:14 <rustamk> rustamk has joined #html-media
16:41:25 <ddavis> zakim, this will be 63342
16:41:25 <Zakim> I do not see a conference matching that name scheduled within the next hour, ddavis
16:41:29 <LJWatson> LJWatson has joined #html-media
16:41:33 <ddavis> zakim, this is HTML_WG(MEDIA)
16:41:33 <Zakim> sorry, ddavis, I do not see a conference named 'HTML_WG(MEDIA)' in progress or scheduled at this time
16:41:38 <ddavis> zakim, this will be HTML_WG(MEDIA)
16:41:38 <Zakim> I do not see a conference matching that name scheduled within the next hour, ddavis
16:42:19 <sahil> sahil has joined #html-media
16:42:59 <paulc_> paulc_ has joined #html-media
16:51:11 <paulc_> zakim, who is on the phone?
16:51:11 <Zakim> sorry, paulc_, I don't know what conference this is
16:51:13 <Zakim> On IRC I see paulc_, LJWatson, rustamk, JF, MattWolenetz, geguchi, cyns, cheslip, ddavis, ddorwin, BobLund, Zakim, RRSAgent, paulc, trackbot, adrianba
16:52:03 <paulc_> Agenda: https://www.w3.org/wiki/HTML/wg/2015-04-Agenda
16:57:43 <ddavis> scribenick: ddavis
16:57:54 <ddavis> scribe: Daniel
16:58:13 <ddavis> Meeting: HTML WG Media Task Force F2F (Day 1)
16:58:18 <ddavis> Chair: paulc
16:58:43 <ddavis> Topic: Agenda bashing
16:58:55 <ddavis> paulc: How do we allocate our time between EME and MSE?
16:59:03 <ddavis> paulc: We have a lot of detailed points for EME.
16:59:16 <ddavis> ... We asked people to suggest their preferred topics.
16:59:39 <ddavis> ... See https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#Potential_Topics
17:00:18 <ddavis> ... I'd have thought we need to get some sort of agreement to split EME and MSE time.
17:00:34 <ddavis> ... Jerry, Matthew and Mark are the MSE editors.
17:00:54 <ddavis> ... We've got CR status at 5pm today.
17:01:12 <ddavis> ... The status is that Cyril took at action item to do some work on MSE CR, back in TPAC.
17:01:59 <ddavis> ... Apparently there's no update since January.
17:02:49 <ddavis> MattWolenetz: I reduced the initial list of bugs to a few.
17:03:19 <ddavis> ... These are listed in https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#MSE
17:04:33 <cwilso> cwilso has joined #html-media
17:04:34 <ddavis> ... Only 28465 really requires significant action, I think.
17:04:54 <ddavis> paulc: I'd like to give an update on 27239 because I've been looking into that.
17:05:17 <ddavis> ... I've been talking to Dominic and TJ about whether we still need the normative reference.
17:05:26 <ddavis> ... That and testing are probably the large items.
17:05:33 <ddavis> ... So could we allocate an hour to MSE?
17:05:53 <ddavis> ... We could do it after lunch, excluding CR status.
17:06:04 <ddavis> ... At 5pm, we should ONLY have the CR status discussion.
17:06:32 <ddavis> ... Should we just start with MSE and get them out of the way?
17:07:23 <ddavis> Paul updates the agenda on the wiki.
17:07:39 <ddavis> paulc: How do we organize the EME topics?
17:07:56 <jdsmith> jdsmith has joined #html-media
17:07:56 <ddavis> ... The administrative stuff is at the bottom.
17:08:30 <ddavis> ... David, what do you mean by the "interoperability" topic?
17:08:41 <ddavis> ddorwin: I'll update the wiki with a link.
17:09:52 <ddavis> paulc: Shall we take an hour for lunch?
17:11:31 <ddavis> ... Taking a vote of how many people will be here at 5pm Thursday.
17:11:51 <ddavis> ... So looks like we have critical mass through tomorrow afternoon.
17:12:09 <ddavis> ... I suggest we just get started with MSE topics and see how long it takes to get through the non-CR items.
17:12:14 <ddavis> ... Matthew do you want to lead?
17:13:15 <ddavis> Topic: [MSE] Bug 27239
17:13:19 <paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239
17:13:38 <ddavis> paulc: The history is that we've been waiting for the streams spec to lock down.
17:13:56 <ddavis> ... Last week I picked up the thread which pointed to bug #253 in the streams spec.
17:14:05 <ddavis> ... I spent a message asking the status.
17:14:32 <ddavis> ... The proposal we're talking about is "Readable byte stream"
17:14:36 <paulc_> Readable byte stream proposal: https://github.com/whatwg/streams/blob/master/BinaryExtension.md
17:14:53 <ddavis> paulc: That proposal is not in the stream spec yet - it's a standalone proposal.
17:15:04 <ddavis> ... We need to reference that for the streams capability within MSE.
17:15:09 <sahil> sahil has joined #html-media
17:15:10 <ddavis> ... This bug is stuck.
17:15:30 <paulc_> See status report on streams status: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239#c4
17:15:47 <ddavis> ... The answer I got from Dominic is the issue we should look at is issue #300
17:15:54 <paulc_> Master issue on this implementation is https://github.com/whatwg/streams/issues/300
17:16:18 <ddavis> paulc: There's a series of items that need to be done before moving to stream spec.
17:16:51 <ddavis> ... I was referred to Takeshi who said they're going to do the integration next week.
17:16:56 <LJWatson> LJWatson has joined #html-media
17:17:10 <ddavis> ... I'm assuming the MSE spec will be based on the streams spec but I don't if anyone's looked at that proposal.
17:17:33 <ddavis> ... As soon as this appears in the streams spec the MSE editors will have to see whether that can be done.
17:17:47 <ddavis> MattWolenetz: I haven't looked into how much change is needed for that.
17:17:59 <paulc_> ETA for integration is now week of Apr 20:https://github.com/whatwg/streams/issues/253#issuecomment-92841148
17:18:17 <ddavis> paulc: All we have to do is continue to wait.
17:19:04 <ddavis> ddorwin: The MSE reference is to the WHATWG spec (on GitHub).
17:19:11 <ddorwin> https://streams.spec.whatwg.org/
17:19:13 <paulc_> Update would occur next week https://github.com/whatwg/streams
17:19:14 <ddavis> paulc: That's where the change will be made next week.
17:19:41 <ddavis> ... From a chair's point of view it's not clear to me if we could get to CR with a pointer to a WHATWG spec and not a stable W3C spec.
17:19:46 <ddavis> s/W3C //
17:20:00 <ddavis> paulc: How many people have implementations of that feature?
17:20:14 <ddavis> jdsmith: We don't have that feature.
17:20:30 <ddavis> ddorwin: We should add an issue box to the spec saying this is not stable.
17:21:20 <ddavis> ... Search for "appendStream" in the spec for the right section.
17:21:38 <paulc_> Add an issue box for 27239 at http://www.w3.org/TR/media-source/#widl-SourceBuffer-appendStream-void-ReadableStream-stream-unsigned-long-long-maxSize
17:22:58 <ddavis> ... Is there anything else for bug #27239?
17:23:26 <ddavis> @@@ Where would the streams spec be if available in the browser?
17:23:32 <ddavis> ddorwin: As appendStream
17:24:17 <ddavis> s/@@@/sahil:/
17:24:26 <ddavis> Topic: [MSE] Bug 28465
17:24:27 <LJWatson> 6/server irc.w3.org/6667
17:24:36 <paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28465
17:24:57 <markw> markw has joined #html-media
17:25:05 <ddavis> paulc: This has been discussed in the last week. Matthew, you seem to be the author.
17:26:05 <ddavis> MattWolenetz: Currently the media element that is from a secure origin disallows use of media content from insecure origins.
17:26:26 <paulc_> See proposal at https://lists.w3.org/Archives/Public/public-html-media/2015Apr/0013.html.
17:26:32 <ddavis> ... This bug is trying to track improving this without introducing securing security regressions.
17:26:55 <ddavis> ddorwin: This bug tracks the fact that MSE generally doesn't allow that.
17:27:11 <ddavis> ... This tracks making MSE content the same as regular video content.
17:27:25 <ddavis> MattWolenetz: There is one proposal outstanding for how this might be accomplished.
17:27:33 <ddavis> ... Most of it depends on updates to specs outside MSE.
17:28:05 <ddavis> ... I don't have extremely deep knowledge of the other specs. My understanding is that the approach presented here is feasible.
17:28:46 <ddavis> ... The idea is for the response portion of the fetch API is to append to the stream using the MSE API for insecure content into a secure origin.
17:28:59 <MarkVickers> MarkVickers has joined #html-media
17:29:16 <ddavis> markw: I don't have any objection to the proposal but it's not something we'd find useful. I may be able to say something later.
17:29:36 <ddavis> ... This proposal doesn't protect the privacy of the content being viewed.
17:29:53 <ddavis> paulc: You pointed out that nobody had responded directly to this proposal.
17:30:00 <paulc_> Original proposal is at http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0038.html
17:30:20 <ddavis> markw: We feel the whole UI for mixed content is not good. We feel it should be shown the same as insecure sites.
17:30:39 <ddavis> ... It's a lot to ask of the user to have a "third category" of security.
17:31:20 <ddavis> ddorwin: This provides authors an option. For someone using MSE but doesn't want to downgrade/upgrade to/from HTTPS.
17:32:12 <ddavis> rustamk: From the perspective of Comcast, the biggest concern is the way our CDN is structured is how long does it take to transition the CDNs to do everything over HTTPS.
17:32:37 <ddavis> ... Some of the traffic might be going over an insecure pipeline so that messaging could be controlled by the browsers.
17:32:52 <ddavis> ... We don't object to the proposal.
17:33:33 <ddavis> paulc: We could drill down into the proposal. There's lots of other discussion on this thread about what the thing should be called. It's up to you attendees if you want to delve deeper now.
17:33:38 <joesteele> joesteele has joined #html-media
17:34:11 <ddavis> BobLund: I'd agree with David and Matt that there's nothing wrong with this proposal but we don't see it as a solution to the HTTPS issue - it's a standalone issue.
17:34:58 <ddavis> geguchi: I'm not sure how we can address this but if you want to be able to do things like convert @@@ segments to support TLS everywhere, that's something you can do.
17:35:46 <ddavis> ddorwin: There's been hints of requirements for HTTPS. This is an MSE feature - there's nothing that will allow you to get content on a HTTPS page.
17:36:04 <ddavis> ddorwin: That's more of a discussion for HTTPS being required.
17:36:18 <ddavis> paulc: So what do we do with this bug? Make it dependent on something else?
17:36:35 <ddavis> paulc: Makes me uncomfortable that before CR we have people saying  not against and not for.
17:36:38 <ddavis> BobLund: I'm for it.
17:36:56 <ddavis> paulc: Matthew, do you know what to change to implement this?
17:37:16 <ddavis> MattWolenetz: There's still discussion on this about getting streams work done sufficiently.
17:37:47 <ddavis> ddorwin: In this thread there's ongoing conversations. Is MSE going to change, etc.?
17:38:07 <ddavis> ... The debate is dependStream or dependResponse and it's not just a renaming issue.
17:38:29 <ddavis> ... We favor dependStream because you need to make sure you don't expose anything from an opaque object.
17:38:40 <ddavis> ... Going to rec is dependent on the Streams API anyway.
17:39:09 <ddavis> ... We also thing that there are other cases for this related to Fetch where you wouldn't want an opaque object, so these are generally useful primitives that MSE could take advantage of.
17:39:15 <paulc_> See Domenic's offer to spec what is needed here: http://lists.w3.org/Archives/Public/public-html-media/2015Apr/0023.html
17:39:37 <ddavis> paulc: I also think it would be too hard to spec an opaque object.
17:39:52 <ddavis> ... Do you think Dominic is going to do this and make a PR?
17:40:11 <ddavis> ... Then we'd be in the  same position as the previous bug - depending on a pull request.
17:40:39 <ddavis> ... The Stream spec uses the methodology of doing a pull request for just this new piece of technology, make sure they got the names right, etc.
17:40:55 <ddavis> ... so anyone interested would need to discuss it on that pull request thread.
17:41:15 <ddavis> ... So we would open up an issue box in the spec saying we have a possible dependency.
17:41:40 <ddavis> ... When that dependency gets to a specific state then we'd have the discussion in the MSE forum to see if we need to change something.
17:42:07 <ddavis> MattWolenetz: Mainly I was looking to see if there's consensus and no objections to this particular approach.
17:42:39 <ddavis> paulc: Until people see what Dominic does in his pull request it's unlikely we'll be able to drill down into this.
17:42:55 <ddavis> ddorwin: This is more of an FYI.
17:43:08 <ddavis> ... Dominic and Anne have more expertise on those APIs.
17:43:22 <joesteele> s/@@@ segments/TLS segments to fragmented MP4/
17:43:47 <ddavis> paulc: I'd call this an active bug and Matthew, we'd ask you to anchor something in the bug, referring to 28465
17:44:14 <ddavis> paulc: I think you should ask Dominic for the pull request so we can refer to it.
17:44:32 <ddavis> MattWolenetz: Makes sense.
17:44:54 <ddavis> Topic: [MSE] Bug 27242
17:44:59 <paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242
17:45:14 <paulc_> rrsagent, generate the minutes
17:45:14 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html paulc_
17:45:50 <ddavis> MattWolenetz: I'll be splitting out the portion of this bug where I added further scenarios.
17:46:00 <ddavis> ... Those will be broken up into separate bugs.
17:46:20 <ddavis> ... Comment #3 and below - we don't need to discuss at this time.
17:46:40 <paulc_> Matthew will separate the items in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c3 into separate bugs
17:47:00 <ddavis> MattWolenetz: Currently we waiting for feedback for what we should do in out-of-order decode streams.
17:47:26 <ddavis> ... If we've not appended a P frame, should we @@@ or not.
17:47:41 <paulc_> this bug will concentrate on the question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c2
17:48:15 <ddavis> s/@@@/buffer/
17:48:37 <paulc_> Question at hand in bug 27242 is "By keeping the P-frame out of the ranges util the B-frames arrive, I think it would be clearer to app developers that the SourceBuffer is still waiting for more data even though the P-frame was appended."
17:48:38 <ddavis> MattWolenetz: We want feedback from developers on what the buffer ranges should be.
17:49:44 <ddavis> ... If you have an out-of-order decode and you've not yet appended P-frames, what should the source buffer in MSE tell the buffer about the P-frames.
17:49:52 <ddavis> ... Have they been buffered or not?
17:50:35 <ddavis> markw: In extreme cases, there are 60 fps but there could be 60 frames that cover 2 seconds.
17:51:03 <ddavis> ... Then the question would be whether playback could continue, but if you can't switch framerates then you're waiting for the B-frames to arrive.
17:51:41 <ddavis> MattWolenetz: That also fits in with the notion of the buffer range.
17:52:02 <ddavis> ... It comes down to the application and implementation.
17:52:15 <ddavis> paulc: So what do we do with this bug?
17:52:26 <ddavis> MattWolenetz: I'll update it based on our discussion.
17:52:40 <ddavis> paulc: So tell the app that the range is what you can play.
17:52:42 <sahil> sahil has joined #html-media
17:52:46 <sahil> sahil has left #html-media
17:53:08 <ddavis> MattWolenetz: Yes. You have two conditions - one is for the same content but e.g. 60 fps playing 60 frames over two seconds.
17:53:37 <ddavis> paulc: Where does this occur within the spec?
17:53:56 <ddavis> MattWolenetz: I know where within the Chromium code. I'll have to go back and find it in the spec.
17:54:30 <ddavis> paulc: So you're going to break out your additional questions because they're orthogonal.
17:54:42 <ddavis> ... And then reply directly to Aaron's original post.
17:55:23 <ddavis> ... Rus, do you know how long the next item will take?
17:55:31 <ddavis> rustamk: More than 10 minutes.
17:55:43 <ddavis> paulc: I suggest we have a 10 minute break.
17:57:13 <ddavis> zakim, who's here?
17:57:13 <Zakim> sorry, ddavis, I don't know what conference this is
17:57:15 <Zakim> On IRC I see joesteele, MarkVickers, markw, LJWatson, cwilso, paulc_, rustamk, MattWolenetz, geguchi, cheslip, ddavis, ddorwin, BobLund, Zakim, RRSAgent, paulc, trackbot, adrianba
18:08:02 <jlacivita> jlacivita has joined #html-media
18:14:07 <rustamk> rustamk has joined #html-media
18:15:14 <joesteele> rrsagent, draft minutes
18:15:14 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
18:16:17 <ddavis> Topic: [MSE] Use cases driving additional/alternate content insertion requirements
18:16:41 <ddavis> rustamk: This is not just ads.
18:16:53 <ddavis> ... People switch players, streams, etc.
18:16:59 <paulc_> paulc_ has joined #html-media
18:17:08 <paulc_> rrsagent, generate the minutes
18:17:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html paulc_
18:17:12 <ddavis> ... Any alternate content - we want to be able to seamlessly insert, remove and delete.
18:17:19 <paulc_> See use cases at https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases
18:17:24 <ddavis> ... These use cases describe things you can't do outside the client.
18:17:42 <ddavis> rustamk: We're suggesting what we want MSE to support with frame-level accuracy.
18:17:56 <ddavis> ... The use cases are well described.
18:18:18 <ddavis> rustamk: All the alternate content that comes in, you can't guarantee it's encoded in the same way or has the same profiles.
18:18:41 <ddavis> ... For ad use cases, the ad providers get content from all over the place.
18:19:12 <ddavis> ... We want to solve the issue for VOD and linear, so it's seamless and the user doesn't notice anything.
18:19:24 <ddavis> ... So here are the use cases - how do we solve it?
18:20:00 <ddavis> geguchi: A lot of these use cases came from gaps we identified.
18:20:24 <ddavis> ... A lot of them came from one particular section of the MSE spec.
18:20:24 <paulc_> See spec gaps: https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases#Specification_Gaps
18:20:53 <ddavis> geguchi: The content you're appending is constant, or so it's assumed.
18:21:09 <ddavis> ... There's a problem if the content is from different sources and is inconsistent, e.g. encoding.
18:21:12 <jdsmith> jdsmith has joined #html-media
18:21:26 <ddavis> ... We could use @@@ cues but they may not be accurate.
18:21:31 <jdsmith> jdsmith has joined #html-media
18:21:43 <ddavis> ... We could have multiple players and buffers but that's not guaranteed to be supported.
18:21:55 <ddavis> ... This section of the spec is important to look at.
18:22:37 <ddavis> paulc: This will push back the status of the MSE spec.
18:22:48 <ddavis> rustamk: In order for MSE to be successful this is a must.
18:23:25 <ddavis> paulc: I know some people see MSE as an extension spec of HTML. Have you considered having this as an extension spec to MSE?
18:23:34 <ddavis> paulc: It could be hooks into MSE.
18:23:58 <ddavis> ... So an extension to an extension, or a future proposal that could be merged in.
18:24:13 <ddavis> ... A bit like how Robin did the ruby feature for HTML.
18:24:26 <ddavis> ... He wrote it as an extension and it was moved in to the main spec.
18:24:34 <ddavis> ... But here it sounds like you're being more additive.
18:24:56 <ddavis> ... Those options exist and you should consider starting to write a spec, then we'd have some idea of what to do.
18:25:17 <ddavis> MarkVickers: I'd like to hear from the spec authors for guidance. This has come up a few times.
18:25:26 <ddavis> ... How much is this an implementation change or a spec change?
18:25:50 <ddavis> ... Do people feel this is needed or something we're not going to support?
18:26:11 <ddavis> Matthew: The intent of MSE was to be less about codec API.
18:26:41 <ddavis> ... I echo the concerns for better transition but I don't see it as something we should have in MSE now.
18:27:07 <ddavis> ... Also I'm not sure how we could minimally modify MSE to include this, especially as it would be almost impossible to implement on some platforms, e.g. mobile.
18:27:23 <ddavis> ... How would you set up MSE sources buffers, for example, to handle this?
18:27:38 <ddavis> ... Do you see a need for frame-accurate track transitions?
18:27:53 <ddavis> rustamk: I think so, I can see a couple of use cases for source equals.
18:28:21 <ddavis> Matthew: If there's a common requirement with source equal then we might want to address that in the HTML source equal, not MSE.
18:28:41 <ddavis> rustamk: So if we update/extend the spec, is there interest in the overall group for these capabilities?
18:28:53 <ddavis> paulc: So is there any interest in those use cases?
18:29:27 <ddavis> MarkVickers: Nobody's thinking this is getting in the way of MSE getting to Recommendation.
18:29:45 <ddavis> ... Let's just talk about are we interested in addressing these use cases in some way.
18:30:02 <ddavis> ddorwin: One issue is to consider whether this is actually an MSE issue or a video issue.
18:30:07 <ddavis> s/@@@/text track/
18:30:43 <ddavis> ddorwin: This could be an implementation issue, so there may be reasons why this could not be implemented.
18:31:04 <ddavis> ... Maybe TPAC is a better place for this discussion.
18:31:25 <ddavis> ... There's other media work we need to look at.
18:32:08 <ddavis> jdsmith: From Microsoft's perspective we're generally supportive. From an implementation perspective we'd have some concerns about dynamically modifying the number of tracks.
18:32:21 <ddavis> ... Being able to change the tracks might be useful.
18:32:57 <ddavis> MarkVickers: When you talk about changing tracks, a common case is one piece of video has two language audio tracks and then goes down to one language.
18:33:21 <ddavis> jdsmith: Right now, we set up a media pipeline and adding or modifying that is normally not done dynamically.
18:33:44 <joesteele> joesteele has joined #html-media
18:33:47 <ddavis> paulc: Is there a correlation between these use cases and what we're talking to the accessibility people about?
18:34:13 <ddavis> rustamk: There's some correlation. There could be a descriptive audio service available for some content.
18:34:33 <ddavis> paulc: This could be interesting for the accessibility people.
18:34:55 <ddavis> MarkVickers: There's a requirement in the US for content to have descriptions, e.g. descriptive tracks.
18:35:06 <ddavis> ... The same thing for text tracks and other languages.
18:35:18 <ddavis> ... It's going to become more of an issue.
18:35:42 <ddavis> ddorwin: We're not handling decoders with text tracks.
18:36:16 <ddavis> ... Also, we can't specify which codecs people should use but we could have best practices.
18:37:00 <ddavis> rustamk: We still get a variety of content such as progressive/not progressive.
18:37:23 <ddavis> ddorwin: We should suggest how to get best compatibility for features.
18:37:43 <ddavis> MarkVickers: There are non-ad cases such as "movie extras", e.g. on DVDs/BluRays.
18:37:59 <ddavis> MarkVickers: There can be extra commentary or director's cuts.
18:38:25 <ddavis> ... You can pre-process it and make it linear but it would be nice if you could deal with it.
18:38:45 <ddavis> markw: There are times when we want to play different segments seamlessly.
18:38:58 <ddavis> ... There's an issue with discoverability and the capabilities of different devices.
18:39:11 <ddavis> ... We just have to encode everything into every possible format.
18:39:27 <ddavis> ... So this issue could be about optimization for a few variety of formats.
18:40:03 <ddavis> MarkVickers: We have linearized things now but if we have an API like this it would help with device capabilities.
18:40:11 <ddavis> ... People can improve their pipelines over time.
18:40:34 <ddavis> geguchi: Not all devices can support everything but it would be nice if the API was not limiting.
18:40:52 <ddavis> geguchi: It sounds like maybe MSE may not be the right place for these places.
18:42:26 <ddavis> ddavis: GGIE TF in the TV IG has similar use cases
18:42:28 <joesteele> https://www.w3.org/2011/webtv/wiki/GGIE_TF
18:42:42 <ddavis> ... That would be a good place to raise this.
18:43:10 <ddavis> paulc: Previously we've encouraged people to file bugs
18:43:17 <MattWolenetz> MattWolenetz has joined #html-media
18:43:29 <rustamk> rustamk has joined #html-media
18:43:39 <ddavis> ... There have been misconceptions about what groups are trying to do, e.g. the Web and TV IG.
18:44:03 <ddavis> paulc: This could be the perfect case of re-starting the relationship with the TV IG.
18:44:28 <ddavis> ... We could work together and they could report back to this Media TF.
18:44:48 <ddavis> ... Is there any chance these use cases are more pertinent at the media level rather than just MSE?
18:45:05 <ddavis> MarkVickers: There's two kind of engagement. One is at the bug level and that's continued.
18:45:21 <ddavis> ... The other is where we wrote big requirements docs which became MSE and EME.
18:45:51 <ddavis> ... What's not clear to me is whether this is something that should be handled at a bug level or at a bigger level, e.g. Web and TV IG requirements.
18:46:50 <ddavis> ddavis: GGIE would take longer because it's generating requirements from use cases.
18:47:07 <ddavis> rustamk: An extension to MSE might be a better, faster place to start.
18:47:29 <ddavis> ddorwin: MSE is about streams, but this might be a separate issue.
18:47:57 <ddavis> MarkVickers: The answer is, is that level of use cases enough or is it better to write a more formal requirements document to get more input and refinement.
18:48:30 <ddavis> MattWolenetz: One thing maybe missing from the use cases is the source equal case.
18:48:52 <ddavis> ... If MSE were to support these use cases, changes would have to be made all over the place.
18:49:26 <ddavis> ... If we want to linearize or have multiple tracks, how is that related to source equal?
18:49:41 <ddavis> MarkVickers: That's a good thing to take on - add source equal to the use cases.
18:49:49 <ddavis> ... and where should these documents live?
18:50:12 <ddavis> paulc: If we knew the solution was something additional to MSE, one proposal is do a pull request of what you'd change.
18:50:40 <ddavis> ... but if it's possible to solve these use cases by changing the media element, then you want to do a pull request on HTML 5.1.
18:51:16 <ddavis> ... You've nearly picked the solution, described the use cases. You've got to pull the use cases up a level and decide if the changes should be in MSE, HTML or other.
18:51:51 <ddavis> ... Tackle the question of what it would take to provide that facility to the media element itself.
18:52:07 <ddavis> ddorwin: EME is on the media element, as an example.
18:52:12 <LJWatson> LJWatson has joined #html-media
18:52:58 <ddavis> ... I don't know the details of the use cases but maybe it's harder to read through Interest Group requirement documents.
18:53:18 <ddavis> ... Also some of the issues don't require specs, they just don't have implementations.
18:53:37 <ddavis> ... They could be implementation-dependent.
18:53:55 <ddavis> ... E.g. synchronization is in the HTML spec but is poorly implemented.
18:54:36 <ddavis> BobLund: About the Media Controller, one of the options is to support multiple media elements with synchronization. What's missing from the Media Controller?
18:54:52 <ddavis> ddorwin: It was implemented in WebKit but no better than what you could do with JavaScript.
18:55:09 <rustamk> rustamk has joined #html-media
18:55:20 <ddavis> ... It was not implemented well and was misleading.
18:55:51 <ddavis> ... It was a lower priority and wasn't dealt with.
18:56:20 <ddavis> ... It might help to champion Media Controller.
18:56:33 <ddavis> geguchi: Is Media Controller designed for playlisting elements?
18:56:38 <ddavis> ddorwin: I don't think so.
18:56:45 <ddavis> geguchi: So it's a different use case.
18:56:56 <ddavis> ddorwin: I wasn't proposing it as a solution, just using it as an example.
18:57:15 <ddavis> geguchi: When you look at the spec, some of it disallows this so it's like a blocker.
18:57:56 <ddavis> paulc: In Robin's "After HTML5" plan, sent to the WG and under discussion, there's a reference to more Media APIs.
18:58:33 <ddavis> ... This section of the document talks about what new work might be done - there's an assumption that more is needed for media.
18:58:47 <ddavis> ... The reaction we've got is that we haven't pushed individual items.
18:59:09 <ddavis> ... What we need to do is to figure out if there's going to be more media discussion, who owns that?
18:59:18 <ddavis> ... Might be MSE, Media Controller or something else.
18:59:36 <ddavis> ... In other words, there's going to be more media work done but not a good plan.
19:00:19 <ddavis> ... The suggestion in Robin's document is for Community Groups to be used.
19:00:38 <ddavis> ... It wasn't clear how to choose between Task Forces and Community Groups.
19:01:08 <ddavis> cwilso: There's a lot of discussion on the After HTML5 plan.
19:01:23 <ddavis> ... There's some decision making based on how functional the task forces are.
19:02:04 <ddavis> ... One of the things we've been pushing for is to use Community Groups to incubate brand new ideas to where it could be something for a working group.
19:02:17 <paulc_> paulc_ has joined #html-media
19:02:27 <ddavis> ... They'll be some movement on this.
19:02:36 <paulc_> See After HTML5 [DRAFT] plan: http://darobin.github.io/after5/html-plan.html
19:03:27 <paulc_> In particular it mentions the possibility of new work in Media APIs:
19:03:31 <paulc_> "New Media APIs are needed, and some coherence could usefully be brought amongst all the people extending HTMLMediaElement. Some recent ideas about media controls could also fit here. Note that there is an existing HTML WG Media TF. Whether it should be extended to include new deliverables or whether two groups with different media aspects ought to be considered is left as a decision of the interested parties."
19:03:52 <ddavis> ddavis: Two examples of CGs are the Second Screen CG (now WG) and Device Timing CG, which may be incorporated into the HTML spec.
19:04:22 <rustamk> rustamk has joined #html-media
19:04:22 <ddavis> MarkVickers: The simplest thing would be to leave the use cases as they are and expand on that, having more discussion.
19:04:50 <ddavis> paulc: If the Task Force wants to have a new conference call to go through these, I'm happy to start that.
19:05:02 <ddavis> ... We've had good feedback today.
19:05:27 <ddavis> MarkVickers: At least for now, these use cases could go through one more iteration within the Task Force.
19:05:54 <ddavis> ACTION: paulc to figure out what's going to happen to Media Controller
19:05:54 <trackbot> Created ACTION-82 - Figure out what's going to happen to media controller [on Paul Cotton - due 2015-04-22].
19:06:54 <ddavis> ACTION: rustamk to update the use cases and contact Paul to set up new discussion
19:06:54 <trackbot> Error finding 'rustamk'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.
19:07:29 <ddavis> MarkVickers: You'd need to make the use cases high level enough so that they're not pre-supposing a solution.
19:08:08 <ddavis> MattWolenetz: It may be that the solutions may not be sufficient to meet all the use cases, some of them source equal could benefit from.
19:09:13 <ddavis> ACTION: ddavis to point Web and TV IG members to the use case wiki page.
19:09:13 <trackbot> Created ACTION-83 - Point web and tv ig members to the use case wiki page. [on Daniel Davis - due 2015-04-22].
19:10:35 <paulc_> ACTION: paulc (really rustamk) to update uses cases and arrange for further discussion
19:10:35 <trackbot> Created ACTION-84 - (really rustamk) to update uses cases and arrange for further discussion [on Paul Cotton - due 2015-04-22].
19:12:24 <ddavis> paulc: Let's break for lunch and meet back at 1:15.
19:12:39 <paulc_> rrsagent, generate the minutes
19:12:39 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html paulc_
19:26:33 <BobLund> BobLund has joined #html-media
19:36:14 <ddorwin> ddorwin has joined #html-media
20:08:03 <Zakim> Zakim has left #html-media
20:11:58 <rustamk> rustamk has joined #html-media
20:16:03 <joesteele> joesteele has joined #html-media
20:19:25 <MattWolenetz> MattWolenetz has joined #html-media
20:20:19 <joesteele> scribenick: joesteele
20:20:56 <joesteele> paulc: we will be stepping through the EME agenda now
20:21:07 <joesteele> topic: EME session 1
20:21:13 <joesteele> paulc: David, item #1?
20:21:35 <cheslip> cheslip has joined #html-media
20:21:45 <joesteele> topic: [EME] Interoperability
20:21:52 <ddorwin> https://docs.google.com/presentation/d/1dFCcWC-FH3ghBDQ6fxTc6ABLYcspz9MQ03HYki5e36I/preview?slide=id.p
20:22:09 <joesteele> ddorwin: pasted the link to bring up
20:22:19 <markw> markw has joined #html-media
20:22:55 <joesteele> ddorwin: Interop and segmentation are common topics
20:23:03 <joesteele> ... wanted to talk about the issues
20:23:20 <joesteele> ... previously everything was proprietary
20:23:45 <joesteele> ... EME provides the common platform -- expanding the reach (most of this is on the slides)
20:24:12 <joesteele> ... description of GPS as an interop use case
20:24:33 <joesteele> ... some feature requests for EME prsent the problem of fragmentation as well
20:24:51 <joesteele> ... when optional is used for example, optional features are usually discouraged in specs
20:25:12 <joesteele> ... should avoid optional features
20:25:48 <joesteele> ... Therefore (gives advice on how to judge when adding a feature)
20:26:11 <joesteele> ... Other considerations (more advice on what to consider)
20:26:41 <joesteele> ... this is where TAG is concerned - should be implemented by lower level building blocks
20:27:08 <ddavis> ddavis has joined #html-media
20:27:14 <joesteele> ... Still not convinced? (relating fragmentation/segmentation to common objections raised to EME)
20:27:27 <joesteele> ... and formal objections raised to EME
20:27:49 <joesteele> ... keep in mind that TAG input will be taken into account for final approval
20:27:58 <joesteele> ... (end of slides)
20:28:30 <joesteele> MarkVickers: I think we have accomplished a lot -- what was in the plugin model is now in the HTML5 model
20:28:47 <joesteele> ... but it is true that we now have a problem with how things are currently implemented
20:29:09 <joesteele> ... from a distributors point of view you could choose one of the two widely distributed plugins and run everywhere
20:29:33 <joesteele> ... but now you will have to use different @@models? for each browsers
20:29:44 <joesteele> ... this is a step back. This may change over time
20:30:19 <joesteele> ddorwin: that is another definition of interop, if we are explicit and defined things (not optionally) then the impact of supporting multiple things is lessened
20:30:32 <joesteele> MarkVickers: I would agree, PSSH is a good example where we could do better
20:30:45 <joesteele> ... not really our area, but maybe we should take that on
20:31:05 <joesteele> ddorwin: there is one common PSSH, that may not support all use cases, but does support all in the spec
20:31:07 <circ-user-1ImDm> circ-user-1ImDm has joined #html-media
20:31:18 <joesteele> markw: worth considering where we are
20:31:43 <joesteele> ... came from DRM being a fairly opaque thing, over time we have constrained the way certain features work
20:31:57 <circ-user-1ImDm> SETNAME gurupanguji
20:32:01 <joesteele> ... this is a godo thing, but we did not come to a group conencus that we should do that
20:32:12 <joesteele> ... i.e. only the things in the spec should be supported
20:32:30 <joesteele> ... fragmentation is a bad thing, but a certain amount was to be expected
20:32:40 <cwilso> circ-user-1lmDm:  try "/nick gurupanguji"
20:32:45 <joesteele> ... user agents interacting with the DRM gives them a certain amount of control
20:33:02 <joesteele> ... it is hard to say there should not be optional features because of this
20:33:20 <joesteele> ... want the application to get something, although it may not be just what they ask for
20:33:30 <joesteele> ... for example pre-requesting licenses
20:33:44 <joesteele> ... might not have it, but if you do you can use it
20:34:08 <joesteele> paulc: as far as I know OPTIONAL does not occur i the W3C process doc
20:34:18 <joesteele> ... must, should and may are used
20:34:36 <joesteele> ... I assume you are not saying EME should only include features that every browser implements?
20:34:50 <joesteele> ... that is not what the process doc says, it says we must have at least 2 implementations
20:35:11 <joesteele> ... some process docs are much more stringent (core language features may require 5)
20:35:30 <joesteele> ... there are lots of W3C spec for which there are not 100% feature support when exiting CR
20:35:47 <joesteele> ... you may inly have 2 so you know it is implementable
20:36:01 <joesteele> ... might set it too high
20:36:12 <joesteele> ... so what do you mean by optional in this context?
20:36:17 <joesteele> s/inly/only/
20:36:38 <joesteele> ddorwin: it is more the spirit of the optional, are we defining things that we know exclude large portions of clients?
20:37:08 <joesteele> ... I don't expect every user agent to implement every feature? but are we knowingly defining things only possible on certain clients?
20:37:54 <joesteele> paulc: give me an example of two things that are in the spec that you view as optional
20:38:02 <joesteele> ddorwin: downscaling is optional
20:38:21 <joesteele> ... where you should design an app to avoid failing on platforms that do not support it
20:38:38 <joesteele> ... I have tried to be clear on how you would use it without breaking other platforms
20:39:03 <joesteele> paulc: your presentation is not black and white in the sense that all optional features are evil
20:39:11 <joesteele> ... do you think this should be in the spec or not?
20:39:35 <joesteele> ddorwin: initially I opposed it, there was a lot of desire for it so we found a way to word it to allow apps to fail gracefully
20:40:31 <joesteele> ... initialization data types, codecs those are also optional
20:40:38 <joesteele> ... all HTML issues
20:40:56 <joesteele> paulc: HTML issue 4 -- look that over. THe gorup may the choice not to define it
20:41:04 <joesteele> s/gorup/group/
20:41:13 <joesteele> ... e.g. GIF versus PNG
20:41:33 <joesteele> ... that is a very controversial item, all the codec related ones are
20:41:50 <joesteele> ddorwin: not trying to open that can of worms -- just an example of optional
20:42:06 <joesteele> topic: [EME] Secure Origin Requirement
20:42:26 <joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
20:42:48 <paulc_> See also https://lists.w3.org/Archives/Public/public-html-media/2015Mar/0006.html
20:43:19 <joesteele> rrsagent, draft minutes
20:43:19 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
20:43:34 <joesteele> paulc: there was a huge amount of discussion on this at the TPAC
20:43:41 <markw> https://docs.google.com/presentation/d/14EfnEzyTG5naAZaujv8AX4xv33Z9zUboefuAr4bwnts/edit?usp=sharing
20:43:47 <joesteele> ... lots of other folks in the room for that discussion, TAG folks, etc.
20:44:01 <joesteele> rrsagent, draft minutes
20:44:01 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
20:44:14 <ddorwin> Better: https://docs.google.com/presentation/d/14EfnEzyTG5naAZaujv8AX4xv33Z9zUboefuAr4bwnts/preview?slide=id.p
20:44:28 <paulc_> See TPAC minutes for 26632: http://www.w3.org/2014/10/30-html-wg-minutes.html#item30
20:44:53 <sahil> sahil has joined #html-media
20:45:01 <joesteele> markw: not trying to summarize the whole history
20:45:13 <joesteele> ... question is when EME should be restricted to secure origins?
20:45:43 <joesteele> ... some cases where the browser should restrict, for example when it needs to decide to whom it is giving permission
20:45:48 <LJWatson> LJWatson has joined #html-media
20:46:07 <joesteele> ... Mixed Content (discussion of current proposal)
20:46:28 <joesteele> ... that removes one of the objections to requiring HTTPS because scaling issues go away
20:46:53 <joesteele> ... summarizing the recent thread
20:47:33 <joesteele> ... don't think a blanket restriction is justified, don't think the current proposal is relevant, mixed content UI is not viable
20:48:09 <joesteele> ... Content security modes (discussion of this diagram -- think you should be truthful, but not show as a downgrade)
20:48:43 <joesteele> ... Purpose (restating what the purpose of restricting EME to HTTPS would serve)
20:48:57 <joesteele> ... things have gotten better with recent normative restrictions on the CDM
20:49:25 <joesteele> ... not clear to me that if you are following the recommendations that HTTPS offers you any additional security
20:49:43 <joesteele> ... especially since the same folks are often implementing the browser and the CDM
20:50:08 <joesteele> ... Proposal (if any of these 3 things hold, secure origin is not required)
20:50:42 <joesteele> ... this is responsive to the way TAG raised their comments  to us
20:50:56 <joesteele> ... they indicated if we could not address with normative requirements, should require secure origin
20:51:22 <joesteele> MarkVickers: are you suggesting the 2nd bullet recommendations are mandatory?
20:51:29 <joesteele> markw: that would be fine for me
20:51:38 <joesteele> ... if UA and CDM are happy that would be fine
20:51:44 <joesteele> MarkVickers: agreed
20:52:01 <joesteele> markw: these are recommendations of what the CDM should, but are not well defined enough
20:52:09 <joesteele> ... might be a judgment call
20:52:20 <joesteele> MarkVickers: maybe making them mandatory would lead to approval
20:52:34 <paulc_> enrypting identifiers is in http://www.w3.org/TR/encrypted-media/#encrypt-identifiers
20:53:13 <joesteele> markw: the underlying concern from our point of view is that the way it is framed, "if CDMs don't do X,Y and Z they should use HTTPS". But I want them to all do X, Y and Z.
20:53:30 <joesteele> ... I want the UA to know the security properties of the CDM they are integrating
20:53:56 <joesteele> @@1: the concern is that the person integrating might not have the information to do this
20:54:16 <joesteele> markw: we are saying that they should have that information
20:54:50 <joesteele> @@1: we did have to look at all the plugins and saw which plugins were crashing and that the plugin model was the biggest hole
20:55:05 <joesteele> ... trustig the plugin imepentato to do the right thing doesn't work
20:55:22 <joesteele> markw: but in this case the UA should know that level of detail on the CDM
20:55:35 <joesteele> ... and when you do know you do not need the secure origin
20:56:03 <joesteele> MakrVickers: the closer integration with plugsin was a practical technical thing to do but maybe did not change the legal relationship
20:56:39 <joesteele> ... service providers have to protect privacy, contracts require this, the new EME model brings that relationship into this
20:57:03 <joesteele> ... when the spec says these things are mandatory you do have the capabilities to do the inspection required, you have the leverage
20:57:11 <joesteele> ... no reason you should not feel comfortable
20:57:24 <joesteele> ... you could have source code requirements, etc
20:57:53 <joesteele> ddorwin: you might not have source code access, or it might be a platform DRM where you can't get that
20:58:21 <joesteele> ... in the best case you can do things, but assuming that everyone can do this at the same level as the open source is a problem
20:58:31 <joesteele> ... have to cinsider all user agents, not just the happy path
20:58:54 <joesteele> BobLund: the proposal is not saying everyone has to follow that path, just that if you do you do not have to do that
20:59:09 <joesteele> ddorwin: I would agrue that half do not foloow the happy path
20:59:50 <joesteele> @@1: no way to test those requirements though, I would change the way we did embedded objects so we would not have had the same problem there
21:00:28 <joesteele> ... we are largely moving to secure anyways. the mixed content experience is not great today, but at some point that should tell the user "hey this is insecure"
21:00:35 <joesteele> ... at that point we should bite the bullet
21:01:10 <joesteele> markw: when the user types HTTPS they get the green padlock, but then at some point it will go orange (because content was loaded)
21:01:16 <joesteele> ... don't need to go to much into that
21:01:39 <joesteele> ... one of the reocmmendations is that it is put into a separate process, more work there is needed
21:02:03 <joesteele> ... but I don;t buy that "we do not know what the CDM does" because that is true for many other components of the UA
21:02:24 <joesteele> ddorwin: there are 3 companies where that is true, sometimes those DRMs are part of the platform (running as root)
21:02:42 <joesteele> ... that is not always the case, but in that case it has very different privieldges
21:03:03 <joesteele> markw: but you are saying you don't trust the user agent to to the right thing in that case, but you don't in other cases
21:03:22 <joesteele> markw: I don't think this is a powerfull feature in this case
21:03:56 <joesteele> @@1: we don't always know whether the CDM is following the guidlines,
21:04:20 <joesteele> ... we could test this, but would end up with a registry of which CDMs do and which do not
21:04:38 <joesteele> markw: would like to encourage folks to follow the best practices, but hard to make that testable
21:05:03 <joesteele> MarkVickers: you may be using HTTPS code that is part of the platform which you can't see
21:05:15 <joesteele> ... it is strange to say "secure == HTTPS"
21:05:40 <joesteele> ddorwin: we do not that !HTTPS is not secure
21:06:07 <joesteele> BobLund: but this is about securing the information between the license server and the application
21:06:32 <joesteele> ddorwin: this is a larger subject than that bug, 128 responses to it changes the direction
21:07:34 <joesteele> ... if a user agent does not feel comfortable with a CDM and requires HTTPS that would introduce a difference
21:07:55 <joesteele> markw: annoucing -- we are planning to move all of our services to HTTPS in the coming year.
21:08:24 <joesteele> ... last year we measured a large hit for doing this, but since then we have been optimizing and we think that now the costs are such that it is justified
21:08:38 <joesteele> jdsmith: was there a specific reason?
21:08:42 <paulc_> See Mark's email on Netflix's usage of HTTPS http://lists.w3.org/Archives/Public/public-html-media/2015Apr/0028.html
21:09:02 <joesteele> markw: the big cost was the content streams being snooped on by ISVs
21:09:38 <joesteele> ddorwin: feel like this was a bit of wasted time with this outcome
21:09:53 <joesteele> jdsmith: they did share the information they had at the time
21:10:36 <joesteele> markw: it turned out we were too pessimictic on what the cost would be
21:11:32 <joesteele> @@1: HTTPS is still a journey, e.g. service workers require HTTPS, convincing services to move these to HTTPS is an up-hill battle. Hopefully more folks will discover as you did that it is not as expensive as expected.
21:11:48 <joesteele> s/pessimictic/pessimistic/
21:12:22 <joesteele> markw: if you want folks to move for the right reasons, you should convince them on the benefits rather than withholding features as a stick
21:13:34 <joesteele> @@1: that is fair. But the challenge is how much do you trust the realtionship between UAs and CDM providers.
21:14:00 <joesteele> s/@@1:/cwilso:/
21:14:24 <joesteele> BobLund: why do you think it is unverifiable?
21:14:40 <markw> s/the big cost was the content streams being snooped on by ISVs/the big concern was the content streams being snooped on by ISPs and others/
21:15:03 <joesteele> cwilso: it might require a reverse engineer
21:15:24 <joesteele> MarkVickers: and you can have non-technical/legal things which would constrain this
21:15:30 <markw> s/too pessimictic on what the cost would be/too pessimictic on what the timescale for optimization would be/
21:15:46 <joesteele> joesteele: you could also have a trusted third party as an intermediary for verification of compliance
21:16:10 <joesteele> MarkVickers: the contract could say, the CDM ust be doing these three things and if there is a proven breach you have liability
21:16:27 <ddorwin> https://docs.google.com/presentation/d/1MxiJbSDlhvBTuJkTx4ns-lmSCMKM8WmEc3LCHuVClms/preview
21:16:27 <joesteele> rrsagent, draft minutes
21:16:27 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
21:16:32 <markw> s/too pessimistic on what the cost would be/too pessimistic on what the timescale for optimization would be/
21:17:00 <joesteele> paulc: at the end of the TPAC there seemed to be some agreement that moving the HTTPS at some time was probably the right thing to do
21:17:44 <joesteele> ... this sounds like the spec says "you SHOULD use HTTPS" but in the RFC language that means you must have a reason for making an exception
21:18:13 <joesteele> ... in those cases where the UA and CDM are confident that the restrctiions are being made you do not need to make an exception
21:18:30 <joesteele> ddorwin: basic was that SHOULD would be menaingless, it would have become CANT
21:18:41 <joesteele> ... some providers would have said we will not support it
21:19:02 <joesteele> markw: we never said we could not, we said that it would be prohibitively expensive
21:19:16 <joesteele> ... if a whole bunch of browsers required it tomorrow, it would still be an issue
21:20:10 <markw> s/it would be prohibitively expensive/it would be prohibitively expensive and it would take time to work on optimizations/
21:20:11 <joesteele> paulc: we need to find concensus, if you insist upno MUST we may end up with a formal objection, if a MAY then Google might object
21:20:52 <joesteele> ddorwin: what really matters is the market, need browsers to support it to avoid segmentation
21:21:02 <joesteele> s/menaingless/meaningless/
21:21:20 <joesteele> ddorwin: the spec has a hanging space that does not define this ...
21:21:35 <joesteele> markw: want to go back to the "don't trust CDMs" discussion
21:21:57 <joesteele> ... one of the whole advantage of the EME was that it puts the UA in the position of being able to restrict the CDM
21:22:22 <joesteele> ... if HTTPS is mandatory this reduces the incentive for UAs and CDMs to do the right thing
21:22:52 <joesteele> ddorwin: some folks will plugin ontop of something and not care about security, HTTPS provides some level of security against that
21:23:15 <joesteele> ... now that vendors has to make a choice do they get content or not?
21:24:06 <joesteele> ... at the other end you have browser vendors who care a lot and don't think HTTPS absolves them of providing security
21:24:50 <joesteele> ... the ones that are doing the security reviews also want HTTPS and they ones that are not doing the security reviews should have it required
21:25:18 <joesteele> cwilso: the only test you have for that criteria is that the UA is reviewing the CDM
21:25:36 <joesteele> ... that is a hard thing to do, especially if the CDM updates
21:27:13 <joesteele> cwilso: I don't trust even our own engineers
21:27:24 <joesteele> paulc: those arguments were not used when making TLS mandatory, it is not a MUST
21:27:55 <joesteele> markw: the best engineers in the world write security holes, its not about trusting the engineers
21:28:15 <joesteele> cwilso: the more security we can embed in the stack, the better off we will be overall for defence in depth
21:28:38 <joesteele> jdsmith: some UAs/CDMs may have good security and we are wrapping in an additional layer of security
21:29:15 <joesteele> BobLund: that is good in the absolute case, but it has implications. HTTPS is great but getting the certs to use HTTPS is not.
21:29:26 <joesteele> ... wrapping additional security because we can is not the best solution
21:29:53 <joesteele> ddorwin: someone implementing UA on a set top box with no security concerns,
21:30:24 <joesteele> ... if it is required (for example by Chromium) with a powerful features check, it will be HTTPS by default
21:30:41 <joesteele> ... then everyone will be HTTPS, there will be no motivation to disable if everyone is HTTPS already
21:30:57 <joesteele> ... if we could require sites to use HTTPS it would work, but we cannot
21:31:02 <rustamk> rustamk has joined #html-media
21:31:28 <joesteele> markw: writing a MUST into a client spec like this it not a great tactic for convincing companies to invest millions to upgrade
21:31:43 <joesteele> ddorwin: the intent was that this is a talking point and how do we get there?
21:32:12 <joesteele> ... we did not solve this in Web Platform. We are not turning on HTTPS tomorrow, but it should be clear where we are headed.
21:32:29 <joesteele> ... questions still out there -- What is the cutoff date? when are we moving over?
21:33:13 <joesteele> joesteele: has there been a date discussed yet?
21:33:20 <ddorwin> https://docs.google.com/presentation/d/1MxiJbSDlhvBTuJkTx4ns-lmSCMKM8WmEc3LCHuVClms/preview
21:33:29 <joesteele> ddorwin: that has been blocked by the discussion of whether we need HTTPS
21:33:38 <joesteele> ... want to skim thourhg some of the slides again
21:33:47 <joesteele> s/thourhg/through/
21:34:01 <joesteele> ... Mixed COntent UX --
21:34:16 <joesteele> ... problem is that the UX is not accurate
21:34:31 <joesteele> ... UX looking worse is an opinion
21:34:46 <joesteele> ... Privacy & Security --
21:35:17 <joesteele> ... HTTPS is provding more than just message protection and confidentiality
21:35:35 <joesteele> ... this is kind of about sandbox versus not sandboxed
21:36:12 <joesteele> ... HTTPS is coming (discussion of all the discussion online)
21:36:24 <joesteele> rrsagent, draft minutes
21:36:24 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
21:36:51 <joesteele> ... EME is not alone in trying to address this problem
21:38:12 <joesteele> jdsmith: think that the statement on the Optional page are not agreed
21:38:51 <joesteele> jdsmith: the UAs that are implementing EME are all invested in security, we are not sure how to control the proliferation
21:39:10 <joesteele> ddorwin: the UAs who have implemented and shipped are thinking about thits, this is more about the long tail
21:39:41 <joesteele> ... we are not going to requre some of the normative solutions proposed (i.e. sandboxes)
21:39:48 <joesteele> ... Segmentation --
21:40:31 <joesteele> ... slides need to be updated -- Netflix indicated they will support this
21:40:49 <joesteele> paulc: who defines what is the right choice?
21:40:55 <joesteele> ddorwin: the right choice for them
21:41:23 <joesteele> ... if content providers are not supporting HTTPS these are not really options
21:41:31 <joesteele> rrsagent, draft minutes
21:41:31 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
21:41:49 <joesteele> ddorwin: Summary --
21:42:33 <joesteele> ... we have a solution for mixed content, but spec is not complete and will cause pushback from the TAG
21:42:41 <joesteele> markw: on mixed content UX
21:43:02 <joesteele> ... my concern is the bait and switch of the transition between secure and insecure for the user
21:43:10 <rustamk> rustamk has joined #html-media
21:43:27 <joesteele> ... we would prefer to migrate everything instead of suffer the mixed UX
21:43:44 <joesteele> ... would still like a better answer to how do we better control the CDM
21:44:00 <joesteele> ... if HTTPS is just defense in depth, can we come up with something better
21:44:38 <joesteele> ... it would be awkward for a new UA to not get access to content because of this HTTPS requirement when the older browsers all have it
21:44:55 <joesteele> ... would be a good to know when this HTTPS will become mandatory
21:45:10 <joesteele> ... probably needs to be an agreement between content providers and browsers
21:45:32 <joesteele> ddorwin: Anna proposed we write "by XYZ date" it will be requirded and then we will test it
21:45:46 <joesteele> markw: we could write that into the spec -- required after this date
21:46:00 <joesteele> ddorwin: mainly wanted to get at how do we fix this?
21:46:42 <joesteele> ... having an MSE mixed content solution changes the game, not requiring providers to switch there CDNs
21:47:12 <joesteele> jeremy: if HTTPS is coming, what do we need to focus on?
21:48:11 <joesteele> ddorwin: the powerful features spec is trying to define "what is an origin that can use a powerful feature"?
21:48:47 <joesteele> ... if individual specs are looking at this, and all new specs should be looking at this, in this case some consider EME a powerful feature.
21:49:05 <joesteele> ... there are also efforts to address this in older specs like geolocation and WebRTC
21:49:50 <joesteele> rustamk: assume you are watching protected content and you have to switch to content that is not -- does that need to be going over HTTPS pipeline?
21:50:09 <joesteele> MattWolenetz: is that for a player coming from scure origin?
21:50:14 <joesteele> rustamk: yes
21:50:47 <joesteele> ddorwin: the stream would have to be secure, unless you are using the mixed content UX
21:50:51 <joesteele> s/scure/secure/
21:51:02 <joesteele> ... that is how the mixed content works
21:51:16 <joesteele> jeremy: is XMLHR consider a powerful feature?
21:51:26 <joesteele> ddorwin: no -- it is banned from insecure origina
21:51:54 <joesteele> ... a few things are optionally-blocked because they would break the web
21:52:04 <joesteele> ... other stuff like scripts and XHR are blocked
21:52:12 <joesteele> paulc: how do we move forward?
21:53:00 <joesteele> ... do we want the have text that says "HTTPS is required by date XXX?"
21:53:26 <joesteele> jdsmith: at the TPAC there was a lot of support but we did not talk about timeframes
21:53:55 <joesteele> paulc: picking a date seemed to be a problem because some companies were not ready to go there
21:54:04 <joesteele> ... are we in the same place now? or can we pick a date?
21:54:15 <joesteele> s/requirded/required/
21:54:38 <joesteele> jdsmith: we have one new piece of info, that Netflix has concluded it is feasible to move.
21:55:00 <joesteele> jeremy: I think the rest of the industry is a couple of years behind Netflix
21:55:49 <joesteele> paulc: for those early implementors who built the EME support for Netflix, have gotten a lot of feedback from users
21:56:25 <joesteele> jdsmith: I am jsut saying that they had what looked like a substantial issue and after applying resources, detemrines it was possible. It is a solvable problem.
21:56:42 <joesteele> ... it is a question of how much time is appropriate to give companies to move
21:57:10 <joesteele> @@2: does that mean it is not an undue burden? just because it is solvable does not mean it should be solved
21:57:39 <joesteele> paulc: after 1.5 hours of discussion on this, do we have a concrete proposal for test to go in the document?
21:57:46 <joesteele> ... I can go around the room and ask
21:58:21 <ddavis> s/@@2/Brian/
21:59:02 <joesteele> markw: I think we should recognize the reality that browsers are out there without HTTPS. If we can apply the additional requirements I suggested, make the requirements a SHOULD. If you don't make it a MUST.
21:59:28 <joesteele> ... The task then would be for the browser vendors to talk their customer and determine a timeline for deprecating
21:59:51 <joesteele> ... Need to give certainty to folks getting ready to invest in a move to EME
22:00:04 <joesteele> ... Can't work it out here because we don't have the right people.
22:00:23 <joesteele> rrsagent, draft minutes
22:00:23 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
22:01:34 <joesteele> ddorwin: We can put what I have on the "Proposal" slide IF the requirements are not met
22:02:10 <joesteele> markw: if this is not a secure origin, UA's SHALL reject if the other requirements are not met
22:02:49 <joesteele> paulc: would like to have a real date for when I go to the Director
22:03:01 <joesteele> ... not a bikeshed
22:03:14 <joesteele> ... we can make this a priority feedback item for Last Call
22:03:39 <joesteele> markw: don't want to put a date in the spec because this might not be the right place to make the decision
22:03:54 <joesteele> ... UAs would want to make that decision themselves
22:04:20 <joesteele> paulc: true -- there are more than 4-5 user agents
22:04:49 <joesteele> ... this is not a decision the browser vendors here can decide on
22:05:23 <joesteele> cwilso: the spirit of this is to move to defense in depth through this proposal. Maybe state as "It should be expected that a secure origin is required"
22:05:47 <joesteele> ... if this set of requirements is true, the browser can choose to not require secure origins but we are moving in that direction
22:06:08 <joesteele> paulc: Mark, any change you would block the spec until we have a date in the recommendation?
22:06:25 <joesteele> cwilso: think within two years you will have a decision on this
22:06:43 <joesteele> ... if you could, this part of the spec would go away
22:07:02 <joesteele> markw: I would be fine with noting that we expect this requirement will be upgraded in the future
22:07:13 <joesteele> cwilso: the stronger that signal is, the better for us
22:07:24 <joesteele> ddorwin: I would like to state our end game
22:07:30 <joesteele> paulc: that is what SHOULD does
22:08:06 <joesteele> jdsmith: if a large # of sites are still running HTTP in the future turning it on will be a problem
22:08:20 <joesteele> rustamk: that is why we need to comunicate to all the partners as soon as possible
22:08:43 <joesteele> cwilso: think it should be strong than SHOULD, explicitly state that this is an exception
22:08:58 <joesteele> paulc: that is called a deprecated feature in standards parlance
22:09:10 <rustamk> rustamk has joined #html-media
22:09:23 <joesteele> ... we could write this that way from the start
22:09:35 <joesteele> ... normally that is done in multiple versions of the spec
22:10:22 <joesteele> ... this would be a strong warning
22:10:42 <joesteele> rustamk: what stops a UA from turning it off now?
22:11:05 <joesteele> paulc: that is the intent
22:11:35 <joesteele> ... want to minimize the number of UAs that are dependent on the deprecated feature
22:11:54 <joesteele> jdsmith: thought we wanted to encourage service to support HTTPS?
22:12:06 <joesteele> s/service to support/services to support/
22:12:25 <joesteele> cwilso: this is an indicator to content hosts that they will have to move sooner or later
22:12:54 <joesteele> paulc: david said "we write specs for UAs not web sites", we are telling sites that this thing is going away
22:13:12 <joesteele> ddorwin: synchronous XHR is a good example
22:13:45 <joesteele> paulc: is there consensus if we go in that direction?
22:13:53 <joesteele> ddorwin: yes
22:14:11 <joesteele> markw: that is what I said
22:14:24 <rustamk> rustamk has joined #html-media
22:15:05 <joesteele> MarkVickers: I don't understand the conditional part, the conditional parts should be mandatory
22:15:13 <joesteele> ... 1st bullet
22:15:19 <joesteele> ... 2nd bullet we should go through
22:15:37 <joesteele> ... 3rd bullet - don't understand that one
22:15:54 <joesteele> ... rather make it the case that even with HTTPS all of them should be mandatory
22:16:03 <joesteele> ... some of which are recommendations today
22:16:30 <joesteele> ... for example some CDMs not protecting their data even though HTTPS is being used
22:17:11 <joesteele> markw: the idea was that HTTPS gives you confidentiality, and identifiers that could be exposed will not be using HTTPS
22:18:14 <joesteele> joesteele: our protocol will meet the requirements/recommendations with or without HTTPS so it will not impact us
22:18:38 <joesteele> ddorwin: there are unreachable points in the spec that need to be cleaned up
22:18:55 <joesteele> ... the point of doing that was that people may ignore some parts of the spec
22:19:13 <joesteele> ... but implementor will be reading the algorithms
22:19:31 <joesteele> MarkVickers: maybe those requirements should be in the algorithms then
22:19:46 <joesteele> ddorwin: could do some of that in say "send a message"
22:19:56 <joesteele> ... there are also things that do not fit cleanly
22:20:02 <joesteele> ... there are editing things we could do
22:20:18 <joesteele> ... happy to have more normative stuff, help wanted
22:20:29 <joesteele> MarkVickers: are there recommendations that can be mandatory?
22:20:44 <joesteele> ddorwin: I have tried to make everything I can, mandatory
22:20:52 <joesteele> jdsmith: requirements in there are more normative now
22:21:16 <joesteele> ... we want to encourage folks to use HTTPS as it will be required at some point
22:21:34 <joesteele> ... I am more tempted to say that "You should expect HTTPS will be required at some point"
22:22:05 <joesteele> markw: The identifier should be called out as not being exposable during an interim period while HTTPS is not required
22:23:09 <joesteele> ... we expect the CDM to meet all the requirements so that they could be exposed over HTTP
22:23:17 <joesteele> and then say HTTPS may be required for defence in depth
22:23:39 <joesteele> s/and then/... and then/
22:23:55 <joesteele> paulc: David and Mark can you come up with some text for this by EOD tomorrow
22:24:04 <joesteele> rrsagent, draft minutes
22:24:04 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
22:24:15 <joesteele> Zakim, who is here?
22:24:55 <joesteele> paulc: proposal to to detach the statement about HTTPS from the requirement bullets
22:25:24 <MikeSmith> MikeSmith has joined #html-media
22:25:54 <joesteele> jdsmith: what is meant by per-site permissions?
22:26:21 <joesteele> markw: for example, a dialog saying "allow netflix.com" to use EME
22:27:12 <joesteele> ddorwin: I agree with the deprecated path, but we need to figure out what that IF statement is
22:27:28 <joesteele> markw: I would also like to encourage CDMs to be sufficiently safe to not require HTTPS
22:27:45 <joesteele> ddorwin: exposing a fixed hardware identifier is an example
22:27:56 <joesteele> markw: that is not allowed
22:28:03 <joesteele> ddorwin: that is still a UA decision
22:28:08 <joesteele> rrsagent, draft minutes
22:28:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
22:28:15 <joesteele> paul: break for 10 minutes
22:28:23 <joesteele> s/paul:/paulc:/
22:36:19 <pangu> pangu has joined #html-media
22:37:40 <rustamk> rustamk has joined #html-media
22:46:00 <joesteele> topic: [EME] Issue 45 - Remove "persistent-release" session
22:46:05 <ericde> ericde has joined #html-media
22:46:21 <joesteele> topic: [EME] Issue 45 - Remove "persistent-release-message" MediaKeySessionType
22:46:34 <ddorwin> https://docs.google.com/presentation/d/1k_a3TqPyopLbrbjUseuS2rVhATaccelsqVQZ9EnDZhE/preview?slide=id.p
22:46:41 <joesteele> paulc: please get the issues out and hold the questions for now -- we have guests coming in
22:46:56 <sahil> sahil has joined #html-media
22:47:08 <joesteele> ddorwin: History
22:47:30 <MattWolenetz> MattWolenetz has joined #html-media
22:47:59 <joesteele> ... has not been a concrete definition as yet
22:48:27 <joesteele> ... Current Status (still undefined)
22:49:15 <joesteele> ... Proposal (remove the undefined value and have Mark file bugs for what is needed)
22:49:43 <joesteele> ... this would address the immediate concern and leave a path forward to addressing Marks concerns
22:49:46 <joesteele> paulc: any questions?
22:50:09 <joesteele> jdsmith: are you saying the current specification is not enough today?
22:50:13 <joesteele> ddorwin: yes
22:50:27 <joesteele> ... only a couple of notes about behavior
22:50:46 <joesteele> ... concern is that it will not be interoperable if implemented
22:50:50 <markw> https://docs.google.com/a/netflix.com/presentation/d/1xhihHWL7Vpu0dX4aPYsT1-4ajtZTRqQ3wQvF_yCWyMk/edit#slide=id.p
22:51:57 <joesteele> markw: Secure release (description of what it is)
22:52:16 <joesteele> ... Could drop the "May"
22:52:58 <joesteele> ... Concurrent stream limits (purpose is to enable this feature)
22:53:31 <joesteele> ... could be enforced in Javascript but not robust enough and could allow automated account sharing by cirumventing
22:54:18 <joesteele> ... Three approaches (real-time and non-real-time)
22:54:37 <joesteele> ... approach depends on context (e.g. native apps, browsers)
22:55:08 <joesteele> ... Javascript approahc is real-time, CDM approach is non-real-time
22:55:42 <joesteele> ... Comment (real-time not good enough, non-real-time is)
22:56:00 <joesteele> s/Comment (/Marks Comments (/
22:56:13 <geguchi> geguchi has joined #html-media
22:56:34 <joesteele> ... has negative implications for server infrastructure being real-time
22:56:54 <joesteele> ... this was proposed very early on and was left as blackbox by design
22:57:23 <joesteele> ... think there are things remaining to be spec'd but were waiting for additional implementation experience
22:57:53 <joesteele> ... seems like David wants details about what is in that message, but has been CDM-specific
22:58:00 <joesteele> ... my suggestion is that it reamin that way
22:58:14 <joesteele> s/reamin/remain/
22:58:27 <joesteele> ddorwin: I was referring more to behavior rather than contents
22:58:38 <joesteele> ... is this actually deployed in user agents?
22:58:42 <joesteele> markw: yes
22:58:58 <joesteele> ddorwin: ok wanted to have this discussion
22:59:12 <joesteele> ... we do not believe real-time is practical for any platform
22:59:30 <joesteele> ... non-real is deployed on many platforms
22:59:57 <joesteele> ... would like some data on what kinds of problems are being solved by this?
23:00:15 <joesteele> markw: we are working with folks to implement this and it is in the field today
23:00:32 <joesteele> ... if it is removed entirely, folks will have to make proprietary extensions to support this
23:00:38 <joesteele> ... that would be unfortunate
23:00:39 <JF> JF has joined #html-media
23:00:47 <joesteele> ... we can certainly fill in missing details
23:00:59 <joesteele> ... I hear the concerns about reporting details
23:01:10 <joesteele> ... unnecesary to do the real-time thing
23:01:30 <joesteele> ... I can't publish our data about error rates
23:01:56 <joesteele> ... Fundamentally either you require the license server to be online for the stream to continue or you do not
23:02:17 <joesteele> ... I don't hold out much hope for a renewal based solution
23:02:37 <joesteele> ddorwin: the application is repsonsible for keeping the servers up, not the client
23:02:49 <joesteele> ... think that is the wrong approach
23:03:08 <joesteele> ... re: implementing their own things, I would argue folks are doing that already
23:03:38 <joesteele> ... the concern is segmentation. Absent this feature all CDMs should get access to content, except Netflix.
23:03:49 <joesteele> ... so it becomes non-optional
23:03:56 <rustamk> rustamk has joined #html-media
23:04:12 <joesteele> ... we should not pretend that real-time will not be a requirement in the future
23:04:23 <joesteele> paulc: think we should go back to the original agenda at this point
23:04:34 <joesteele> ... Accessibility visitors have a presentation
23:05:12 <joesteele> MarkVickers: I have a security expert who would like to speak on this tomorrow
23:05:18 <joesteele> paulc: how about 11am PST?
23:05:53 <joesteele> topic: Transcript Accessibility
23:06:04 <paulc_> https://www.w3.org/WAI/PF/HTML/wiki/Full_Transcript
23:06:43 <joesteele> chaals: this comes from HTML issue 194
23:06:47 <paulc_> See http://www.w3.org/html/wg/tracker/issues/194
23:06:54 <joesteele> ... how do you find transcripts for video?
23:07:12 <joesteele> ... for example you are not actually watching the video
23:07:17 <JF> Proposal under discussion: https://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement
23:07:29 <joesteele> ... you are blind, you are in a meeting, you just want to skip to the useful bits, etc.
23:07:41 <joesteele> ... lots of reasons you might want the transcript
23:07:54 <joesteele> ... today there is no common way of doing that
23:08:23 <joesteele> ... we are here because you as the Media TF know about media on the web and want a sanity check
23:08:58 <joesteele> ... would like to ultimately ask for a way to add a rel attribute on a link as a standard way of identifying the transcript for a video
23:09:19 <joesteele> ... would also like an HTML element called <transcript> used for wrapping transcripts
23:09:42 <joesteele> ... explained the use cases in the wiki page
23:09:55 <joesteele> ... sometimes the transcript is on the same page as the video
23:10:03 <joesteele> ... sometimes they are external
23:10:48 <joesteele> ... sometimes you have multiple transcripts, text, audio transcriptions, alternate language dub
23:11:02 <joesteele> ... as a search engine we want folks to be able to find videos
23:11:24 <joesteele> ... one thing that is harder is to use a snippet from the dialog of the video to find the video
23:11:41 <joesteele> ... this should be easy to do given the transcripts available
23:12:01 <joesteele> ... should be able to use those transcripts for this use case
23:12:27 <joesteele> chaals: should not be a hard technical problem
23:12:54 <joesteele> ... transcript might only be available as a PDF -- would like to link in this case
23:13:08 <joesteele> ... someone uses a "Daisy" player, would like to link to the Daisy transcript
23:13:22 <joesteele> ... Requirements are on the web page
23:13:41 <joesteele> ... R1 -- R5
23:14:18 <joesteele> ... Proposed solutions. We want a way to link a video to a transcript
23:14:53 <joesteele> ... attribute on the video element has been discussed, having multiple transcripts on the video is a problem
23:15:34 <joesteele> ... using a link seems to be semantically equivalent, but tracks are supposed to be synced to the master component, and if no timing this is not really a track
23:15:52 <joesteele> ... (this is partially a bikeshed argument -- we don't care)
23:16:34 <joesteele> ... could use a transcript element, but don't want to block this off while we wait??
23:17:00 <joesteele> ... we prefer the <link rel="transcript" > construct
23:17:15 <joesteele> ... (discussion of the wiki page markup)
23:17:26 <joesteele> rrsagent, draft minutes
23:17:26 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
23:17:57 <joesteele> ... we don't think the transcript element is necessary if we get the link "rel"
23:18:24 <ericde> ericde has joined #html-media
23:18:40 <joesteele> ... this also simplified the probably edge case of multiple transcripts
23:19:11 <joesteele> ... this would let us know where the transcripts begin and end
23:19:41 <joesteele> ... would like for folks to agree that we can produce and consume this construct
23:19:52 <joesteele> paulc: why was this never dealt with before?
23:20:19 <ddavis> q+
23:20:22 <joesteele> chaals: various reasons, some folks have preferred transcript element right up to today
23:20:42 <joesteele> ... looks kinda like the longdesc which might have impacted this discussion
23:20:54 <joesteele> ... lots of discussions on this still going on
23:21:12 <ddorwin> q+
23:21:26 <paulc_> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964
23:21:47 <paulc_> q?
23:21:49 <joesteele> ... is this obviously insane or a dumb approach? can you imagine consuming or producing?
23:22:08 <rustamk> rustamk has joined #html-media
23:22:10 <MattWolenetz> q+
23:22:33 <joesteele> ddavis: think that linking to transcripts is important
23:22:43 <joesteele> ... in the video element you can have multiple sources
23:23:01 <joesteele> ... inconsistent for link to be outside -- should be consistent with sources
23:23:17 <joesteele> ... agree that you do not know where it ends -- but don't think that is a big issue
23:23:53 <joesteele> chaals: could use source or track instead but folks objected
23:24:10 <joesteele> ... can have multiple links inside and folks are using that for embedded data
23:24:44 <joesteele> cheslip: the transcript container has a landmark elemtn similar to nav
23:25:03 <joesteele> JF: not knowing where it ends is a problem, similar problem with footnotes
23:25:14 <joesteele> s/elemtn/element/
23:25:34 <joesteele> ddorwin: according to NDN link can only be in a head element
23:25:49 <rustamk> rustamk has joined #html-media
23:25:50 <joesteele> ... have you explored using custom elements to prove its usefulness
23:25:55 <joesteele> chaals: not yet
23:26:09 <rustamk> rustamk has joined #html-media
23:26:15 <joesteele> ... core of what we want is something in the video element that gets exposed
23:26:26 <joesteele> ddorwin: and another issue is what the UX expected is?
23:26:35 <joesteele> chaals: video points to the transcript
23:27:03 <joesteele> ... some players wants to allow you to scroll around the transcript and then sync back to the location in the video at that point
23:27:16 <joesteele> ... folks are not very specific
23:27:25 <joesteele> MarkVickers: you would need timing info right?
23:27:36 <joesteele> chaals: you can have links which point to a timed thing in the video
23:27:47 <joesteele> ddavis: you are saying you can use timed tracks?
23:27:50 <joesteele> chaals: yes
23:28:27 <joesteele> MattWolenetz: I assuem the analog is that apps can dynamically construct this transcript element, if they are linking back int how might this be done with MSE?
23:28:36 <joesteele> chaals: this has not been explored
23:28:55 <joesteele> ... we have explored "you have a link"
23:29:01 <ddorwin> s/to NDN/to MDN/
23:29:11 <joesteele> BobLund: that would be a difference between MSE and source=
23:29:27 <joesteele> MattWolenetz: source= is more of a static resource
23:30:05 <joesteele> ... use case #3 mentions synchronization from the transcript is required, curious how that got much pushback from track
23:30:38 <joesteele> JF: when transcript is static it reads more like a screenplay, would not normally have timestamps
23:31:04 <joesteele> ... now we can do interactive transcripts -- at least one producer is doing that by embedding timestamps for every word in the transcript
23:31:10 <joesteele> ... linking back to original video
23:31:25 <joesteele> cheslip: this is really a landmark
23:31:40 <joesteele> jdsmith: so you do not envision a default transcript reader?
23:31:46 <joesteele> chaals: right
23:32:29 <joesteele> ... and a lot of the use cases I envision there is a user will preferentially read some large presentations and not others
23:33:03 <joesteele> jeremy: I just think that is not the right tag. Also think this is not formalized enough to be part of HTML, could be a source as not a track.
23:33:14 <joesteele> JF: that is interesting
23:33:25 <joesteele> BobLund: why could the tracks not be just a single queue
23:33:42 <joesteele> chaals: you could but browsers objected
23:34:08 <joesteele> chaals: we think that is a bikeshed issue but it has not gotten resolved
23:34:28 <joesteele> paulc: when was this conversation?
23:34:39 <joesteele> JF: F2F 2012 in Microsoft
23:35:36 <joesteele> MarkVickers: we had talked about "related things",  images, titles etc. This is not like that because it is tightly tied to a specific piece of content.
23:36:16 <joesteele> ... it is really part of that piece of media. I think this is also powerful but it needs to be standardized more so people can rely on what it being referred to.
23:36:46 <paulc_> See http://www.w3.org/2012/05/03-html-wg-minutes.html#item06 for the April 2012 discussion of ISSUE-194
23:36:47 <joesteele> ddorwin: like our earlier discussion on splicing content, it seems like the transcript should be related to a time
23:37:06 <joesteele> ... that time may default to zero, but then you may have 5 and 10 and 30, etc.
23:37:28 <joesteele> ... because thier are two related things here, seems like an architectural issue
23:38:08 <joesteele> chaals: my expectation of the default transcript format is HTML
23:38:24 <joesteele> ... because browsers are good at that
23:38:47 <joesteele> ... we want to set that expectation, but we don't want to break the case where folks have a PDF
23:39:17 <joesteele> ... we should think more about that
23:39:37 <joesteele> JF: you are right about the tight binding, we want to be as generic as possible
23:40:02 <joesteele> MarkVickers: there are backwards ways of dealing with things --  like mime-types
23:40:22 <joesteele> ... if we think it is important we have a set of these, we should define that set
23:40:35 <joesteele> ... give people a target of a good transcript to go to
23:40:52 <joesteele> ddorwin: one potential option is a shell file like WebVTT
23:41:09 <joesteele> ... would have times and could have additional times later
23:41:24 <joesteele> chaals: what you get today usuauly is an HTML document
23:41:36 <joesteele> ... the reference will often be done with a URL
23:41:55 <joesteele> ... we have punted that decision to URLs because that is already there
23:42:14 <joesteele> ... sound like we are describing best practice, ie. do things that work in browsers or players
23:42:42 <joesteele> ... if we had said you should be using HTML+ that would changes things
23:42:50 <joesteele> rrsagent, draft minutes
23:42:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
23:43:17 <joesteele> JF: you have mentioend track twice, we got a lot of feedback from an implementor on this.
23:43:30 <joesteele> ddorwin: not advocating that, but just bring it up
23:43:40 <joesteele> JF: we want the hints that tell us whether we are on the right path
23:43:48 <joesteele> ddorwin: maybe the right folks aren;t here
23:44:00 <joesteele> ddavis: the spec say you can have a list of 0 or more cues
23:44:08 <joesteele> ... you could use track element now
23:44:35 <joesteele> cheslip: Mark mentioned mime-types, might want to support that
23:44:58 <joesteele> ... concencus seems to be we could use track, but need to hear from the folks that objected before
23:45:18 <joesteele> jeremy: need to be able to sync that 0 on the first track
23:45:31 <joesteele> MarkVickers: you can play without video
23:45:54 <joesteele> jeremy; the definition is the the track is synchornized to a given source
23:46:05 <joesteele> s/jeremy;/jeremy:/
23:46:29 <joesteele> jeremy: what if there are restrictions involved, how does the application distinguish
23:46:44 <joesteele> MarkVickers: I believe you could play a captions track without playing video
23:46:55 <joesteele> jeremy: I don't think you can do it in a browser
23:47:15 <joesteele> rrsagent, draft minutes
23:47:15 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
23:47:30 <joesteele> paulc: I dropped the link above to the 2012 minutes
23:47:46 <joesteele> .. the discussion of the track element is in those minutes and I encourage folks to look at it
23:48:15 <joesteele> s/.. the discussion/... the discussion/
23:48:45 <joesteele> ... look for the word "mandatory" in those minutes
23:49:05 <joesteele> ... woiuld like to make sure that any presentation covers all the critiques that have been done before, we just came full circle
23:49:15 <joesteele> http://www.w3.org/2012/05/03-html-wg-minutes.html#item06
23:49:46 <joesteele> paulc: I will drop this link in with research
23:49:49 <paulc_> Ted's 2012 research: http://www.w3.org/html/wg/wiki/ISSUE-194/Research
23:50:14 <joesteele> chaals: points about MSE and splicing we need to think about
23:50:34 <joesteele> ... half the msg here is whether putting the link in the video element makes sense
23:50:47 <joesteele> ... any obvious reason why the name would prevent implementing?
23:51:21 <joesteele> ... folks in this room have connections to the right folks in your orgs who can comment on this
23:51:55 <joesteele> JF: the second question is about the transcript element as another element
23:52:05 <joesteele> ... does anyone have any strong feelings on this?
23:53:03 <joesteele> ddorwin: seems like we should go for the right solution, since it has taken so long so far
23:53:23 <joesteele> ... could present what you would really like and ignore the names
23:53:39 <joesteele> chaals: I agree, would be nice to get input from Wev&TV IG and TAG
23:54:04 <joesteele> ... as well. We wanted to know whether there was stuff we have just missed
23:54:19 <joesteele> ... big takeaway is about MSE and splicing
23:54:22 <paulc_> MikeSmith: are you on the phone?
23:55:02 <joesteele> paulc: who are the right people?
23:55:12 <joesteele> chaals: the people who make players,
23:55:24 <joesteele> ... browser native players, players that run in browsers
23:55:54 <joesteele> ... search and content management folks who want to link videos to transcripts
23:55:56 <MikeSmith> paulc_: not on phone yet
23:56:12 <joesteele> ... maybe some assistive technology developers
23:56:15 <paulc_> MikeSmith: okay, we are just finishing up the previous topic
23:56:21 <MikeSmith> Hai
23:56:34 <joesteele> ... and folks who had strong opinions in 2012 (maybe)
23:56:49 <MikeSmith> zakim, call Mike
23:56:55 <MikeSmith> hmm
23:57:02 <joesteele> paulc: we might be doing a disservice by hiding this in the Accessibility TF
23:57:17 <joesteele> chaals: absolutely, this is not really about accessibility
23:57:23 <joesteele> ... not only about accessibility
23:57:34 <joesteele> paulc: the 2nd question is what is the right venue?
23:57:41 <joesteele> chaals: the HTML WG maybe?
23:57:52 <joesteele> ... might need to go to multiple places to make that happen
23:57:58 <joesteele> paulc: I can help with that
23:58:10 <joesteele> rrsagent, draft minutes
23:58:10 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
23:58:34 <joesteele> paulc: I would suggest you take another run while you are here. And then send it out to a candidate list of places
23:58:53 <joesteele> ... public-html, web-and-tv-ig
23:59:03 <joesteele> chaals: thanks
23:59:08 <joesteele> rrsagent, draft minutes
23:59:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
23:59:49 <joesteele> topic: [MSE] Plan for getting MSE out of CR