See also: IRC log
<trackbot> Date: 15 April 2015
<ddavis> scribenick: ddavis
<scribe> scribe: Daniel
<scribe> Meeting: HTML WG Media Task Force F2F (Day 1)
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?
<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
<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.
<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.
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
paulc: David, item #1?
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
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
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: 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?
<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
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]