There are 19 comments (sorted by their types, and the section they are about).
question comments
Comment LC-3009
Commenter: Garrett Smith <dhtmlkitchen@gmail.com> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :How can you apply a filter chain for video capture to a VIDEO element's src?
Related issues: (space separated ids)
WG Notes: Does not seem to be in scope for this document at this time. Discussion has happened on the list.
Resolution: This document does not aim to solve the problem of defining filter chains for video. A later project can build on this basis, but the Working Group feels that it is out of scope for the 1.0 version of this document.
No change in response to this comment is contemplated. (Please make sure the resolution is adapted for public consumption)
substantive comments
Comment LC-3018
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== Please use [Exposed] ==
That way it is much clearer what is exposed to Window and/or Worker.
See https://github.com/w3c/mediacapture-main/issues/163
Related issues: 163
(space separated ids)
WG Notes: List discussion seems to conclude that only [exposed=Window] is required.
Resolution: The Working Group discussion concluded that explicit marking with [Exposed] is valuable, but did not find any support for adding exposure to workers at this time; thus, the Working Group decided adding [exposed=Window] to all relevant WebIDL constructs and has reflected this in its working document as illustrated in https://github.com/w3c/mediacapture-main/commit/6a479c794deeaf1bba40d87ae1299827cfa79773#diff-ea76d38900f79cfae8f60e5f7cf16dd1
(Please make sure the resolution is adapted for public consumption)
Comment LC-3020
Commenter: Kuu Miyazaki <miyazaqui@gmail.com> (archived message ) Context: MediaStreamTrack.kind
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stefan Håkansson
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Two kinds of MediaStreamTracks, 'audio' and 'video' are defined in the spec.
But shouldn't we add another kind, 'video+audio (muxed)'?
I thought there might be a platform that doesn't support separate
sources for audio and video but only supports an encoded/muxed stream
as a source.
In such case, it would be hard for User Agent to implement for
instance removeTrack.
Related issues: (space separated ids)
WG Notes: We have not discussed this case as far as I can remember. But it seems to me that even if a device is hardwired to deal with both audio and video at the same time, the UA could still allow for removal of tracks from a MediaStream as this would simply mean that the "control surface" of the media is removed - this would not stop the device from coding both audio and video though.
Resolution: This has not been discussed in the Task Force, but it seems that the relevant cases can be handled with the current set of APIs.
No change in response to this comment is contemplated. (Please make sure the resolution is adapted for public consumption)
Comment LC-3026
Commenter: Phillips, Addison <addison@lab126.com> on behalf of Internationalization Working Group (archived message ) Context: MediaStreamTrack.label
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The first issue is I18N-ISSUE-464:
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#widl-MediaStreamTrack-label
The 'label' value is described as follows:
--
User Agents MAY label audio and video sources (e.g., "Internal microphone" or "External USB Webcam"). The MediaStreamTrack.label attribute MUST return the label of the object's corresponding source, if any. If the corresponding source has or had no label, the attribute MUST instead return the empty string.
--
Since the value is intended to contain natural language text, probably for consumption/display to the end-user, maybe it should be possible to determine or set the language (@lang) and base direction (@dir) of the text. This will allow the text to be displayed properly in different contexts: most text rendering systems depend on this information to do a good job, even within the same display context.
In addition, it may be useful to allow multiple labels in different languages (although generally the source's label is applied by the user's user-agent, and so will be appropriately localized??)
[1] https://www.w3.org/International/track/products/78
Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)
Related issues: (space separated ids)
WG Notes: This issue is thorny. The identifiers returned as "label" in present implementations are mainly from underlying drivers, and it seems impossible for an UA to reliably provide translations of these labels. A simple fallback seems like it's needed.
Since the mediaDevices.enumerateDevices call is only defined on Navigator, we ask whether it's possible to state that the @lang attribute is window.navigator.language, and whether it's appropriate to determine @dir via the same method
Resolution: The Working Group feels the topic of localizing human readable strings in JavaScript needs to be solved at the platform level rather than in this particular specification.
We tried getting input and insights from the Internationalization Working Group on how to progress such an addition to the platform, to no avail. (Please make sure the resolution is adapted for public consumption)
Comment LC-3021
Commenter: Justin Uberti <juberti@google.com> (archived message ) Context: 4.3.6 MediaTrackCapabilities
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :In Sections 4.3.6 and 4.3.7, the various parameters that can be specified
are declared, but there is no text that defines their exact meaning. Are
they defined somewhere else, or did I just miss them?
e.g.
http://w3c.github.io/mediacapture-main/getusermedia.html#media-track-constraints
4.3.7.2 Dictionary MediaTrackConstraintSet
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-MediaTrackConstraintSet>
MembersaspectRatio of type ConstrainDouble
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDouble>
deviceId of type ConstrainDOMString
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDOMString>
echoCancellation of type ConstrainBoolean
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainBoolean>
facingMode of type ConstrainDOMString
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDOMString>
frameRate of type ConstrainDouble
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDouble>
groupId of type ConstrainDOMString
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDOMString>
height of type ConstrainLong
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainLong>
sampleRate of type ConstrainLong
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainLong>
sampleSize of type ConstrainLong
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainLong>
volume of type ConstrainDouble
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainDouble>
width of type ConstrainLong
<http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-ConstrainLong>
Related issues: (space separated ids)
WG Notes: The registry references have been removed as result of the vote. In the process the definitions have been moved to section 4.3.9
Resolution: The parameters are defined in section 4.3.9 of the document. (Please make sure the resolution is adapted for public consumption)
Comment LC-3022
Commenter: Charlie Kehoe <ckehoe@google.com> (archived message ) Context: 4.3.7.2 Dictionary MediaTrackConstraintSet Members
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Peter Thatcher
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Some applications involve listening to audio for a potentially extended
period of time (with user consent, of course), and are not particularly
latency-sensitive. An example would be the "Ok Google" hotwording available
on the Chrome new tab page, or other types of continuous speech
recognition. For these applications, a typical low-latency audio
configuration can lead to excessive power usage. I've measured 20% CPU
usage for audio capture in Chrome, for example.
My proposed solution is to offer a way to change the audio buffer size.
This enables a tradeoff between latency and power usage. For example, a
member could be added to MediaTrackConstraintSet
<http://w3c.github.io/mediacapture-main/getusermedia.html#dictionary-mediatrackconstraintset-members>
:
dictionary MediaTrackConstraintSet {
...
audioBufferDurationMs of type ConstrainLong
};
This would be an integer number of milliseconds. Perhaps the name could
mention latency instead (e.g. audioLatencyMs).
How does this simple change sound?
- Charlie
Related issues: (space separated ids)
WG Notes: Discussion seems to show some support for a latency constraint on audio tracks. There seems to be consensus around "latency" as the name and seconds as the units. The meaning can be either ideal or max latency, but min latency doesn't make sense.
Examples from the discussion:
{ latency: 0.0025 } // ideally low-latency
{ latency: 0.025 } // ideally high-latency
{ latency: { max: 0.0025 } } // must be low latency
Some applications would prefer to have higher latency with lower battery impact, such as speech hot word detection, and some applications, for example interactive music applications, cannot function if latency is too high
Resolution: The Working Group agreed to add a way for the application to control the audio buffer size by means of a new MediaStreamTrack constraint to represent latency. (Please make sure the resolution is adapted for public consumption)
Comment LC-3015
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: MediaStreamTrackEvent
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Bergkvist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== MediaStreamTrackEvent's track member is not nullable ==
Either you need to make this nullable or you need to require the
dictionary argument and not give that a default value of null.
See https://github.com/w3c/mediacapture-main/issues/160
Related issues: 160
(space separated ids)
WG Notes: https://github.com/w3c/mediacapture-main/pull/169 should fix this.
Resolution: The Working Group has considered this comment, and has made the corresponding change in its Working Document https://github.com/w3c/mediacapture-main/commit/8d330d290d8318c57628a1f9c6f275fb58a86cc8 (Please make sure the resolution is adapted for public consumption)
Comment LC-3016
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: 6.1 Direct Assignment to Media Elements
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stefan Håkansson
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== Remove "Direct Assignment to Media Elements" ==
It conflicts with the definition given in the HTML Standard, which
also allows for setting a `Blob` object and such. Given that it's
integrated there, providing a pointer seems better.
See https://github.com/w3c/mediacapture-main/issues/161
Related issues: 161
(space separated ids)
WG Notes: There is an open issue as well as a PR related to this comment. In addition, a bug has been filed on the html draft.
Resolution: The Working Group agrees the specification needs to defer to the existing description of assignments made in the HTML specification and had modified the specification accordingly.
The Media Capture and Streams spec keeps the parts that are not yet reflected in the HTML specification (as reported in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28785 ). (Please make sure the resolution is adapted for public consumption)
Comment LC-3017
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: 7.1 MediaStreamError
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Daniel Burnett
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== MediaStreamError should not be an interface ==
Errors in the platform are represented by JavaScript `Error` object
subclasses.
See https://github.com/w3c/mediacapture-main/issues/162
Related issues: 162
(space separated ids)
WG Notes: After discussions, we have changed the typing of the errors so that MediaStreamError no longer exists as an interface.
We have one extended error type (overconstrained error) and a number of errors that are DOMError with different names.
Resolution: We believe we have addressed this issue through a revisition of the error handling in the spec - most importantly PR #194, which added the "overconstrained error".
We believe this change, and associated other changes, together resolve the issue. (Please make sure the resolution is adapted for public consumption)
Comment LC-3027
Commenter: Phillips, Addison <addison@lab126.com> on behalf of Internationalization Working Group (archived message ) Context: message of type DOMString, readonly , nullable
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :https://www.w3.org/International/track/issues/465
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#widl-MediaStreamError-message
The 'message' value of MediaStreamError has no associated language or base direction information. Multiple 'message' values in different languages are not provided for. Since the message is generated by the user-agent, this may already be appropriately localized, but what about remote or hosted cases? And having the language and direction metadata may be useful when presenting the string in JS alerts or in an HTML context.
Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)
Related issues: (space separated ids)
WG Notes:
Resolution: We recognize that the internationalization of error messages is a huge unsolved problem for the Web platform.
These error messages are primarily intended for debugging and not for display in the user interface.
Should error messages need better internationalization support, appropriate tooling needs to be added at the EcmaScript or WebIDL level, at which time the WG will happily consider making use of such tools.
The Working Group doesn't plan on making change based on this comment. (Please make sure the resolution is adapted for public consumption)
Comment LC-3025 : onaddtrack
Commenter: Iñaki Baz Castillo <ibc@aliax.net> (archived message ) Context: addtrack
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Bergkvist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Hi,
The current draft states that both onaddtrack and onremovetrack events
"are not fired when the script directly modifies the tracks of
aMediaStream".
I don't like that. When I call close on a WebSocket I get the onclose
event. Events indicate that something happened regardless who or what
caused it.
I see no reason at all to just fire those events due to a track
modification made by the script in a MediaStream.
Related issues: (space separated ids)
WG Notes:
Resolution: A note was added to the document that clarifies that the addtrack and removetrack events are defined to be used by other specs that use the MediaStream API and need to notify the script that the User Agent has updated a MediaStream's track set "from the background".
[1] https://github.com/w3c/mediacapture-main/commit/13ad8737791455ffae8f9f91c018d8aa896ca379 (Please make sure the resolution is adapted for public consumption)
Comment LC-3010
Commenter: Elliott Sprehn <esprehn@chromium.org> (archived message ) Context: enumerateDevices()
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== enumerateDevices should be getAll() to match other APIs ==
```mediaDevices.getAll()``` is pretty clear and matches other APIs
like the Cache API in SW.
Related issues: 157
(space separated ids)
WG Notes: Hesitant to do name changes on an "I like it better" basis, and there doesn't seem to be consistency across the platform on naming "things like this".
Resolution: The Working Group does not contemplate any change based on this comment. (Please make sure the resolution is adapted for public consumption)
Comment LC-3023
Commenter: Joe Berkovitz <joe@noteflight.com> on behalf of Web Audio Working Group (archived message ) Context: enumerateDevices()
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Harald Alvestrand
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The Web Audio WG so far has identified one key item that we would like to
see addressed. The MediaDeviceInfo result from enumerateDevices() (
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#idl-def-MediaDeviceInfo)
lacks information that is typically available in the underlying OS
implementations that we think would be very helpful for implementations:
· Channel count and configuration (Mono, Stereo, 5.1, 7.1, etc…)
· Physical Output (Headphone, Speaker, HDMI, …)
· Latency (this matters a lot for gaming -- it will be very low for
on-board hardware, perhaps quite high for wireless audio bridging like
Apple TV)
· Output capabilities (bitstream passthrough vs PCM – relevant in
digital media adapter cases (Chromecast, etc))
It is perhaps sufficient from a user interface point of view to have a
string to display, but for a program to be able to either adapt to the user
selection or to guide and default the user selection, the above are pretty
important characteristics, at least in some use cases. Many if not most of
the host OSes that user agents run on expose these sorts of output device
characteristics.
Aside from the difficulty with enumerating devices, there is also perhaps a
need to make it possible for applications to query the set of available
devices with respect to the above charateristics. MediaTrackConstraints and
MediaTrackSettings do not currently include constraint attributes that map
to items in the above list. And even if they do, arriving at a
practical goodness-of-fit
metric that can be generalized across a spectrum of audio apps may be
difficult.
The same concerns apply to the set of input devices.
Related issues: (space separated ids)
WG Notes: This seems to have high complexity, but also value for many use cases. Is it possible to find extension points in the proposal so that these things can be added later without breaking the model?
Resolution: After discussions in the TF and with the commenter, two changes have been implemented:
- Add a channel count for input devices (https://github.com/w3c/mediacapture-main/pull/210)
- Add capability to discover input device capabilities via enumerateDevices (https://github.com/w3c/mediacapture-main/pull/211)
Regarding output devices and capabilities, this is more in scope for the Audio Output Devices API document (https://github.com/w3c/mediacapture-output) and should be brought as comment to that document or alternatively as a proposed new document outlining a suitable API. (Please make sure the resolution is adapted for public consumption)
Comment LC-3024
Commenter: Martin Thomson <martin.thomson@gmail.com> (archived message ) Context: 14. IANA Registrations
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :On 20 April 2015 at 05:40, Harald Alvestrand <harald@alvestrand.no> wrote:
> There's more text on what they mean in section 14.1, "Track
> Constrainable Property Registration".
Can we remove the registry? Is there any reason that we can't simply
maintain the document with the definitions of the things we are using?
Related issues: (space separated ids)
WG Notes: This was discussed again, and no consensus was found so a vote was issued. The result of the vote was that the document should not reference any registry.
Resolution: The reference to the registry has been removed from the document. Recorded here: https://lists.w3.org/Archives/Public/public-media-capture/2015Oct/0018.html (Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-3012
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: MediaStream
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Bergkvist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== MediaStream's active attribute ==
The link from the constructor to "active" indicates a `MediaStream`
state of active/inactive. However, the prose doesn't reference to this
as a state but rather as something that is a boolean. This is rather
confusing.
See https://github.com/w3c/mediacapture-main/issues/159
Related issues: 159
(space separated ids)
WG Notes:
Resolution: The Working Group agreed that the the value for the active state should not be calculated in the MediaStream constructor, but instead be defined by the stream's track set.
PR #168 [1] removed the concerned text.
[1] https://github.com/w3c/mediacapture-main/pull/168 (Please make sure the resolution is adapted for public consumption)
Comment LC-3011
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message ) Context: addTrack()
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Bergkvist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :== Language does not seem tamper-free ==
E.g. if I overwrite `MediaStream.prototype.addTrack` does that affect
`MediaStream`'s constructor? I think both `addTrack()` and the
constructor are meant to invoke a "private" algorithm. This happens
throughout the specification.
See https://github.com/w3c/mediacapture-main/issues/158
Related issues: 158
(space separated ids)
WG Notes:
Resolution: The WG agreed to use private algorithms instead of the exposed API to reference the intended functionality as recommended by reporter of this comment.
PR #167 fixes this issue and a similar issue in the MediaStream.clone() method.
[1] https://github.com/w3c/mediacapture-main/pull/167 (Please make sure the resolution is adapted for public consumption)
Comment LC-3014
Commenter: Harald Alvestrand <harald@alvestrand.no> (archived message ) Context: 4.3.1 Life-cycle and Media Flow
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Adam Bergkvist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :In the current specification, we have two concepts related to sources
and tracks:
- A track can be stop()ed, in which case it is ended.
- A track can be detached from its source.
The text says:
A) in terminology for "source", we have:
Sources are detached from a track when the track is ended for any reason.
B) Under "Life-cycle and Media Flow", we have:
A MediaStreamTrack can be detached from its source. It means that the
track is no longer dependent on the source for media data. If no other
MediaStreamTrack is using the same source, the source will be stopped.
MediaStreamTrack attributes such as kind and label must not change
values when the source is detached.
C) Under the "enabled" attribute of a track, we have:
On getting, the attribute must return the value to which it was last
set. On setting, it must be set to the new value, regardless of whether
the MediaStreamTrack object has been detached from its source or not.
Under the "stop" function for a track, we have:
3. Set track's readyState attribute to ended.
4. Detach track's source.
It seems to me that this is one concept more than we need.
Whether there is a relationship between a stopped track and its source
or not is an implementation detail, and we shouldn't be constraining it
in our API description.
So my suggestion:
In A, C and D, simply remove the text that refers to "Detach".
In B, instead say:
If all MediaStreamTracks that are using the same source are ended, the
source will be stopped.
I think that simplifies the terminology, and doesn't change any
observable property of the API.
What do people think?
(If others like it, I'll file a bug for it.)
Harald
Related issues: 164
(space separated ids)
WG Notes: The issue was discussed on the list, and the resolution was that it was sufficient with concept of stopping a source.
Resolution: The Working Group agrees with the suggestion, and commit [1] removes the concept of detaching a source from its track.
[1] https://github.com/w3c/mediacapture-main/commit/8a0561644d0f7d922ccf15f8dd3e7bb725b6163f (Please make sure the resolution is adapted for public consumption)
Comment LC-3019
Commenter: Jason Ausborn <jason.ausborn@gmail.com> (archived message ) Context: 11.1 Interface Definition
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :After consolidating WebIDL from the working draft, I processed it with the
W3 WebIDL checker. The checker had errors regarding the
ConstrainablePattern interface for undefined Capabilities and Settings
types.
Current:
[NoInterfaceObject]
interface ConstrainablePattern {
*Capabilities* getCapabilities ();
Constraints getConstraints ();
*Settings* getSettings ();
Promise<void> applyConstraints (Constraints constraints);
attribute EventHandler onoverconstrained;
};
Recommended:
[NoInterfaceObject]
interface ConstrainablePattern {
*object* getCapabilities ();
Constraints getConstraints ();
*object* getSettings ();
Promise<void> applyConstraints (Constraints constraints);
attribute EventHandler onoverconstrained;
};
The above changes will pass with the WebIDL Checker. Note, changing *object
*to *any *will work also (as well as other defined types).
----------------
I was confused after reading *11.1 Interface Definition *in regards to
"*limitations
of the interface definition language* used in this specification".
WebIDL states that the *[NoInterfaceObject]* extended attribute should be
solely used on *supplemental *interfaces. IMO, I recommend rephrasing the *11.1
Interface Definition *description. Consider rewording *limitations of the
interface definition language*, and consider adding *supplemental
interface* somewhere
in the description.
Related issues: (space separated ids)
WG Notes: There is only one WG reply on this thread (http://lists.w3.org/Archives/Public/public-media-capture/2015Apr/0017.html); thank you Jan-Ivar! In addition to expressing a dislike for the mechanism, Jan-Ivar provides a very good explanation of the ConstrainablePattern mechanism used in the document, a mechanism which humans can comprehend but WebIDL cannot, at least currently.
Resolution: We have added text explaining that the "Constrainable Pattern" is not an interface that can be used/inherited etc. but rather a template. See https://github.com/w3c/mediacapture-main/pull/306 for details of the change.
Jason was emailed on January 29th 2016, but has not responded so far.
(Please make sure the resolution is adapted for public consumption)
Add a comment .