W3C

- DRAFT -

HTML Media Task Force Teleconference

15 Apr 2015

Agenda

See also: IRC log

Attendees

Present
Paul_Cotton, Glenn_Eguchi, Cory_Heslip, Rustam_Khashimkhodjaev, Daniel_Davis, Joe_Steele, Mark_Vickers, Jeremy_LaCivita, Sahil, Mark_Watson, Matthew_Wolenetz, David_Dorwin, Chris_Wilson, Jerry_Smith
Regrets
Chair
paulc
Scribe
Daniel

Contents


<trackbot> Date: 15 April 2015

<ddavis> scribenick: ddavis

<scribe> scribe: Daniel

<scribe> Meeting: HTML WG Media Task Force F2F (Day 1)

Agenda bashing

paulc: How do we allocate our time between EME and MSE?
... We have a lot of detailed points for EME.
... We asked people to suggest their preferred topics.
... See https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#Potential_Topics
... I'd have thought we need to get some sort of agreement to split EME and MSE time.
... Jerry, Matthew and Mark are the MSE editors.
... We've got CR status at 5pm today.
... The status is that Cyril took at action item to do some work on MSE CR, back in TPAC.
... Apparently there's no update since January.

MattWolenetz: I reduced the initial list of bugs to a few.
... These are listed in https://www.w3.org/wiki/HTML/wg/2015-04-Agenda#MSE
... Only 28465 really requires significant action, I think.

paulc: I'd like to give an update on 27239 because I've been looking into that.
... I've been talking to Dominic and TJ about whether we still need the normative reference.
... That and testing are probably the large items.
... So could we allocate an hour to MSE?
... We could do it after lunch, excluding CR status.
... At 5pm, we should ONLY have the CR status discussion.
... Should we just start with MSE and get them out of the way?

Paul updates the agenda on the wiki.

paulc: How do we organize the EME topics?
... The administrative stuff is at the bottom.
... David, what do you mean by the "interoperability" topic?

ddorwin: I'll update the wiki with a link.

paulc: Shall we take an hour for lunch?
... Taking a vote of how many people will be here at 5pm Thursday.
... So looks like we have critical mass through tomorrow afternoon.
... I suggest we just get started with MSE topics and see how long it takes to get through the non-CR items.
... Matthew do you want to lead?

[MSE] Bug 27239

<paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239

paulc: The history is that we've been waiting for the streams spec to lock down.
... Last week I picked up the thread which pointed to bug #253 in the streams spec.
... I spent a message asking the status.
... The proposal we're talking about is "Readable byte stream"

<paulc_> Readable byte stream proposal: https://github.com/whatwg/streams/blob/master/BinaryExtension.md

paulc: That proposal is not in the stream spec yet - it's a standalone proposal.
... We need to reference that for the streams capability within MSE.
... This bug is stuck.

<paulc_> See status report on streams status: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27239#c4

paulc: The answer I got from Dominic is the issue we should look at is issue #300

<paulc_> Master issue on this implementation is https://github.com/whatwg/streams/issues/300

paulc: There's a series of items that need to be done before moving to stream spec.
... I was referred to Takeshi who said they're going to do the integration next week.
... I'm assuming the MSE spec will be based on the streams spec but I don't if anyone's looked at that proposal.
... As soon as this appears in the streams spec the MSE editors will have to see whether that can be done.

MattWolenetz: I haven't looked into how much change is needed for that.

<paulc_> ETA for integration is now week of Apr 20:https://github.com/whatwg/streams/issues/253#issuecomment-92841148

paulc: All we have to do is continue to wait.

ddorwin: The MSE reference is to the WHATWG spec (on GitHub).

<ddorwin> https://streams.spec.whatwg.org/

<paulc_> Update would occur next week https://github.com/whatwg/streams

paulc: That's where the change will be made next week.
... 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 spec.
... How many people have implementations of that feature?

jdsmith: We don't have that feature.

ddorwin: We should add an issue box to the spec saying this is not stable.
... Search for "appendStream" in the spec for the right section.

<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

ddorwin: Is there anything else for bug #27239?

sahil: Where would the streams spec be if available in the browser?

ddorwin: As appendStream

[MSE] Bug 28465

<LJWatson> 6/server irc.w3.org/6667

<paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28465

paulc: This has been discussed in the last week. Matthew, you seem to be the author.

MattWolenetz: Currently the media element that is from a secure origin disallows use of media content from insecure origins.

<paulc_> See proposal at https://lists.w3.org/Archives/Public/public-html-media/2015Apr/0013.html.

MattWolenetz: This bug is trying to track improving this without introducing securing security regressions.

ddorwin: This bug tracks the fact that MSE generally doesn't allow that.
... This tracks making MSE content the same as regular video content.

MattWolenetz: There is one proposal outstanding for how this might be accomplished.
... Most of it depends on updates to specs outside MSE.
... I don't have extremely deep knowledge of the other specs. My understanding is that the approach presented here is feasible.
... 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.

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.
... This proposal doesn't protect the privacy of the content being viewed.

paulc: You pointed out that nobody had responded directly to this proposal.

<paulc_> Original proposal is at http://lists.w3.org/Archives/Public/public-html-media/2015Feb/0038.html

markw: We feel the whole UI for mixed content is not good. We feel it should be shown the same as insecure sites.
... It's a lot to ask of the user to have a "third category" of security.

ddorwin: This provides authors an option. For someone using MSE but doesn't want to downgrade/upgrade to/from HTTPS.

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.
... Some of the traffic might be going over an insecure pipeline so that messaging could be controlled by the browsers.
... We don't object to the proposal.

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.

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.

geguchi: I'm not sure how we can address this but if you want to be able to do things like convert TLS segments to fragmented MP4 to support TLS everywhere, that's something you can do.

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.
... That's more of a discussion for HTTPS being required.

paulc: So what do we do with this bug? Make it dependent on something else?
... Makes me uncomfortable that before CR we have people saying not against and not for.

BobLund: I'm for it.

paulc: Matthew, do you know what to change to implement this?

MattWolenetz: There's still discussion on this about getting streams work done sufficiently.

ddorwin: In this thread there's ongoing conversations. Is MSE going to change, etc.?
... The debate is dependStream or dependResponse and it's not just a renaming issue.
... We favor dependStream because you need to make sure you don't expose anything from an opaque object.
... Going to rec is dependent on the Streams API anyway.
... 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.

<paulc_> See Domenic's offer to spec what is needed here: http://lists.w3.org/Archives/Public/public-html-media/2015Apr/0023.html

paulc: I also think it would be too hard to spec an opaque object.
... Do you think Dominic is going to do this and make a PR?
... Then we'd be in the same position as the previous bug - depending on a pull request.
... 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.
... so anyone interested would need to discuss it on that pull request thread.
... So we would open up an issue box in the spec saying we have a possible dependency.
... 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.

MattWolenetz: Mainly I was looking to see if there's consensus and no objections to this particular approach.

paulc: Until people see what Dominic does in his pull request it's unlikely we'll be able to drill down into this.

ddorwin: This is more of an FYI.
... Dominic and Anne have more expertise on those APIs.

paulc: I'd call this an active bug and Matthew, we'd ask you to anchor something in the bug, referring to 28465
... I think you should ask Dominic for the pull request so we can refer to it.

MattWolenetz: Makes sense.

[MSE] Bug 27242

<paulc_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242

MattWolenetz: I'll be splitting out the portion of this bug where I added further scenarios.
... Those will be broken up into separate bugs.
... Comment #3 and below - we don't need to discuss at this time.

<paulc_> Matthew will separate the items in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c3 into separate bugs

MattWolenetz: Currently we waiting for feedback for what we should do in out-of-order decode streams.
... If we've not appended a P frame, should we buffer or not.

<paulc_> this bug will concentrate on the question in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242#c2

<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."

MattWolenetz: We want feedback from developers on what the buffer ranges should be.
... 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.
... Have they been buffered or not?

markw: In extreme cases, there are 60 fps but there could be 60 frames that cover 2 seconds.
... 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.

MattWolenetz: That also fits in with the notion of the buffer range.
... It comes down to the application and implementation.

paulc: So what do we do with this bug?

MattWolenetz: I'll update it based on our discussion.

paulc: So tell the app that the range is what you can play.

MattWolenetz: Yes. You have two conditions - one is for the same content but e.g. 60 fps playing 60 frames over two seconds.

paulc: Where does this occur within the spec?

MattWolenetz: I know where within the Chromium code. I'll have to go back and find it in the spec.

paulc: So you're going to break out your additional questions because they're orthogonal.
... And then reply directly to Aaron's original post.
... Rus, do you know how long the next item will take?

rustamk: More than 10 minutes.

paulc: I suggest we have a 10 minute break.

[MSE] Use cases driving additional/alternate content insertion requirements

rustamk: This is not just ads.
... People switch players, streams, etc.
... Any alternate content - we want to be able to seamlessly insert, remove and delete.

<paulc_> See use cases at https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases

rustamk: These use cases describe things you can't do outside the client.
... We're suggesting what we want MSE to support with frame-level accuracy.
... The use cases are well described.
... All the alternate content that comes in, you can't guarantee it's encoded in the same way or has the same profiles.
... For ad use cases, the ad providers get content from all over the place.
... We want to solve the issue for VOD and linear, so it's seamless and the user doesn't notice anything.
... So here are the use cases - how do we solve it?

geguchi: A lot of these use cases came from gaps we identified.
... A lot of them came from one particular section of the MSE spec.

<paulc_> See spec gaps: https://www.w3.org/wiki/HTML/Media_Task_Force/MSE_Ad_Insertion_Use_Cases#Specification_Gaps

geguchi: The content you're appending is constant, or so it's assumed.
... There's a problem if the content is from different sources and is inconsistent, e.g. encoding.
... We could use text track cues but they may not be accurate.
... We could have multiple players and buffers but that's not guaranteed to be supported.
... This section of the spec is important to look at.

paulc: This will push back the status of the MSE spec.

rustamk: In order for MSE to be successful this is a must.

paulc: I know some people see MSE as an extension spec of HTML. Have you considered having this as an extension spec to MSE?
... It could be hooks into MSE.
... So an extension to an extension, or a future proposal that could be merged in.
... A bit like how Robin did the ruby feature for HTML.
... He wrote it as an extension and it was moved in to the main spec.
... But here it sounds like you're being more additive.
... Those options exist and you should consider starting to write a spec, then we'd have some idea of what to do.

MarkVickers: I'd like to hear from the spec authors for guidance. This has come up a few times.
... How much is this an implementation change or a spec change?
... Do people feel this is needed or something we're not going to support?

Matthew: The intent of MSE was to be less about codec API.
... I echo the concerns for better transition but I don't see it as something we should have in MSE now.
... 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.
... How would you set up MSE sources buffers, for example, to handle this?
... Do you see a need for frame-accurate track transitions?

rustamk: I think so, I can see a couple of use cases for source equals.

Matthew: If there's a common requirement with source equal then we might want to address that in the HTML source equal, not MSE.

rustamk: So if we update/extend the spec, is there interest in the overall group for these capabilities?

paulc: So is there any interest in those use cases?

MarkVickers: Nobody's thinking this is getting in the way of MSE getting to Recommendation.
... Let's just talk about are we interested in addressing these use cases in some way.

ddorwin: One issue is to consider whether this is actually an MSE issue or a video issue.
... This could be an implementation issue, so there may be reasons why this could not be implemented.
... Maybe TPAC is a better place for this discussion.
... There's other media work we need to look at.

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.
... Being able to change the tracks might be useful.

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.

jdsmith: Right now, we set up a media pipeline and adding or modifying that is normally not done dynamically.

paulc: Is there a correlation between these use cases and what we're talking to the accessibility people about?

rustamk: There's some correlation. There could be a descriptive audio service available for some content.

paulc: This could be interesting for the accessibility people.

MarkVickers: There's a requirement in the US for content to have descriptions, e.g. descriptive tracks.
... The same thing for text tracks and other languages.
... It's going to become more of an issue.

ddorwin: We're not handling decoders with text tracks.
... Also, we can't specify which codecs people should use but we could have best practices.

rustamk: We still get a variety of content such as progressive/not progressive.

ddorwin: We should suggest how to get best compatibility for features.

MarkVickers: There are non-ad cases such as "movie extras", e.g. on DVDs/BluRays.
... There can be extra commentary or director's cuts.
... You can pre-process it and make it linear but it would be nice if you could deal with it.

markw: There are times when we want to play different segments seamlessly.
... There's an issue with discoverability and the capabilities of different devices.
... We just have to encode everything into every possible format.
... So this issue could be about optimization for a few variety of formats.

MarkVickers: We have linearized things now but if we have an API like this it would help with device capabilities.
... People can improve their pipelines over time.

geguchi: Not all devices can support everything but it would be nice if the API was not limiting.
... It sounds like maybe MSE may not be the right place for these places.

ddavis: GGIE TF in the TV IG has similar use cases

<joesteele> https://www.w3.org/2011/webtv/wiki/GGIE_TF

ddavis: That would be a good place to raise this.

paulc: Previously we've encouraged people to file bugs
... There have been misconceptions about what groups are trying to do, e.g. the Web and TV IG.
... This could be the perfect case of re-starting the relationship with the TV IG.
... We could work together and they could report back to this Media TF.
... Is there any chance these use cases are more pertinent at the media level rather than just MSE?

MarkVickers: There's two kind of engagement. One is at the bug level and that's continued.
... The other is where we wrote big requirements docs which became MSE and EME.
... 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.

ddavis: GGIE would take longer because it's generating requirements from use cases.

rustamk: An extension to MSE might be a better, faster place to start.

ddorwin: MSE is about streams, but this might be a separate issue.

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.

MattWolenetz: One thing maybe missing from the use cases is the source equal case.
... If MSE were to support these use cases, changes would have to be made all over the place.
... If we want to linearize or have multiple tracks, how is that related to source equal?

MarkVickers: That's a good thing to take on - add source equal to the use cases.
... and where should these documents live?

paulc: If we knew the solution was something additional to MSE, one proposal is do a pull request of what you'd change.
... 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.
... 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.
... Tackle the question of what it would take to provide that facility to the media element itself.

ddorwin: EME is on the media element, as an example.
... I don't know the details of the use cases but maybe it's harder to read through Interest Group requirement documents.
... Also some of the issues don't require specs, they just don't have implementations.
... They could be implementation-dependent.
... E.g. synchronization is in the HTML spec but is poorly implemented.

BobLund: About the Media Controller, one of the options is to support multiple media elements with synchronization. What's missing from the Media Controller?

ddorwin: It was implemented in WebKit but no better than what you could do with JavaScript.
... It was not implemented well and was misleading.
... It was a lower priority and wasn't dealt with.
... It might help to champion Media Controller.

geguchi: Is Media Controller designed for playlisting elements?

ddorwin: I don't think so.

geguchi: So it's a different use case.

ddorwin: I wasn't proposing it as a solution, just using it as an example.

geguchi: When you look at the spec, some of it disallows this so it's like a blocker.

paulc: In Robin's "After HTML5" plan, sent to the WG and under discussion, there's a reference to more Media APIs.
... This section of the document talks about what new work might be done - there's an assumption that more is needed for media.
... The reaction we've got is that we haven't pushed individual items.
... What we need to do is to figure out if there's going to be more media discussion, who owns that?
... Might be MSE, Media Controller or something else.
... In other words, there's going to be more media work done but not a good plan.
... The suggestion in Robin's document is for Community Groups to be used.
... It wasn't clear how to choose between Task Forces and Community Groups.

cwilso: There's a lot of discussion on the After HTML5 plan.
... There's some decision making based on how functional the task forces are.
... 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.
... They'll be some movement on this.

<paulc_> See After HTML5 [DRAFT] plan: http://darobin.github.io/after5/html-plan.html

<paulc_> In particular it mentions the possibility of new work in Media APIs:

<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."

ddavis: Two examples of CGs are the Second Screen CG (now WG) and Device Timing CG, which may be incorporated into the HTML spec.

MarkVickers: The simplest thing would be to leave the use cases as they are and expand on that, having more discussion.

paulc: If the Task Force wants to have a new conference call to go through these, I'm happy to start that.
... We've had good feedback today.

MarkVickers: At least for now, these use cases could go through one more iteration within the Task Force.

<scribe> ACTION: paulc to figure out what's going to happen to Media Controller [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action01]

<trackbot> Created ACTION-82 - Figure out what's going to happen to media controller [on Paul Cotton - due 2015-04-22].

<scribe> ACTION: rustamk to update the use cases and contact Paul to set up new discussion [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action02]

<trackbot> Error finding 'rustamk'. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

MarkVickers: You'd need to make the use cases high level enough so that they're not pre-supposing a solution.

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.

<scribe> ACTION: ddavis to point Web and TV IG members to the use case wiki page. [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action03]

<trackbot> Created ACTION-83 - Point web and tv ig members to the use case wiki page. [on Daniel Davis - due 2015-04-22].

<paulc_> ACTION: paulc (really rustamk) to update uses cases and arrange for further discussion [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action04]

<trackbot> Created ACTION-84 - (really rustamk) to update uses cases and arrange for further discussion [on Paul Cotton - due 2015-04-22].

paulc: Let's break for lunch and meet back at 1:15.

<joesteele> scribenick: joesteele

paulc: we will be stepping through the EME agenda now

EME session 1

paulc: David, item #1?

[EME] Interoperability

<ddorwin> https://docs.google.com/presentation/d/1dFCcWC-FH3ghBDQ6fxTc6ABLYcspz9MQ03HYki5e36I/preview?slide=id.p

ddorwin: pasted the link to bring up
... Interop and segmentation are common topics
... wanted to talk about the issues
... previously everything was proprietary
... EME provides the common platform -- expanding the reach (most of this is on the slides)
... description of GPS as an interop use case
... some feature requests for EME prsent the problem of fragmentation as well
... when optional is used for example, optional features are usually discouraged in specs
... should avoid optional features
... Therefore (gives advice on how to judge when adding a feature)
... Other considerations (more advice on what to consider)
... this is where TAG is concerned - should be implemented by lower level building blocks
... Still not convinced? (relating fragmentation/segmentation to common objections raised to EME)
... and formal objections raised to EME
... keep in mind that TAG input will be taken into account for final approval
... (end of slides)

MarkVickers: I think we have accomplished a lot -- what was in the plugin model is now in the HTML5 model
... but it is true that we now have a problem with how things are currently implemented
... from a distributors point of view you could choose one of the two widely distributed plugins and run everywhere
... but now you will have to use different @@models? for each browsers
... this is a step back. This may change over time

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

MarkVickers: I would agree, PSSH is a good example where we could do better
... not really our area, but maybe we should take that on

ddorwin: there is one common PSSH, that may not support all use cases, but does support all in the spec

markw: worth considering where we are
... came from DRM being a fairly opaque thing, over time we have constrained the way certain features work

<circ-user-1ImDm> SETNAME gurupanguji

markw: this is a godo thing, but we did not come to a group conencus that we should do that
... i.e. only the things in the spec should be supported
... fragmentation is a bad thing, but a certain amount was to be expected

<cwilso> circ-user-1lmDm: try "/nick gurupanguji"

markw: user agents interacting with the DRM gives them a certain amount of control
... it is hard to say there should not be optional features because of this
... want the application to get something, although it may not be just what they ask for
... for example pre-requesting licenses
... might not have it, but if you do you can use it

paulc: as far as I know OPTIONAL does not occur i the W3C process doc
... must, should and may are used
... I assume you are not saying EME should only include features that every browser implements?
... that is not what the process doc says, it says we must have at least 2 implementations
... some process docs are much more stringent (core language features may require 5)
... there are lots of W3C spec for which there are not 100% feature support when exiting CR
... you may only have 2 so you know it is implementable
... might set it too high
... so what do you mean by optional in this context?

ddorwin: it is more the spirit of the optional, are we defining things that we know exclude large portions of clients?
... I don't expect every user agent to implement every feature? but are we knowingly defining things only possible on certain clients?

paulc: give me an example of two things that are in the spec that you view as optional

ddorwin: downscaling is optional
... where you should design an app to avoid failing on platforms that do not support it
... I have tried to be clear on how you would use it without breaking other platforms

paulc: your presentation is not black and white in the sense that all optional features are evil
... do you think this should be in the spec or not?

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
... initialization data types, codecs those are also optional
... all HTML issues

paulc: HTML issue 4 -- look that over. THe group may the choice not to define it
... e.g. GIF versus PNG
... that is a very controversial item, all the codec related ones are

ddorwin: not trying to open that can of worms -- just an example of optional

[EME] Secure Origin Requirement

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

<paulc_> See also https://lists.w3.org/Archives/Public/public-html-media/2015Mar/0006.html

paulc: there was a huge amount of discussion on this at the TPAC

<markw> https://docs.google.com/presentation/d/14EfnEzyTG5naAZaujv8AX4xv33Z9zUboefuAr4bwnts/edit?usp=sharing

paulc: lots of other folks in the room for that discussion, TAG folks, etc.

<ddorwin> Better: https://docs.google.com/presentation/d/14EfnEzyTG5naAZaujv8AX4xv33Z9zUboefuAr4bwnts/preview?slide=id.p

<paulc_> See TPAC minutes for 26632: http://www.w3.org/2014/10/30-html-wg-minutes.html#item30

markw: not trying to summarize the whole history
... question is when EME should be restricted to secure origins?
... some cases where the browser should restrict, for example when it needs to decide to whom it is giving permission
... Mixed Content (discussion of current proposal)
... that removes one of the objections to requiring HTTPS because scaling issues go away
... summarizing the recent thread
... don't think a blanket restriction is justified, don't think the current proposal is relevant, mixed content UI is not viable
... Content security modes (discussion of this diagram -- think you should be truthful, but not show as a downgrade)
... Purpose (restating what the purpose of restricting EME to HTTPS would serve)
... things have gotten better with recent normative restrictions on the CDM
... not clear to me that if you are following the recommendations that HTTPS offers you any additional security
... especially since the same folks are often implementing the browser and the CDM
... Proposal (if any of these 3 things hold, secure origin is not required)
... this is responsive to the way TAG raised their comments to us
... they indicated if we could not address with normative requirements, should require secure origin

MarkVickers: are you suggesting the 2nd bullet recommendations are mandatory?

markw: that would be fine for me
... if UA and CDM are happy that would be fine

MarkVickers: agreed

markw: these are recommendations of what the CDM should, but are not well defined enough
... might be a judgment call

MarkVickers: maybe making them mandatory would lead to approval

<paulc_> enrypting identifiers is in http://www.w3.org/TR/encrypted-media/#encrypt-identifiers

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.
... I want the UA to know the security properties of the CDM they are integrating

@@1: the concern is that the person integrating might not have the information to do this

markw: we are saying that they should have that information

@@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

scribe: trustig the plugin imepentato to do the right thing doesn't work

markw: but in this case the UA should know that level of detail on the CDM
... and when you do know you do not need the secure origin

MakrVickers: the closer integration with plugsin was a practical technical thing to do but maybe did not change the legal relationship
... service providers have to protect privacy, contracts require this, the new EME model brings that relationship into this
... when the spec says these things are mandatory you do have the capabilities to do the inspection required, you have the leverage
... no reason you should not feel comfortable
... you could have source code requirements, etc

ddorwin: you might not have source code access, or it might be a platform DRM where you can't get that
... 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
... have to cinsider all user agents, not just the happy path

BobLund: the proposal is not saying everyone has to follow that path, just that if you do you do not have to do that

ddorwin: I would agrue that half do not foloow the happy path

@@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

scribe: 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"
... at that point we should bite the bullet

markw: when the user types HTTPS they get the green padlock, but then at some point it will go orange (because content was loaded)
... don't need to go to much into that
... one of the reocmmendations is that it is put into a separate process, more work there is needed
... 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

ddorwin: there are 3 companies where that is true, sometimes those DRMs are part of the platform (running as root)
... that is not always the case, but in that case it has very different privieldges

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
... I don't think this is a powerfull feature in this case

