W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

RE: new draft of recording proposal

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Thu, 20 Dec 2012 19:08:59 +0000
To: Travis Leithead <travis.leithead@microsoft.com>, "Mandyam, Giridhar" <mandyam@quicinc.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281FE77@GENSJZMBX01.msg.int.genesyslab.com>
  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
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
Received on Thursday, 20 December 2012 19:09:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC