16:31:31 RRSAgent has joined #html-media
16:31:31 logging to http://www.w3.org/2015/04/15-html-media-irc
16:31:33 RRSAgent, make logs public
16:31:33 Zakim has joined #html-media
16:31:35 Zakim, this will be 63342
16:31:35 I do not see a conference matching that name scheduled within the next hour, trackbot
16:31:36 Meeting: HTML Media Task Force Teleconference
16:31:36 Date: 15 April 2015
16:32:03 zakim, who is on the phone?
16:32:03 sorry, paulc, I don't know what conference this is
16:32:04 On IRC I see RRSAgent, paulc, trackbot, adrianba
16:32:25 zakim, list conferences
16:32:25 I see no active conferences and none scheduled to start in the next 15 minutes
16:36:28 BobLund has joined #html-media
16:38:28 ddorwin has joined #html-media
16:38:50 ddavis has joined #html-media
16:38:55 cheslip has joined #html-media
16:39:19 cyns has joined #html-media
16:39:21 geguchi has joined #html-media
16:39:28 wolenetz has joined #html-media
16:39:53 MattWolenetz has joined #html-media
16:40:30 zakim, who is on the phone?
16:40:30 sorry, paulc, I don't know what conference this is
16:40:31 On IRC I see MattWolenetz, geguchi, cyns, cheslip, ddavis, ddorwin, BobLund, Zakim, RRSAgent, paulc, trackbot, adrianba
16:40:36 JF has joined #html-media
16:41:11 zakim, this is 63342
16:41:11 sorry, ddavis, I do not see a conference named '63342' in progress or scheduled at this time
16:41:14 rustamk has joined #html-media
16:41:25 zakim, this will be 63342
16:41:25 I do not see a conference matching that name scheduled within the next hour, ddavis
16:41:29 LJWatson has joined #html-media
16:41:33 zakim, this is HTML_WG(MEDIA)
16:41:33 sorry, ddavis, I do not see a conference named 'HTML_WG(MEDIA)' in progress or scheduled at this time
16:41:38 zakim, this will be HTML_WG(MEDIA)
16:41:38 I do not see a conference matching that name scheduled within the next hour, ddavis
16:42:19 sahil has joined #html-media
16:42:59 paulc_ has joined #html-media
16:51:11 zakim, who is on the phone?
16:51:11 sorry, paulc_, I don't know what conference this is
16:51:13 On IRC I see paulc_, LJWatson, rustamk, JF, MattWolenetz, geguchi, cyns, cheslip, ddavis, ddorwin, BobLund, Zakim, RRSAgent, paulc, trackbot, adrianba
16:52:03 Agenda: https://www.w3.org/wiki/HTML/wg/2015-04-Agenda
16:57:43 scribenick: ddavis
16:57:54 scribe: Daniel
16:58:13 Meeting: HTML WG Media Task Force F2F (Day 1)
16:58:18 Chair: paulc
16:58:43 Topic: Agenda bashing
16:58:55 paulc: How do we allocate our time between EME and MSE?
16:59:03 paulc: We have a lot of detailed points for EME.
16:59:16 ... We asked people to suggest their preferred topics.
16:59:39 ... See https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#Potential_Topics
17:00:18 ... I'd have thought we need to get some sort of agreement to split EME and MSE time.
17:00:34 ... Jerry, Matthew and Mark are the MSE editors.
17:00:54 ... We've got CR status at 5pm today.
17:01:12 ... The status is that Cyril took at action item to do some work on MSE CR, back in TPAC.
17:01:59 ... Apparently there's no update since January.
17:02:49 MattWolenetz: I reduced the initial list of bugs to a few.
17:03:19 ... These are listed in https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#MSE
17:04:33 cwilso has joined #html-media
17:04:34 ... Only 28465 really requires significant action, I think.
17:04:54 paulc: I'd like to give an update on 27239 because I've been looking into that.
17:05:17 ... I've been talking to Dominic and TJ about whether we still need the normative reference.
17:05:26 ... That and testing are probably the large items.
17:05:33 ... So could we allocate an hour to MSE?
17:05:53 ... We could do it after lunch, excluding CR status.
17:06:04 ... At 5pm, we should ONLY have the CR status discussion.
17:06:32 ... Should we just start with MSE and get them out of the way?
17:07:23 Paul updates the agenda on the wiki.
17:07:39 paulc: How do we organize the EME topics?
17:07:56 jdsmith has joined #html-media
17:07:56 ... The administrative stuff is at the bottom.
17:08:30 ... David, what do you mean by the "interoperability" topic?
17:08:41 ddorwin: I'll update the wiki with a link.
17:09:52 paulc: Shall we take an hour for lunch?
17:11:31 ... Taking a vote of how many people will be here at 5pm Thursday.
17:11:51 ... So looks like we have critical mass through tomorrow afternoon.
17:12:09 ... 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 ... Matthew do you want to lead?
17:13:15 Topic: [MSE] Bug 27239
17:13:19 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239
17:13:38 paulc: The history is that we've been waiting for the streams spec to lock down.
17:13:56 ... Last week I picked up the thread which pointed to bug #253 in the streams spec.
17:14:05 ... I spent a message asking the status.
17:14:32 ... The proposal we're talking about is "Readable byte stream"
17:14:36 Readable byte stream proposal: https://github.com/whatwg/streams/blob/master/BinaryExtension.md
17:14:53 paulc: That proposal is not in the stream spec yet - it's a standalone proposal.
17:15:04 ... We need to reference that for the streams capability within MSE.
17:15:09 sahil has joined #html-media
17:15:10 ... This bug is stuck.
17:15:30 See status report on streams status: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239#c4
17:15:47 ... The answer I got from Dominic is the issue we should look at is issue #300
17:15:54 Master issue on this implementation is https://github.com/whatwg/streams/issues/300
17:16:18 paulc: There's a series of items that need to be done before moving to stream spec.
17:16:51 ... I was referred to Takeshi who said they're going to do the integration next week.
17:16:56 LJWatson has joined #html-media
17:17:10 ... 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 ... As soon as this appears in the streams spec the MSE editors will have to see whether that can be done.
17:17:47 MattWolenetz: I haven't looked into how much change is needed for that.
17:17:59 ETA for integration is now week of Apr 20:https://github.com/whatwg/streams/issues/253#issuecomment-92841148
17:18:17 paulc: All we have to do is continue to wait.
17:19:04 ddorwin: The MSE reference is to the WHATWG spec (on GitHub).
17:19:11 https://streams.spec.whatwg.org/
17:19:13 Update would occur next week https://github.com/whatwg/streams
17:19:14 paulc: That's where the change will be made next week.
17:19:41 ... 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 s/W3C //
17:20:00 paulc: How many people have implementations of that feature?
17:20:14 jdsmith: We don't have that feature.
17:20:30 ddorwin: We should add an issue box to the spec saying this is not stable.
17:21:20 ... Search for "appendStream" in the spec for the right section.
17:21:38 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 ... Is there anything else for bug #27239?
17:23:26 @@@ Where would the streams spec be if available in the browser?
17:23:32 ddorwin: As appendStream
17:24:17 s/@@@/sahil:/
17:24:26 Topic: [MSE] Bug 28465
17:24:27 6/server irc.w3.org/6667
17:24:36 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28465
17:24:57 markw has joined #html-media
17:25:05 paulc: This has been discussed in the last week. Matthew, you seem to be the author.
17:26:05 MattWolenetz: Currently the media element that is from a secure origin disallows use of media content from insecure origins.
17:26:26 See proposal at https://lists.w3.org/Archives/Public/public-html-media/2015Apr/0013.html.
17:26:32 ... This bug is trying to track improving this without introducing securing security regressions.
17:26:55 ddorwin: This bug tracks the fact that MSE generally doesn't allow that.
17:27:11 ... This tracks making MSE content the same as regular video content.
17:27:25 MattWolenetz: There is one proposal outstanding for how this might be accomplished.
17:27:33 ... Most of it depends on updates to specs outside MSE.
17:28:05 ... I don't have extremely deep knowledge of the other specs. My understanding is that the approach presented here is feasible.
17:28:46 ... 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 has joined #html-media
17:29:16 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 ... This proposal doesn't protect the privacy of the content being viewed.
17:29:53 paulc: You pointed out that nobody had responded directly to this proposal.
17:30:00 Original proposal is at http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0038.html
17:30:20 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 ... It's a lot to ask of the user to have a "third category" of security.
17:31:20 ddorwin: This provides authors an option. For someone using MSE but doesn't want to downgrade/upgrade to/from HTTPS.
17:32:12 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 ... Some of the traffic might be going over an insecure pipeline so that messaging could be controlled by the browsers.
17:32:52 ... We don't object to the proposal.
17:33:33 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 has joined #html-media
17:34:11 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 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 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 ddorwin: That's more of a discussion for HTTPS being required.
17:36:18 paulc: So what do we do with this bug? Make it dependent on something else?
17:36:35 paulc: Makes me uncomfortable that before CR we have people saying not against and not for.
17:36:38 BobLund: I'm for it.
17:36:56 paulc: Matthew, do you know what to change to implement this?
17:37:16 MattWolenetz: There's still discussion on this about getting streams work done sufficiently.
17:37:47 ddorwin: In this thread there's ongoing conversations. Is MSE going to change, etc.?
17:38:07 ... The debate is dependStream or dependResponse and it's not just a renaming issue.
17:38:29 ... We favor dependStream because you need to make sure you don't expose anything from an opaque object.
17:38:40 ... Going to rec is dependent on the Streams API anyway.
17:39:09 ... 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 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 paulc: I also think it would be too hard to spec an opaque object.
17:39:52 ... Do you think Dominic is going to do this and make a PR?
17:40:11 ... Then we'd be in the same position as the previous bug - depending on a pull request.
17:40:39 ... 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 ... so anyone interested would need to discuss it on that pull request thread.
17:41:15 ... So we would open up an issue box in the spec saying we have a possible dependency.
17:41:40 ... 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 MattWolenetz: Mainly I was looking to see if there's consensus and no objections to this particular approach.
17:42:39 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 ddorwin: This is more of an FYI.
17:43:08 ... Dominic and Anne have more expertise on those APIs.
17:43:22 s/@@@ segments/TLS segments to fragmented MP4/
17:43:47 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 paulc: I think you should ask Dominic for the pull request so we can refer to it.
17:44:32 MattWolenetz: Makes sense.
17:44:54 Topic: [MSE] Bug 27242
17:44:59 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242
17:45:14 rrsagent, generate the minutes
17:45:14 I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html paulc_
17:45:50 MattWolenetz: I'll be splitting out the portion of this bug where I added further scenarios.
17:46:00 ... Those will be broken up into separate bugs.
17:46:20 ... Comment #3 and below - we don't need to discuss at this time.
17:46:40 Matthew will separate the items in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c3 into separate bugs
17:47:00 MattWolenetz: Currently we waiting for feedback for what we should do in out-of-order decode streams.
17:47:26 ... If we've not appended a P frame, should we @@@ or not.
17:47:41 this bug will concentrate on the question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c2
17:48:15 s/@@@/buffer/
17:48:37 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 MattWolenetz: We want feedback from developers on what the buffer ranges should be.
17:49:44 ... 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 ... Have they been buffered or not?
17:50:35 markw: In extreme cases, there are 60 fps but there could be 60 frames that cover 2 seconds.
17:51:03 ... 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 MattWolenetz: That also fits in with the notion of the buffer range.
17:52:02 ... It comes down to the application and implementation.
17:52:15 paulc: So what do we do with this bug?
17:52:26 MattWolenetz: I'll update it based on our discussion.
17:52:40 paulc: So tell the app that the range is what you can play.
17:52:42 sahil has joined #html-media
17:52:46 sahil has left #html-media
17:53:08 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 paulc: Where does this occur within the spec?
17:53:56 MattWolenetz: I know where within the Chromium code. I'll have to go back and find it in the spec.
17:54:30 paulc: So you're going to break out your additional questions because they're orthogonal.
17:54:42 ... And then reply directly to Aaron's original post.
17:55:23 ... Rus, do you know how long the next item will take?
17:55:31 rustamk: More than 10 minutes.
17:55:43 paulc: I suggest we have a 10 minute break.
17:57:13 zakim, who's here?
17:57:13 sorry, ddavis, I don't know what conference this is
17:57:15 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 has joined #html-media
18:14:07 rustamk has joined #html-media
18:15:14 rrsagent, draft minutes
18:15:14 I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html joesteele
18:16:17 Topic: [MSE] Use cases driving additional/alternate content insertion requirements
18:16:41 rustamk: This is not just ads.
18:16:53 ... People switch players, streams, etc.
18:16:59 paulc_ has joined #html-media
18:17:08 rrsagent, generate the minutes
18:17:08 I have made the request to generate http://www.w3.org/2015/04/15-html-media-minutes.html paulc_
18:17:12 ... Any alternate content - we want to be able to seamlessly insert, remove and delete.
18:17:19 See use cases at https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases
18:17:24 ... These use cases describe things you can't do outside the client.
18:17:42 rustamk: We're suggesting what we want MSE to support with frame-level accuracy.
18:17:56 ... The use cases are well described.
18:18:18 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 ... For ad use cases, the ad providers get content from all over the place.
18:19:12 ... We want to solve the issue for VOD and linear, so it's seamless and the user doesn't notice anything.
18:19:24 ... So here are the use cases - how do we solve it?
18:20:00 geguchi: A lot of these use cases came from gaps we identified.
18:20:24 ... A lot of them came from one particular section of the MSE spec.
18:20:24 See spec gaps: https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases#Specification_Gaps
18:20:53 geguchi: The content you're appending is constant, or so it's assumed.
18:21:09 ... There's a problem if the content is from different sources and is inconsistent, e.g. encoding.
18:21:12 jdsmith has joined #html-media
18:21:26 ... We could use @@@ cues but they may not be accurate.
18:21:31 jdsmith has joined #html-media
18:21:43 ... We could have multiple players and buffers but that's not guaranteed to be supported.
18:21:55 ... This section of the spec is important to look at.
18:22:37 paulc: This will push back the status of the MSE spec.
18:22:48 rustamk: In order for MSE to be successful this is a must.
18:23:25 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 paulc: It could be hooks into MSE.
18:23:58 ... So an extension to an extension, or a future proposal that could be merged in.
18:24:13 ... A bit like how Robin did the ruby feature for HTML.
18:24:26 ... He wrote it as an extension and it was moved in to the main spec.
18:24:34 ... But here it sounds like you're being more additive.
18:24:56 ... 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 MarkVickers: I'd like to hear from the spec authors for guidance. This has come up a few times.
18:25:26 ... How much is this an implementation change or a spec change?
18:25:50 ... Do people feel this is needed or something we're not going to support?
18:26:11 Matthew: The intent of MSE was to be less about codec API.
18:26:41 ... I echo the concerns for better transition but I don't see it as something we should have in MSE now.
18:27:07 ... 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 ... How would you set up MSE sources buffers, for example, to handle this?
18:27:38 ... Do you see a need for frame-accurate track transitions?
18:27:53 rustamk: I think so, I can see a couple of use cases for source equals.
18:28:21