Re: Settings API Proposal v3 feedback summary

On 2012-10-03 03:10, Travis Leithead wrote:
> V4 is now ready. I've posted it on Mercurial for easier reading:
>
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html
>
>  Thanks! Looking forward to your continued feedback.

Thanks for the updated proposal. There's quite a lot of interesting new
stuff here. :)

I've pasted spec text as quotes below.

> 1. Remove LocalMediaStream interface
>
> Note that this process has to bind a completely new LocalMediaStream
> to the video tag a second time (if re-using the same video tag) only
> because the second LocalMediaStream object was different than the
> first.
>
> It is much more efficient for developer code to simply add/remove
> tracks to a MediaStream that are relevant, without needing to change
> the consumer of the MediaStream.

I agree that it's simpler to add tracks, but this was possible in the 
old proposals as well by creating a clone of the first LocalMediaStream 
and play the clone instead.

> 2. New MediaStreamTrack (derived) types

>
> MediaStreamTrack
>     VideoStreamTrack
>         VideoDeviceTrack
>         PictureDeviceTrack
>     AudioStreamTrack
>         AudioDeviceTrack
>
> interface VideoDeviceTrack : VideoStreamTrack {
>     readonly attribute PictureDeviceTrack? pictureTrack;
>     ...

I find the object hierarchy a bit confusing. A VideoDeviceTrack is a
VideoStreamTrack and may have a PictureDeviceTrack that's also a
VideoStreamTrack. Will a PictureDeviceTrack ever be used as a track? I
mean, is the intention that you should be able to add it directly to a
MediaStream with addTrack() or pass it to the MediaStream constructor?

> [Constructor(DOMString type, optional PictureEventInit
> eventInitDict)]
> interface PictureEvent : Event {
>     readonly attribute Blob data;
> };

We should consider making this a more general event interface (e.g.
DataBlobEvent or BlobDataEvent). It would make it more reusable for
other purposes. The interface could for example be used for the
"dataavailable" event in our own recording API to deliver the media
chunks (Blobs). Just for clarification, the event would still have type
"picture" even though it would use a more general Event interface.

> level of type unsigned long, readonly
>     The sensitivity of the microphone. This value must be a whole number
> between 0 and 100 inclusive.

We could use the WebIDL feature [Clamp] here to make sure the value is
in range.

> 3. Settings Retrieval/Application

> Each team a request() is made,

Nit: s/team/time/

> Issue 3
>
> Rotation makes me think I could set this to 45 degrees or some such.
> Maybe there's a better setting name for this. I only want to support
> right-angles.

Orientation? Perhaps the value should be some kind of an enum with the
valid values.

> 4. Device List

I agree with the comments made by other people that it's not OK to let
the JS application silently switch to camera B even though it has gotten
permission to use camera A.


> select
>     test a set of optional and/or mandatory constraints across the set
>     of devices in the device list, with the goal of selecting a single device.

Say that more than one devices satisfied the constraints:
- Is there a reason why the DeviceEvent doesn't deliver a list of all
those devices (and let the developer pick one to use)?
- How does the UA make the choice of which one to select?

> [Constructor(DOMString type, optional DeviceEventInit
> eventInitDict)]
> interface DeviceEvent : Event {
>     readonly attribute MediaStreamTrack device;
> };

If we go with only one track here, we could reuse the
MediaStreamTrackEvent interface. The name of the property is "track" in
that interface but that seems more correct with regards to the type
(MediaStreamTrack).

> readonly attribute unsigned long?  deviceIndex;

How is this indented to be used? The object that has the deviceIndex
property is the one that we'll find if we look up something at position
deviceIndex. It's may not be that useful to store either since the
device may be relocated in the list or the original property could 
become null.

> 6. Example usage scenarios

> function gotMedia(mediastream) {
>    mediastream.videoTracks[0].devices.addEventListener("deviceadded",
>            enableAndShowNewDevice);
> }

It feels like the objects in the track lists have become the entry point 
where you do pretty much everything. I remember that we used to talk 
about a device list that was attached to some global object (e.g. 
navigator.userMedia or something). I think it's an alternative to 
letting every track reference it. A global list could still be 
accessible even if you dropped all track references. There was indeed a 
mapping issue between devices and tracks with a global list, but I don't 
see that problem here since the track in the stream is the device.

/Adam

Received on Wednesday, 17 October 2012 16:03:10 UTC