RE: new draft of recording proposal

*         I think you've duplicated functionality that's already available on the track level with "muteTrack" and "unmuteTrack". Apparently, MediaStreamTrack's "enabled" boolean switch already does this. I don't believe the sink needs to have this capability-unless we're talking about removing the "enabled" switch from the MediaStreamTrack...

>>  I considered this but several people wanted to have a separate mute/unmute at the Recording level, separate from muting the underlying Track (the use case would be that you want to black out recording while continuing to stream media (to a <video> tag or via a PeerConnection)

This makes me wonder if we shouldn't generally consider removing this feature (boolean enabled) from MediaStreamTrack. If most sinks can control this anyway in some form or another, then there'll be little value to also having it on the track-level and a lot of extra potential complexity. On the track, if you set enabled to false, I suspect that you're setting this value on the underlying track's source, thus affecting all tracks using that source. Is that really what is desired? We've been trending lately toward making the sinks smarter and turning the track-level controls into constraints. Having "enabled" on the track level as a non-constraint doesn't seem to fit this pattern very well.

I realize this discussion is tangential to what you've spec'd but I hope some other folks from WebRTC would be willing to comment on removing "enabled" from the track-level, or at least turning it into a constraint instead.



*         You're using the old syntax for throwing exceptions. Last year, the syntax was updated in WebIDL<http://dev.w3.org/2006/webapi/WebIDL/v1.html#idl-exceptions>. You can see examples of how to do this in DOM4 (http://www.w3.org/TR/dom/#error-names-0). Basically, you now say: "throw a DOMException with name InvalidTrackIdError". (INVALID_TRACK_ID --> InvalidTrackId + "Error" on the end).

>> I'm imitating what's in the webRTC and gUM specs.  If it's out  of date, we should update them all.  My main concern is that error reporting be consistent among the three specs.  I'll go along with whatever we decide to do as a group.

Fair enough. I think WebRTC and gUM were both initially based on the Geolocation spec's pattern, which (at least in the WebApps and HTML WG) is not considered the right pattern anymore. I'd strongly recommend we align with what IndexedDb and FileAPI are doing to reduce potential friction for CR publications.

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Thursday, December 20, 2012 11:09 AM
To: Travis Leithead; Mandyam, Giridhar; public-media-capture@w3.org
Subject: RE: new draft of recording proposal

Travis,
  Responses in-line.

From: Travis Leithead [mailto:travis.leithead@microsoft.com]
Sent: Thursday, December 20, 2012 1:58 PM
To: Mandyam, Giridhar; Jim Barnett; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: RE: new draft of recording proposal

Giri, did you get any feedback on your proposal?

Jim, great stuff! Some suggestions for improvement:

*         I think you've duplicated functionality that's already available on the track level with "muteTrack" and "unmuteTrack". Apparently, MediaStreamTrack's "enabled" boolean switch already does this. I don't believe the sink needs to have this capability-unless we're talking about removing the "enabled" switch from the MediaStreamTrack...

>>  I considered this but several people wanted to have a separate mute/unmute at the Recording level, separate from muting the underlying Track (the use case would be that you want to black out recording while continuing to stream media (to a <video> tag or via a PeerConnection)



*         takePhoto is defined to throw when the recorder is not "recording". Is this a requirement for takePhoto? I would think that as long as the underlying track's readyState is "live", then takePhoto would succeed (and that it wouldn't be necessary to start recording to call this API).

>> Good point,  I'll change that.



*         You've also defined takePhoto to throw if the underlying track source isn't "photo-camera". This seems OK to me, but it implies that the source will have a photo-mode. Thus you'd probably never expect a frame grab. Now, if the source was just "camera", then you might expect this to happen, but then you would have thrown an exception earlier. Perhaps you can relax the throw conditions to a track of type VideoStreamTrack only.

>> Yes, I wasn't sure what to do here.  You had 'photo-camera' as the source in your draft, so I kept it but added an open issue asking whether this was too restrictive.  If there's something photo-like that can be done on any VideoStreamTrack, then I think that  it would be better to be loose.



*         You're using the old syntax for throwing exceptions. Last year, the syntax was updated in WebIDL<http://dev.w3.org/2006/webapi/WebIDL/v1.html#idl-exceptions>. You can see examples of how to do this in DOM4 (http://www.w3.org/TR/dom/#error-names-0). Basically, you now say: "throw a DOMException with name InvalidTrackIdError". (INVALID_TRACK_ID --> InvalidTrackId + "Error" on the end).

>> I'm imitating what's in the webRTC and gUM specs.  If it's out  of date, we should update them all.  My main concern is that error reporting be consistent among the three specs.  I'll go along with whatever we decide to do as a group.



*         I think you should get rid of "RecordingError" and adopt the de-facto way of reporting errors asynchronously that has been used in IndexedDb<http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBRequest-error>, FileReader<http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException>, etc: namely the "DOMError<http://www.w3.org/TR/dom/#interface-domerror>" object defined in DOM4. Basically, you just create a new attribute of type DOMError? error, which is null unless an error state has been set, in which case the DOMError basically mirrors the error exception names. You can still fire a "recordingerror" event, but the interface will be Event, instead of "RecordingError" as presently defined. I suggest reading through the IndexedDb, and FileReader specs to get a sense on how this pattern works.



>> See my previous remark.  "RecordingError" is a cut-paste-rename from the webRTC spec.  If there's a newer, better, way to do this, let's move all the specs to it.



-          Jim


From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Thursday, December 20, 2012 10:23 AM
To: Jim Barnett; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: RE: new draft of recording proposal

I had sent out recommended changes to the spec earlier this week, and it looks like several items that I suggested are not in this current version.  How do we resolve merging your most recent changes with what I had suggested?

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Thursday, December 20, 2012 10:15 AM
To: public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: new draft of recording proposal

If anyone is looking for an excuse to escape from their relatives over the holidays, they might try reviewing the updated recording proposal.  I have aligned the event and error definitions with the other specs, added pause/resume, mute/unmute, and Travis' photo proposal.

The main remaining work item is to fix the get/set parameters syntax and use a Mime type instead of separate entries for the various codecs.  I'll try to work on that when it becomes time to escape from my relatives.


-          Jim