@@1: we don't always know whether the CDM is following the guidlines,

scribe: we could test this, but would end up with a registry of which CDMs do and which do not

markw: would like to encourage folks to follow the best practices, but hard to make that testable

MarkVickers: you may be using HTTPS code that is part of the platform which you can't see
... it is strange to say "secure == HTTPS"

ddorwin: we do not that !HTTPS is not secure

BobLund: but this is about securing the information between the license server and the application

ddorwin: this is a larger subject than that bug, 128 responses to it changes the direction
... if a user agent does not feel comfortable with a CDM and requires HTTPS that would introduce a difference

markw: annoucing -- we are planning to move all of our services to HTTPS in the coming year.
... 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

jdsmith: was there a specific reason?

<paulc_> See Mark's email on Netflix's usage of HTTPS http://lists.w3.org/Archives/Public/public-html-media/2015Apr/0028.html

markw: the big concern was the content streams being snooped on by ISPs and others

ddorwin: feel like this was a bit of wasted time with this outcome

jdsmith: they did share the information they had at the time

markw: it turned out we were too pessimistic on what the timescale for optimization would be

@@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.

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

cwilso: that is fair. But the challenge is how much do you trust the realtionship between UAs and CDM providers.

BobLund: why do you think it is unverifiable?

cwilso: it might require a reverse engineer

MarkVickers: and you can have non-technical/legal things which would constrain this

<markw> s/too pessimictic on what the cost would be/too pessimictic on what the timescale for optimization would be/

joesteele: you could also have a trusted third party as an intermediary for verification of compliance

MarkVickers: the contract could say, the CDM ust be doing these three things and if there is a proven breach you have liability

<ddorwin> https://docs.google.com/presentation/d/1MxiJbSDlhvBTuJkTx4ns-lmSCMKM8WmEc3LCHuVClms/preview

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
... 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
... in those cases where the UA and CDM are confident that the restrctiions are being made you do not need to make an exception

ddorwin: basic was that SHOULD would be meaningless, it would have become CANT
... some providers would have said we will not support it

markw: we never said we could not, we said that it would be prohibitively expensive and it would take time to work on optimizations
... if a whole bunch of browsers required it tomorrow, it would still be an issue

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

ddorwin: what really matters is the market, need browsers to support it to avoid segmentation
... the spec has a hanging space that does not define this ...

markw: want to go back to the "don't trust CDMs" discussion
... one of the whole advantage of the EME was that it puts the UA in the position of being able to restrict the CDM
... if HTTPS is mandatory this reduces the incentive for UAs and CDMs to do the right thing

ddorwin: some folks will plugin ontop of something and not care about security, HTTPS provides some level of security against that
... now that vendors has to make a choice do they get content or not?
... at the other end you have browser vendors who care a lot and don't think HTTPS absolves them of providing security
... 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

cwilso: the only test you have for that criteria is that the UA is reviewing the CDM
... that is a hard thing to do, especially if the CDM updates
... I don't trust even our own engineers

paulc: those arguments were not used when making TLS mandatory, it is not a MUST

markw: the best engineers in the world write security holes, its not about trusting the engineers

cwilso: the more security we can embed in the stack, the better off we will be overall for defence in depth

jdsmith: some UAs/CDMs may have good security and we are wrapping in an additional layer of security

BobLund: that is good in the absolute case, but it has implications. HTTPS is great but getting the certs to use HTTPS is not.
... wrapping additional security because we can is not the best solution

ddorwin: someone implementing UA on a set top box with no security concerns,
... if it is required (for example by Chromium) with a powerful features check, it will be HTTPS by default
... then everyone will be HTTPS, there will be no motivation to disable if everyone is HTTPS already
... if we could require sites to use HTTPS it would work, but we cannot

markw: writing a MUST into a client spec like this it not a great tactic for convincing companies to invest millions to upgrade

ddorwin: the intent was that this is a talking point and how do we get there?
... we did not solve this in Web Platform. We are not turning on HTTPS tomorrow, but it should be clear where we are headed.
... questions still out there -- What is the cutoff date? when are we moving over?

joesteele: has there been a date discussed yet?

<ddorwin> https://docs.google.com/presentation/d/1MxiJbSDlhvBTuJkTx4ns-lmSCMKM8WmEc3LCHuVClms/preview

ddorwin: that has been blocked by the discussion of whether we need HTTPS
... want to skim through some of the slides again
... Mixed COntent UX --
... problem is that the UX is not accurate
... UX looking worse is an opinion
... Privacy & Security --
... HTTPS is provding more than just message protection and confidentiality
... this is kind of about sandbox versus not sandboxed
... HTTPS is coming (discussion of all the discussion online)
... EME is not alone in trying to address this problem

jdsmith: think that the statement on the Optional page are not agreed
... the UAs that are implementing EME are all invested in security, we are not sure how to control the proliferation

ddorwin: the UAs who have implemented and shipped are thinking about thits, this is more about the long tail
... we are not going to requre some of the normative solutions proposed (i.e. sandboxes)
... Segmentation --
... slides need to be updated -- Netflix indicated they will support this

paulc: who defines what is the right choice?

ddorwin: the right choice for them
... if content providers are not supporting HTTPS these are not really options
... Summary --
... we have a solution for mixed content, but spec is not complete and will cause pushback from the TAG

markw: on mixed content UX
... my concern is the bait and switch of the transition between secure and insecure for the user
... we would prefer to migrate everything instead of suffer the mixed UX
... would still like a better answer to how do we better control the CDM
... if HTTPS is just defense in depth, can we come up with something better
... 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
... would be a good to know when this HTTPS will become mandatory
... probably needs to be an agreement between content providers and browsers

ddorwin: Anna proposed we write "by XYZ date" it will be required and then we will test it

markw: we could write that into the spec -- required after this date

ddorwin: mainly wanted to get at how do we fix this?
... having an MSE mixed content solution changes the game, not requiring providers to switch there CDNs

jeremy: if HTTPS is coming, what do we need to focus on?

ddorwin: the powerful features spec is trying to define "what is an origin that can use a powerful feature"?
... 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.
... there are also efforts to address this in older specs like geolocation and WebRTC

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?

