Media Capture Task Force Teleconference -- 28 Aug 2013

<trackbot> Date: 28 August 2013

<scribe> scribe: Josh_Soref

<scribe> scribenick: timeless

Minutes Approval

<stefanh> 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> test suite

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> 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 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> MediaStreams with no tracks need to not be Ended

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

- DRAFT -

Media Capture Task Force Teleconference

28 Aug 2013

Attendees

Contents

Minutes Approval

Media Capture and Streams

Test Suite

Bugs

Summary of Action Items

Scribe.perl diagnostic output