W3C

List of comments on “Media Capture and Streams” (dated 14 April 2015)

Quick access to

There are 19 comments (sorted by their types, and the section they are about).

question comments

Comment LC-3013
Commenter: Nigel Megitt <nigel.megitt@bbc.co.uk> (archived message)
Context: Document as a whole
assigned to Harald Alvestrand
Resolution status:

Does this work include the capture of related streams of media and/or data
with common timing references, such as captions or subtitles?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-3009
Commenter: Garrett Smith <dhtmlkitchen@gmail.com> (archived message)
Context: Document as a whole
assigned to Harald Alvestrand
Resolution status:

How can you apply a filter chain for video capture to a VIDEO element's src?
(space separated ids)
(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
assigned to Harald Alvestrand
Resolution status:

== 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
163
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-3020
Commenter: Kuu Miyazaki <miyazaqui@gmail.com> (archived message)
Context: MediaStreamTrack.kind
assigned to Stefan Håkansson
Resolution status:

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.
(space separated ids)
(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
assigned to Harald Alvestrand
Resolution status:

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)
(space separated ids)
(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
Not assigned
Resolution status:

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>
(space separated ids)
(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
assigned to Peter Thatcher
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-3015
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message)
Context: MediaStreamTrackEvent
assigned to Adam Bergkvist
Resolution status:

== 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
160
(space separated ids)
(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
assigned to Stefan Håkansson
Resolution status:

== 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
161
(space separated ids)
(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
assigned to Daniel Burnett
Resolution status:

== 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
162
(space separated ids)
(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
assigned to Harald Alvestrand
Resolution status:

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)
(space separated ids)
(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
assigned to Adam Bergkvist
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-3010
Commenter: Elliott Sprehn <esprehn@chromium.org> (archived message)
Context: enumerateDevices()
assigned to Harald Alvestrand
Resolution status:

== enumerateDevices should be getAll() to match other APIs ==
```mediaDevices.getAll()``` is pretty clear and matches other APIs
like the Cache API in SW.
157
(space separated ids)
(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()
assigned to Harald Alvestrand
Resolution status:

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.
(space separated ids)
(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
Not assigned
Resolution status:

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?
(space separated ids)
(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
assigned to Adam Bergkvist
Resolution status:

== 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
159
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-3011
Commenter: Anne van Kesteren <annevk@annevk.nl> (archived message)
Context: addTrack()
assigned to Adam Bergkvist
Resolution status:

== 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
158
(space separated ids)
(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
assigned to Adam Bergkvist
Resolution status:

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
164
(space separated ids)
(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
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:46:56 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org