MattWolenetz: is that for a player coming from secure origin?

rustamk: yes

ddorwin: the stream would have to be secure, unless you are using the mixed content UX
... that is how the mixed content works

jeremy: is XMLHR consider a powerful feature?

ddorwin: no -- it is banned from insecure origina
... a few things are optionally-blocked because they would break the web
... other stuff like scripts and XHR are blocked

paulc: how do we move forward?
... do we want the have text that says "HTTPS is required by date XXX?"

jdsmith: at the TPAC there was a lot of support but we did not talk about timeframes

paulc: picking a date seemed to be a problem because some companies were not ready to go there
... are we in the same place now? or can we pick a date?

jdsmith: we have one new piece of info, that Netflix has concluded it is feasible to move.

jeremy: I think the rest of the industry is a couple of years behind Netflix

paulc: for those early implementors who built the EME support for Netflix, have gotten a lot of feedback from users

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.
... it is a question of how much time is appropriate to give companies to move

Brian: does that mean it is not an undue burden? just because it is solvable does not mean it should be solved

paulc: after 1.5 hours of discussion on this, do we have a concrete proposal for test to go in the document?
... I can go around the room and ask

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.
... The task then would be for the browser vendors to talk their customer and determine a timeline for deprecating
... Need to give certainty to folks getting ready to invest in a move to EME
... Can't work it out here because we don't have the right people.

ddorwin: We can put what I have on the "Proposal" slide IF the requirements are not met

markw: if this is not a secure origin, UA's SHALL reject if the other requirements are not met

paulc: would like to have a real date for when I go to the Director
... not a bikeshed
... we can make this a priority feedback item for Last Call

markw: don't want to put a date in the spec because this might not be the right place to make the decision
... UAs would want to make that decision themselves

paulc: true -- there are more than 4-5 user agents
... this is not a decision the browser vendors here can decide on

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"
... if this set of requirements is true, the browser can choose to not require secure origins but we are moving in that direction

paulc: Mark, any change you would block the spec until we have a date in the recommendation?

cwilso: think within two years you will have a decision on this
... if you could, this part of the spec would go away

markw: I would be fine with noting that we expect this requirement will be upgraded in the future

cwilso: the stronger that signal is, the better for us

ddorwin: I would like to state our end game

paulc: that is what SHOULD does

jdsmith: if a large # of sites are still running HTTP in the future turning it on will be a problem

rustamk: that is why we need to comunicate to all the partners as soon as possible

cwilso: think it should be strong than SHOULD, explicitly state that this is an exception

paulc: that is called a deprecated feature in standards parlance
... we could write this that way from the start
... normally that is done in multiple versions of the spec
... this would be a strong warning

rustamk: what stops a UA from turning it off now?

paulc: that is the intent
... want to minimize the number of UAs that are dependent on the deprecated feature

jdsmith: thought we wanted to encourage services to support HTTPS?

cwilso: this is an indicator to content hosts that they will have to move sooner or later

paulc: david said "we write specs for UAs not web sites", we are telling sites that this thing is going away

ddorwin: synchronous XHR is a good example

paulc: is there consensus if we go in that direction?

ddorwin: yes

markw: that is what I said

MarkVickers: I don't understand the conditional part, the conditional parts should be mandatory
... 1st bullet
... 2nd bullet we should go through
... 3rd bullet - don't understand that one
... rather make it the case that even with HTTPS all of them should be mandatory
... some of which are recommendations today
... for example some CDMs not protecting their data even though HTTPS is being used

markw: the idea was that HTTPS gives you confidentiality, and identifiers that could be exposed will not be using HTTPS

joesteele: our protocol will meet the requirements/recommendations with or without HTTPS so it will not impact us

ddorwin: there are unreachable points in the spec that need to be cleaned up
... the point of doing that was that people may ignore some parts of the spec
... but implementor will be reading the algorithms

MarkVickers: maybe those requirements should be in the algorithms then

ddorwin: could do some of that in say "send a message"
... there are also things that do not fit cleanly
... there are editing things we could do
... happy to have more normative stuff, help wanted

MarkVickers: are there recommendations that can be mandatory?

ddorwin: I have tried to make everything I can, mandatory

jdsmith: requirements in there are more normative now
... we want to encourage folks to use HTTPS as it will be required at some point
... I am more tempted to say that "You should expect HTTPS will be required at some point"

markw: The identifier should be called out as not being exposable during an interim period while HTTPS is not required
... we expect the CDM to meet all the requirements so that they could be exposed over HTTP
... and then say HTTPS may be required for defence in depth

paulc: David and Mark can you come up with some text for this by EOD tomorrow
... proposal to to detach the statement about HTTPS from the requirement bullets

jdsmith: what is meant by per-site permissions?

markw: for example, a dialog saying "allow netflix.com" to use EME

ddorwin: I agree with the deprecated path, but we need to figure out what that IF statement is

markw: I would also like to encourage CDMs to be sufficiently safe to not require HTTPS

ddorwin: exposing a fixed hardware identifier is an example

markw: that is not allowed

ddorwin: that is still a UA decision

paulc: break for 10 minutes

[EME] Issue 45 - Remove "persistent-release" session

[EME] Issue 45 - Remove "persistent-release-message" MediaKeySessionType

<ddorwin> https://docs.google.com/presentation/d/1k_a3TqPyopLbrbjUseuS2rVhATaccelsqVQZ9EnDZhE/preview?slide=id.p

paulc: please get the issues out and hold the questions for now -- we have guests coming in

ddorwin: History
... has not been a concrete definition as yet
... Current Status (still undefined)
... Proposal (remove the undefined value and have Mark file bugs for what is needed)
... this would address the immediate concern and leave a path forward to addressing Marks concerns

paulc: any questions?

jdsmith: are you saying the current specification is not enough today?

ddorwin: yes
... only a couple of notes about behavior
... concern is that it will not be interoperable if implemented

<markw> https://docs.google.com/a/netflix.com/presentation/d/1xhihHWL7Vpu0dX4aPYsT1-4ajtZTRqQ3wQvF_yCWyMk/edit#slide=id.p

