- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 30 Sep 2013 09:22:09 +0200
- To: public-media-capture@w3.org
Hi,
The (unprocessed) minutes of our call last month (Aug 28) are available
at:
http://www.w3.org/2013/08/28-mediacap-minutes.html (copied as text
below)
Josh indicated he might produce a cleaned up version later on, but in
the meantime, hopefully these raw minutes can be a useful point of
reference.
Dom
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Media Capture Task Force Teleconference
28 Aug 2013
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-media-capture/2013Aug/0165.html
See also: [3]IRC log
[3] http://www.w3.org/2013/08/28-mediacap-irc
Attendees
Present
+1.403.244.aaaa, Dan_Burnett, Cullen_Jennings, stefanh,
Josh_Soref, gmandyam, +91.22.39.14.aabb, Jim_Barnett,
fjh, +33.2.31.26.aacc, +1.610.889.aadd, dom, jesup,
+1.510.996.aaee, +1.650.241.aaff, +46.1.07.14.aagg,
stephane_cazeaux, +1.650.678.aahh, adambe, hta,
+1.650.678.aaii, +1.650.678.aajj, ekr, +1.510.996.aakk,
jbraddock, Frederick_HIrsch, Balwinder_Kaur
Regrets
Chair
stefanh, hta
Scribe
Josh_Soref
Contents
* [4]Topics
1. [5]Minutes Approval
2. [6]Media Capture and Streams
3. [7]Test Suite
4. [8]Bugs
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 28 August 2013
<scribe> scribe: Josh_Soref
<scribe> scribenick: timeless
Minutes Approval
<stefanh>
[10]http://lists.w3.org/Archives/Public/public-media-capture/20
13May/0061.html
[10]
http://lists.w3.org/Archives/Public/public-media-capture/2013May/0061.html
stefanh: are there other comments?
... I propose we approve the minutes
RESOLUTION: Minutes from 7 May 2013 are approved
Media Capture and Streams
burn: the last set of edits were by adambe
... i'd like adambe to speak about it
adambe: the changes were for a bunch of bugs
... they were uncontroversial
... like 10 bugs
... if you have any issues with how bugs are resolved, you can
reopen
... if you have any particular issues/comments
... we can take them now
... or you can comment in the bug
dom: do you have any visibility on the schedule for fixing the
remaining open bugs?
adambe: there are more bugs ... i think i can take a few more
for the next release
burn: there's no schedule in general that the editors have for
closing bugs
... as soon as there's consensus, the editors will make the
change
... it's the responsibility of the chairs to ensure discussion
continues to ensure
... there's a conclusion
fluffy: it's the responsibility of the WG, not the chairs
... but we aren't getting much from the group
burn: if you don't push your own bugs forward to resolution,
one way or the other
... the chairs have the opportunity to close the bug--
essentially reject it
Test Suite
dom: i wanted to mention work i did back in june
<dom> [11]test suite
[11]
https://github.com/w3c/web-platform-tests/tree/master/mediacapture-streams
dom: i did a couple of things on the test suite i did a year
before
... one was moving the suite to github
... where most test suites are now hosted
... the more meaningful work was to update the test suite to
make it more complete and adapt it to the latest changes to the
spec
... the work back in june was trying to write tests for this
specification
... this is again a call for feedback on the test cases
... also interested in hearing from implementers on whether
they're planning to use the test suite
... if not, are there things i can do to make it easier to use
... getUserMedia requires user consent
... i don't think we have a good way to indicate if a test
requires acceptance/refusal
burn: user-consent is written into the spec on purpose
... we don't specify how it's to be obtained
... there isn't any automated way to know
... if i download a browser which says "this automatically
consents to giving microphone access"
dom: when the operation says "do this if you get consent, and
do that if you don't"
ekr: Firefox has a special mode where you can force things to
fail or allow it to succeed
dom: the Web Driver API
ekr: Chrome has persistent permissions
... maybe i'm not understanding how you expect this to work
dom: the test running system will probably use Web Driver
... we're discussing something that we know can't be automated
in the W3 test suite
hta: ZZZ
... W3 has automated test suites
... i'm waiting for things to complete
... before we dailed in
dom: i heard you saying that Chrome is looking at integrating
W3C test suites in its testing framework; harald will look at
W3C test suites for media capture and WebRTC at that occasion
... i'm trying to get feedback
<ekr> I keep getting kicked off the call
<ekr> I blame at/7t
<hta> I said: Chrome has automated tests in its public source
code that manipulate the infobar prompt.
Bugs
burn: bug 19594
hta: the sense i got from the ML
... what we're getting from createObjectURL
... as a URL
... is definitely not the URL of a blob
... and shouldn't be used as the URL of a blob
... so having the letters "blob:" in front is confusing
... the behavior of createObjectURL isn't documented for blob
... we could say "this is the object from which you can get
urls"
... and either say or not say
... do other people have strong opinions one way or the other
stefanh: i looked into the media source extensions
... they identify PPP
... don't know if we should do the same or not?
fluffy: i don't really fully understand the issue
... i suspect most people don't understand what we're talking
about
hta: the createObjectURL model is bad
... all the specifications specify what implementations have to
do
<dom> [12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21606
[12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21606
dom: hta says for backwards compat
<hta> s/the CreateObjectURL is bad/Martin thinks the
CreateObjectURL is bad/
dom: but i'm not sure how important that is
... i'm not sure what isn't solved with
... i'm not sure on the first point
... whether this brings a useful addition to the UCs
jesup: stuff from long ago
... at mozilla we preferred sourceObject
... for reasons roc indicated
... lifetime management of resources
... knowing when they're no longer accessible
... we've implemented both
... our preference is sourceObject
burn: createObjectURL as i'm seeing it used by WebRTC
applications
... they call createObjectURL and then assign the video.src
property to that result
... in that sense, the url is opaque
... they have no idea what's there
... they don't care
... they want to take the output from the Media Stream and send
it to a particular element
... direct assignment of src with .sourceObject covers that
... the question is what UCs are covered by createObjectURL
that aren't covered by .sourceObject
... we'd have to specify what it does, since it doesn't return
a blob
fluffy: thank you very much
hta: can someone argue against this
fluffy: burn asked if there was a UC
... there can't be a UC that needs it
... what's returned right now doesn't do what it says anyway
... i'm in favor of removing it as burn stated
adambe: i think i mentioned this at the editor's call
... there are people who construct and parse their page by
concatenating strings
... it could just be a unique id
... if you take this and build the html using a string
... that's one UC
... not sure it's particularly important
... should you be able to set the source property to a stream?
... i think a separate property of sourceObject cleared up the
discussion
burn: the rationale for keeping it is that you can treat it as
a handle
... some string
... whether the string has meaning or not
... what's important is that it's a string that can be saved
... and your application can dynamically assign one string or
another
... it acts as a handle
<dom> [but that can be done with srcObject too, can't it?]
burn: you aren't changing how the handle is defined
... but you're selecting which one you're assigning
"<html>"+"<body>"+<video src=" + thing +">"
adambe: you can then do element.innerHTML=concatenated
cullen: it's a blob url... it as to have the whole stream
adambe: it doesn't have to have the entire string
dom: not concatenating STREAMs, but STRINGs
ekr: what do you think the length of that string is?
[ very short, a handle ]
adambe: it's a pointer to a registry
ekr: i'm confused
adambe: if someone is doing it that way, we could be breaking
their code
jesup: i understand adambe 's UC
... i was confused initially
... i don't see it as particularly compelling
... in most cases you can construct it the other way
... there are known minuses to using createObjectURL
... in terms of resource lifetime
<Zakim> dom, you wanted to propose asking for feedback on
public-webapps
dom: i understand the UC, while i might not like it, it might
be important
... we should ask on a WebApps or ScriptCoord ML
burn: i like that answer very much
... this is about: "how are the larger web app folks using this
to build an app going to use this functionality?"
... who would send the email to the ML?
stefanh: that's an action on dom
<dom> ACTION: Dom to ask WebApps about createObjectURL
[recorded in
[13]http://www.w3.org/2013/08/28-mediacap-minutes.html#action01
]
<trackbot> Created ACTION-23 - Ask webapps about
createobjecturl [on Dominique Hazaël-Massieux - due
2013-09-04].
burn: i believe we've reached a point of progress on this
hta: i'll create a bug to remove createObjectURL from the spec
... and set a dependency
burn: thanks hta
bug 21618
Jim_: the question is
<gmandyam> [14]MediaStreams with no tracks need to not be Ended
[14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21618
Jim_: can a media stream be resurrected?
adambe: we talked about this
... it can only move from the ended state if the script
explicitly call play()
Jim_: if it reset it
adambe: if a stream is rendered by a MediaElement and it's
consumed by something
... and tracks are removed
... and there's autoplay
... and you add a track back
... what happens?
Jim_: when media stream moves from active to inactive
[ Jim_ reads spec text ]
Jim_: the stream won't ... until you call play()
burn: from a developer perspective, if i set autoplay=""
... and i add Tracks to the Media element
... i expect it to play
Josh_Soref: +1
Jim_: yes, there's an open issue on it
burn: the reason i set autoplay= is because i don't want to
call play()
adambe: what happens if you have a media source where tracks
are coming and going
... can't we align with that behavior?
... i don't know what that behavior is...
... i do like the inactive term better than ended
... it's fine for a stream to start in an inactive state
<burn> agree with inactive as a better state for when tracks go
away
adambe: it's not good to construct a stream without tracks and
have it in ended
Jim_: right
... it certainly should be called inactive if we think it can
become active if you add more tracks
adambe: right, you can construct a stream without any tracks
... is that stream can't have tracks added to it
hta: it's inactive
... we just describe the behavior
jesup: i'm not an expert about how this would be used
... go inactive without data
... if you have autoplay= and you add tracks, it plays
burn: if you have PeerConnection
... what's the consequences for resources with a PeerConnection
jesup: what do you mean by resources losing all tracks?
... no longer have data, or removed?
burn: great question
<Josh_Soref> ... we're talking all tracks being removed
<Josh_Soref> jesup: when a track is removed
<Josh_Soref> ... that will trigger Negotiation
<Josh_Soref> ... which filters through
<Josh_Soref> ... if you add a track to one
<Josh_Soref> ... if you add a track to a previously empty, i'd
assume that will also trigger a negotiation
<Josh_Soref> burn: seems reasonable to me
<Josh_Soref> ... so no magical smart behavior needed by the
browser
<Josh_Soref> ... it triggers negotiation needed
<Josh_Soref> jesup: sounds like how it would work to me
<Josh_Soref> burn: Jim_, do you believe we have an answer to
this question?
<Josh_Soref> Jim_: i think that answers it
<Josh_Soref> ... for issue-3 if autoplay=true and tracks are
added, it will start playing automatically
<Josh_Soref> ... and the other part of inactive is defined
elsewhere
<Josh_Soref> stefanh: do we remove the `ended` / `onended`
<Josh_Soref> ... and just have inactive?
<Josh_Soref> Jim_: i think so
<Josh_Soref> ... you want an oninactive event
<Josh_Soref> burn: there's a difference between a track ending
and a track being removed
<Josh_Soref> stefanh: this is on media
<Josh_Soref> hta: if all tracks become ended, the stream is
inactive
<Josh_Soref> burn: if all tracks become ended, then the stream
is ended
<Josh_Soref> hta: ... we should remove ended
<jesup> agreed, there's no use for ended on a stream; use
inactive instead
<Josh_Soref> stefanh: do we need ended in addition to inactive?
remove ended
<Josh_Soref> adambe: i think we remove ended
<Josh_Soref> burn: anyone want to argue for keeping ended?
<Josh_Soref> ... i think we need a bug proposing this
<Josh_Soref> ekr: previously we called Ended.
<Josh_Soref> ... we're going to call Inactive
<Josh_Soref> stefanh: tracks can be muted
<Josh_Soref> adambe: the only cases where we involve media
stream track
<Josh_Soref> ... is when all tracks in a stream are ended
<Josh_Soref> ... that stream becomes inactive
<Josh_Soref> ... but it could go active again
<Josh_Soref> ... an ended stream w/ no tracks is also inactive
<Josh_Soref> ... we're removing ended
<Josh_Soref> ... since you can always add active tracks
<Josh_Soref> ekr: should we blow away the definition of stream
state?
<Josh_Soref> adambe: it's a convenience to monitor all tracks
in a stream
<Josh_Soref> ekr: every time this WG or WebRTC
<Josh_Soref> ... tries to define composition of things with
individual state
<Josh_Soref> ... given you have to interrogate the individual
states
<Josh_Soref> hta: i'm happy with removing the state variable
from Stream
<Josh_Soref> fluffy: i agree w/ what you're saying
<Josh_Soref> ... i think i'm in favor of looking at what we can
remove from the spec
<Josh_Soref> ... if we've added something later which
supercedes it
<Josh_Soref> burn: i'm ok with this
<Josh_Soref> ... fluffy said to think about this carefully
<Josh_Soref> ... current process is to propose in a bug
<Josh_Soref> ... probably in a couple of steps
<Josh_Soref> ... propose remove Ended from Stream
<jesup> +1 to remove ended, and +1 to consider removing state
<Josh_Soref> ... propose remove StreamState entirely
<Josh_Soref> ... how we tie dependencies together
<Josh_Soref> Jim_: one thing to consider is how many places
that refer to ended/inactive
<Josh_Soref> ... if there are multiple ones, then in each case
we have to replace them with spec text
<Josh_Soref> ... if we have many places that rely on the state
<Josh_Soref> ... even if we define the concept w/o an instance
variable
<Josh_Soref> ... it's still useful
<Josh_Soref> adambe: it also affects stream consumers
<Josh_Soref> dom: i think the concept of state is needed no
matter what
<Josh_Soref> ... the question is whether to expose it or not
<Josh_Soref> ... but media stream consumers need to do
something if no tracks are running
<Josh_Soref> ... the process of moving forward with this needs
to start with removing where we use this notion of state for
streams
<Josh_Soref> hta: there's no state for media stream
<Josh_Soref> ... there are tracks + ended, that's all
<Josh_Soref> Jim_: when we play a MediaStream in a media
element
<Josh_Soref> ... the media element needs to know if it's done
<Josh_Soref> ... because it needs to play events
<Josh_Soref> ... it doesn't need to be an instance variable
<Josh_Soref> ... but it needs a single place with a definition
<Josh_Soref> hta: i think we have agreement on that
<Josh_Soref> ... but there's only one action... removing ended
<Josh_Soref> burn: who's willing to enter bugs?
<Josh_Soref> hta: i can enter them
<Josh_Soref> dom: we're talking about removing the ended
attribute
<Josh_Soref> ... question about ended state
<Josh_Soref> ... and what about the ended event?
<Josh_Soref> hta: that naturally follows
<Josh_Soref> burn: output-device-selection
<Josh_Soref> ... and Promises
<Josh_Soref> ... stefanh, do you have a quick update on
Promises?
<Josh_Soref> stefanh: it turns out that DOM4 which includes
Promises
<Josh_Soref> ... is not a W3 Spec, it's in WhatWG
<Josh_Soref> ... and i understand it can't be referenced
<Josh_Soref> ... we have to reference W3 DOM4
<Josh_Soref> ... so we can't reference Promises for the time
being
<Josh_Soref> burn: we don't have a normative reference
<Josh_Soref> ... which will matter for CR
<Josh_Soref> dom: you don't need reference until CR
<Josh_Soref> ... i don't think we should hold off on the tech
for reasons of references
<Josh_Soref> dom: if we need/want references, i wouldn't hold
off
<Josh_Soref> stefanh: i agree
<Josh_Soref> ... but the conclusion was...
<Josh_Soref> dom: if we want to use them, i don't think we
should stop
<Josh_Soref> ... just because of this
<Josh_Soref> burn: bug 22251
<dom> [15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=22251
[15] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22251
<Josh_Soref> ... add error codes for HARDWARE_UNAVAILABLE and
NO_DEVICES_FOUND
<Josh_Soref> ... not sure who's following
<Josh_Soref> hta: the feedback from anne
<Josh_Soref> ... was that for the other two error codes
<Josh_Soref> ... the dom-spec thing
<Josh_Soref> ... anne said the editor of JS is pushing back
against adding more error codes
<Josh_Soref> ... which puzzled me a bit
<Josh_Soref> dom: i don't think the ability to report specific
errors will be dropped anytime soon
<Josh_Soref> ... we should continue under the assumption that
the current model is the correct one
<Josh_Soref> ... if we need new errors, define them in our
document
<Josh_Soref> ... if DOM will define them in its document is
unclear
<Josh_Soref> ... at least for my perspective, we should focus
on whether these situations need distinct error messages
<Josh_Soref> ... clearly other specs not just our own...
<Josh_Soref> hta: you're suggesting keeping a table in our own
spec
<Josh_Soref> ... in addition to dom errors, the name field have
value?
<Josh_Soref> dom: with a note that we're trying to move them
out
<Josh_Soref> ... i don't think coordination should prevent us
from making design decisions
<Josh_Soref> hta: are people ok w/ the resolution
<Josh_Soref> ... source_unavailable
<Josh_Soref> dom: there was some discussion on whether it's
useful to distinguish hardware_unavailable and no_devices_found
<Josh_Soref> ekr: we're now working on device enumeration
<Josh_Soref> ekr: specific settings that only apply to one
camera
<Josh_Soref> ... and doesn't apply to another device
<Josh_Soref> ... why not give me hardware unavailable
<Josh_Soref> dom: hardware_unavailable is if you have a device
id
<Josh_Soref> ... and no device found is when you want video and
system only has microphone
<Josh_Soref> fluffy: i'm not really
<Josh_Soref> ... i want to be clear how this error would be
generated
<Josh_Soref> ... i was wondering how things would work
<Josh_Soref> ... if i had a non mandatory constraint for HD
<Josh_Soref> ... HD plugged in [busy]
<Josh_Soref> ... and non HD plugged in
<Josh_Soref> ... i'd certainly want the non HD camera
<Josh_Soref> ... i'd like the ability to show the user that the
camera is in use by another application
<Josh_Soref> ... but i don't want that to break me getting
cameras when i want them
<Josh_Soref> ... on Enumeration, i'd like to go back to that
<Josh_Soref> Balwinder Kaur, Aptina Imaging: this is QR
<Josh_Soref> ... i work for an imaging company
<Josh_Soref> ... i've been experimenting w/ HTML5
<Josh_Soref> ... and the ability to access cameras
<Josh_Soref> ... i'd like to be able to pick which camera
<Josh_Soref> ... i have a browser, a usb camera, one on the
display
<Josh_Soref> ... everytime i have to go to the browser to pick
it
<Josh_Soref> ... i'm not sure if this is what you're discussing
<Josh_Soref> ... being able to pick the camera and use it is
very important
<Josh_Soref> fluffy: it's a public call, we want your input
<Josh_Soref> ... i have similar desires
<Josh_Soref> ... others do as well
<Josh_Soref> ... it's a tradeoff with privacy fingerprinting
<Josh_Soref> ... it's a longer topic
<Josh_Soref> ... i'm sure someone would be glad to run you
through the background
<Josh_Soref> burn: fluffy and I should talk w/ you
<Josh_Soref> ... as one of the people to propose Constraints, I
can give you the motivations for it
<Josh_Soref> ... there's another factor involved
<Josh_Soref> ... not every app developer wants to precisely
select the device
<Josh_Soref> ... and also when you're dealing w/ PeerConnection
<Josh_Soref> ... and changes w/ device settings -- based on
congestion
<Josh_Soref> ... we want input from developers and device
manufacturers
<Josh_Soref> ... but for Patent Policy reasons, we need to know
who is participating
<Josh_Soref> ... there are disclosure requirements
<Josh_Soref> Balwinder_Kaur: i'm aware of the concern
<ekr_> burn is correct
<Josh_Soref> burn: fluffy pointed out that this is a bigger
topic
<Josh_Soref> ... much more than we can complete in 5 minutes
<fluffy> Can some zakim expert add an action item for Dan and I
to talk to the Aptina folks
<Josh_Soref> dom: i think that's probably correct
<Josh_Soref> hta: the algorithm is...
<Josh_Soref> dom: i think firefox already uses error codes
<Josh_Soref> burn: for a long time, there has been some TBD in
the Constraint satisfaction algorithm for names of errors to be
generated
<Josh_Soref> ... sounds like we're finally getting names for
them
<burn> ACTION: burn to (and fluffy) contact Aptina [recorded in
[16]http://www.w3.org/2013/08/28-mediacap-minutes.html#action02
]
<trackbot> Created ACTION-24 - (and fluffy) contact aptina [on
Daniel Burnett - due 2013-09-04].
burn: regarding output device selection
... any status on that
stefanh: we had some proposal to move it to the HTML WG
... i don't know...
hta: justin is on vacation
... i sent the proposal
burn: what's the impact on our TF?
stefanh: JJJJ
ekr_: i don't agree with that
<fluffy> I might disagree with it too, but I'm not sure yet
hta: public-html@w3.org
fluffy: how can they solve the problem?
hta: the concept that output-devices is the same as
input-devices is not a well formed concept yet
<ekr_> I'm actually not sure how I would implement the thing
fluffy phrased
<ekr_> Like, my mac has two displays each with a microphone and
speaker
fluffy: i think we need time to discuss
<ekr_> Does Cullen mean "the speaker associated with the
display associated with this microphone"
<ekr_> ?
burn: apparently we need discussion on the list about how much
work needs to remain in this TF
dom: you don't want to get into technical or political
fluffy: opening new topics before we close things
... i object to it being closed rapidly
... sorry it was opened
hta: when is the JSEP draft coming out?
fluffy: exactly
burn: i'm going to declare my section on Media
Capture+Streaming closed
<dom> +1 to publish new WD
stefanh: are people ok w/ a new draft?
burn: i'm in favor
... clearly indicate current state
dom: seems like ReSpec has a bug where you use a Sequence
... ideally the bug would be fixed in the generated version
burn: dom does the adjustments needed to make the document
legal for publication
dom: i'll be happy to do it anyway
burn: these challenges come up from time to time
stefanh: sounds like no objection
<fjh> DAP is not meeting
<fjh> many of DAP participants plan to attend TPAC
dom: sounds like many people in the TF are in WebRTC
... and a few people from DAP
... but those people are mostly in other WGs that would attend
<fjh> +1 to dom assessment that DAP participants likely to
attend TF meeting on Thursday
<fjh> maybe you should set up a questionnaire regarding
participation
stefanh: we should probably do that
<fluffy> +3
Many thanks to josh for scribing
[ adjourned ]
trackbot, end meeting
RRSAgent: draft minutes
Summary of Action Items
[NEW] ACTION: burn to (and fluffy) contact Aptina [recorded in
[17]http://www.w3.org/2013/08/28-mediacap-minutes.html#action02
]
[NEW] ACTION: Dom to ask WebApps about createObjectURL
[recorded in
[18]http://www.w3.org/2013/08/28-mediacap-minutes.html#action01
]
[End of minutes]
Received on Monday, 30 September 2013 07:22:25 UTC