markw: Secure release (description of what it is)
... Could drop the "May"
... Concurrent stream limits (purpose is to enable this feature)
... could be enforced in Javascript but not robust enough and could allow automated account sharing by cirumventing
... Three approaches (real-time and non-real-time)
... approach depends on context (e.g. native apps, browsers)
... Javascript approahc is real-time, CDM approach is non-real-time
... Marks Comments (real-time not good enough, non-real-time is)
... has negative implications for server infrastructure being real-time
... this was proposed very early on and was left as blackbox by design
... think there are things remaining to be spec'd but were waiting for additional implementation experience
... seems like David wants details about what is in that message, but has been CDM-specific
... my suggestion is that it remain that way

ddorwin: I was referring more to behavior rather than contents
... is this actually deployed in user agents?

markw: yes

ddorwin: ok wanted to have this discussion
... we do not believe real-time is practical for any platform
... non-real is deployed on many platforms
... would like some data on what kinds of problems are being solved by this?

markw: we are working with folks to implement this and it is in the field today
... if it is removed entirely, folks will have to make proprietary extensions to support this
... that would be unfortunate
... we can certainly fill in missing details
... I hear the concerns about reporting details
... unnecesary to do the real-time thing
... I can't publish our data about error rates
... Fundamentally either you require the license server to be online for the stream to continue or you do not
... I don't hold out much hope for a renewal based solution

ddorwin: the application is repsonsible for keeping the servers up, not the client
... think that is the wrong approach
... re: implementing their own things, I would argue folks are doing that already
... the concern is segmentation. Absent this feature all CDMs should get access to content, except Netflix.
... so it becomes non-optional
... we should not pretend that real-time will not be a requirement in the future

paulc: think we should go back to the original agenda at this point
... Accessibility visitors have a presentation

MarkVickers: I have a security expert who would like to speak on this tomorrow

paulc: how about 11am PST?

Transcript Accessibility

<paulc_> https://www.w3.org/WAI/PF/HTML/wiki/Full_Transcript

chaals: this comes from HTML issue 194

<paulc_> See http://www.w3.org/html/wg/tracker/issues/194

chaals: how do you find transcripts for video?
... for example you are not actually watching the video

<JF> Proposal under discussion: https://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement

chaals: you are blind, you are in a meeting, you just want to skip to the useful bits, etc.
... lots of reasons you might want the transcript
... today there is no common way of doing that
... we are here because you as the Media TF know about media on the web and want a sanity check
... 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
... would also like an HTML element called <transcript> used for wrapping transcripts
... explained the use cases in the wiki page
... sometimes the transcript is on the same page as the video
... sometimes they are external
... sometimes you have multiple transcripts, text, audio transcriptions, alternate language dub
... as a search engine we want folks to be able to find videos
... one thing that is harder is to use a snippet from the dialog of the video to find the video
... this should be easy to do given the transcripts available
... should be able to use those transcripts for this use case
... should not be a hard technical problem
... transcript might only be available as a PDF -- would like to link in this case
... someone uses a "Daisy" player, would like to link to the Daisy transcript
... Requirements are on the web page
... R1 -- R5
... Proposed solutions. We want a way to link a video to a transcript
... attribute on the video element has been discussed, having multiple transcripts on the video is a problem
... 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
... (this is partially a bikeshed argument -- we don't care)
... could use a transcript element, but don't want to block this off while we wait??
... we prefer the <link rel="transcript" > construct
... (discussion of the wiki page markup)
... we don't think the transcript element is necessary if we get the link "rel"
... this also simplified the probably edge case of multiple transcripts
... this would let us know where the transcripts begin and end
... would like for folks to agree that we can produce and consume this construct

paulc: why was this never dealt with before?

chaals: various reasons, some folks have preferred transcript element right up to today
... looks kinda like the longdesc which might have impacted this discussion
... lots of discussions on this still going on

<paulc_> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964

chaals: is this obviously insane or a dumb approach? can you imagine consuming or producing?

ddavis: think that linking to transcripts is important
... in the video element you can have multiple sources
... inconsistent for link to be outside -- should be consistent with sources
... agree that you do not know where it ends -- but don't think that is a big issue

chaals: could use source or track instead but folks objected
... can have multiple links inside and folks are using that for embedded data

cheslip: the transcript container has a landmark element similar to nav

JF: not knowing where it ends is a problem, similar problem with footnotes

ddorwin: according to MDN link can only be in a head element
... have you explored using custom elements to prove its usefulness

chaals: not yet
... core of what we want is something in the video element that gets exposed

ddorwin: and another issue is what the UX expected is?

chaals: video points to the transcript
... some players wants to allow you to scroll around the transcript and then sync back to the location in the video at that point
... folks are not very specific

MarkVickers: you would need timing info right?

chaals: you can have links which point to a timed thing in the video

ddavis: you are saying you can use timed tracks?

chaals: yes

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?

chaals: this has not been explored
... we have explored "you have a link"

BobLund: that would be a difference between MSE and source=

MattWolenetz: source= is more of a static resource
... use case #3 mentions synchronization from the transcript is required, curious how that got much pushback from track

JF: when transcript is static it reads more like a screenplay, would not normally have timestamps
... now we can do interactive transcripts -- at least one producer is doing that by embedding timestamps for every word in the transcript
... linking back to original video

cheslip: this is really a landmark

jdsmith: so you do not envision a default transcript reader?

chaals: right
... and a lot of the use cases I envision there is a user will preferentially read some large presentations and not others

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.

JF: that is interesting

BobLund: why could the tracks not be just a single queue

chaals: you could but browsers objected
... we think that is a bikeshed issue but it has not gotten resolved

paulc: when was this conversation?

JF: F2F 2012 in Microsoft

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.
... 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.

<paulc_> See http://www.w3.org/2012/05/03-html-wg-minutes.html#item06 for the April 2012 discussion of ISSUE-194

ddorwin: like our earlier discussion on splicing content, it seems like the transcript should be related to a time
... that time may default to zero, but then you may have 5 and 10 and 30, etc.
... because thier are two related things here, seems like an architectural issue

chaals: my expectation of the default transcript format is HTML
... because browsers are good at that
... we want to set that expectation, but we don't want to break the case where folks have a PDF
... we should think more about that

JF: you are right about the tight binding, we want to be as generic as possible

MarkVickers: there are backwards ways of dealing with things -- like mime-types
... if we think it is important we have a set of these, we should define that set
... give people a target of a good transcript to go to

ddorwin: one potential option is a shell file like WebVTT
... would have times and could have additional times later

chaals: what you get today usuauly is an HTML document
... the reference will often be done with a URL
... we have punted that decision to URLs because that is already there
... sound like we are describing best practice, ie. do things that work in browsers or players
... if we had said you should be using HTML+ that would changes things

JF: you have mentioend track twice, we got a lot of feedback from an implementor on this.

ddorwin: not advocating that, but just bring it up

JF: we want the hints that tell us whether we are on the right path

ddorwin: maybe the right folks aren;t here

ddavis: the spec say you can have a list of 0 or more cues
... you could use track element now

cheslip: Mark mentioned mime-types, might want to support that
... concencus seems to be we could use track, but need to hear from the folks that objected before

jeremy: need to be able to sync that 0 on the first track

MarkVickers: you can play without video

jeremy: the definition is the the track is synchornized to a given source
... what if there are restrictions involved, how does the application distinguish

MarkVickers: I believe you could play a captions track without playing video

jeremy: I don't think you can do it in a browser

paulc: I dropped the link above to the 2012 minutes
... the discussion of the track element is in those minutes and I encourage folks to look at it
... look for the word "mandatory" in those minutes
... woiuld like to make sure that any presentation covers all the critiques that have been done before, we just came full circle

http://www.w3.org/2012/05/03-html-wg-minutes.html#item06

paulc: I will drop this link in with research

<paulc_> Ted's 2012 research: http://www.w3.org/html/wg/wiki/ISSUE-194/Research

chaals: points about MSE and splicing we need to think about
... half the msg here is whether putting the link in the video element makes sense
... any obvious reason why the name would prevent implementing?
... folks in this room have connections to the right folks in your orgs who can comment on this

JF: the second question is about the transcript element as another element
... does anyone have any strong feelings on this?

ddorwin: seems like we should go for the right solution, since it has taken so long so far
... could present what you would really like and ignore the names

chaals: I agree, would be nice to get input from Wev&TV IG and TAG
... as well. We wanted to know whether there was stuff we have just missed
... big takeaway is about MSE and splicing

<paulc_> MikeSmith: are you on the phone?

paulc: who are the right people?

chaals: the people who make players,
... browser native players, players that run in browsers
... search and content management folks who want to link videos to transcripts

<MikeSmith> paulc_: not on phone yet

chaals: maybe some assistive technology developers

<paulc_> MikeSmith: okay, we are just finishing up the previous topic

<MikeSmith> Hai

chaals: and folks who had strong opinions in 2012 (maybe)

<MikeSmith> hmm

paulc: we might be doing a disservice by hiding this in the Accessibility TF

chaals: absolutely, this is not really about accessibility
... not only about accessibility

paulc: the 2nd question is what is the right venue?

chaals: the HTML WG maybe?
... might need to go to multiple places to make that happen

paulc: I can help with that
... I would suggest you take another run while you are here. And then send it out to a candidate list of places
... public-html, web-and-tv-ig

chaals: thanks

Summary of Action Items

[NEW] ACTION: ddavis to point Web and TV IG members to the use case wiki page. [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action03]
[NEW] ACTION: paulc (really rustamk) to update uses cases and arrange for further discussion [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action04]
[NEW] ACTION: paulc to figure out what's going to happen to Media Controller [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action01]
[NEW] ACTION: rustamk to update the use cases and contact Paul to set up new discussion [recorded in http://www.w3.org/2015/04/15-html-media-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/04/16 18:14:38 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/W3C //
Succeeded: s/@@@/sahil:/
Succeeded: s/@@@ segments/TLS segments to fragmented MP4/
Succeeded: s/@@@/buffer/
Succeeded: s/@@@/text track/
Succeeded: s/inly/only/
Succeeded: s/gorup/group/
Succeeded: s/pessimictic/pessimistic/
Succeeded: s/@@1:/cwilso:/
Succeeded: 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/
FAILED: s/too pessimictic on what the cost would be/too pessimictic on what the timescale for optimization would be/
Succeeded: s/too pessimistic on what the cost would be/too pessimistic on what the timescale for optimization would be/
Succeeded: s/it would be prohibitively expensive/it would be prohibitively expensive and it would take time to work on optimizations/
Succeeded: s/menaingless/meaningless/
Succeeded: s/thourhg/through/
Succeeded: s/scure/secure/
Succeeded: s/requirded/required/
Succeeded: s/@@2/Brian/
Succeeded: s/service to support/services to support/
Succeeded: s/and then/... and then/
Succeeded: s/paul:/paulc:/
Succeeded: s/Comment (/Marks Comments (/
Succeeded: s/reamin/remain/
Succeeded: s/elemtn/element/
Succeeded: s/to NDN/to MDN/
Succeeded: s/jeremy;/jeremy:/
Succeeded: s/.. the discussion/... the discussion/
WARNING: No scribe lines found matching ScribeNick pattern: <Daniel> ...
Found ScribeNick: ddavis
Found Scribe: Daniel
Found ScribeNick: joesteele
ScribeNicks: ddavis, joesteele

WARNING: No "Present: ... " found!
Possibly Present: Better BobLund Brian JF LJWatson MakrVickers MarkVickers MattWolenetz Matthew MikeSmith active adrianba chaals cheslip circ-user-1ImDm circ-user-1lmDm conferences cwilso cyns ddavis ddorwin ericde geguchi html-media https jdsmith jeremy jlacivita joesteele joined left markw minutes next none pangu paulc paulc_ rustamk sahil scheduled scribenick start to trackbot wolenetz
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: https://www.w3.org/wiki/HTML/wg/2015-04-Agenda
Found Date: 15 Apr 2015
Guessing minutes URL: http://www.w3.org/2015/04/15-html-media-minutes.html
People with action items: ddavis paulc really rustamk

[End of scribe.perl diagnostic output]