RE: new draft of recording proposal

I'm not specifically worried about memory exceptions, but about error cases in general.   I'd be more comfortable if someone had done some prototyping and could tell us which of the following cases holds:


1.        When there is an error, there usually is  valid data to return.

2.       When there is an error, there almost never is valid data to return.

3.       There are certain classes of errors for which we know we can return good data, and others  for which we know we cannot.

4.        In most error cases, it's is difficult for the UA to determine if the data is valid.

I think that the API would look rather different depending on which of these holds.   As a hypothetical example, I would think that if 3 was the case, we might want to distinguish the two classes of errors, and return data with one class but not the other.  But that solution wouldn't make any sense if 1, 2, or 4 was the case.

That's why I'd like to have more implementation experience before committing to a particular API design for this issue.


-          Jim

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Friday, December 21, 2012 2:34 PM
To: Jim Barnett; Travis Leithead; public-media-capture@w3.org
Subject: RE: new draft of recording proposal

I think what you are saying is that when a memory exception occurs, then your preference would be that UA should not be allowed to return data at all.  Is that correct?

Regarding validity of the data, I'm not sure why that is a concern for this particular event.  My expectation is that the UA will have its own predefined limits on maximum blob size (e.g. set at compile time).  If it is returning data prior to the recording having ended, then the developer can assume that the blob has reached the UA limits.  This is different from a memory exception due to e.g. heap space limitations.

If there is a memory exception due to lack of heap space, then I agree that all bets are off and any data returned may not be valid.

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

I'm concerned that it may be difficult for the UA (or the application)  to determine whether its data is valid when there is an error.  I'd be more comfortable if someone had prototyped the API and determined  that there is a set of errors that are reasonably common and for which it's easy to return valid data.   I would suggest leaving this out for the time being.  It will be easy enough to add it in a later draft if it turns out to be useful.


-          Jim

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

On point a, I prefer the combination of the recordingerror event + dataavailable. It seems weird to have a one-off event handler defined for such an edge-case as a memory limitation. Then we have to expect that applications always have to register for dataavailable + recordingerrorwithdata, which seems very redundant.

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

Travis, Jim,
No feedback on what I sent out yet.  Since we are opening up two broader discussions about how error reporting and muting of tracks should be handled, I will avoid those topics and will try to highlight areas that I think could be modified in Jim's latest proposal based on the version I sent out earlier this week.


a)      onrecordingerror.  I had suggested adding another event - onrecordingerrorwithdata.  This would allow the developer to create a handler when the recording has to be discontinued due to (most likely) a memory limitation, but data can be returned from the UA.  An alternative could be raising an onrecordingerror event and a dataavailable event, but this makes it more difficult for the developer from providing a special handler for when data is returned from the UA while the error has occurred (e.g. displaying a message to the end user such as "Out-of-memory error - your recording was prematurely stopped."

b)      AvailableRecordingFormats.  I had suggested augmenting this object with VideoRecordingDimensionOptions.  This is consistent with many native media recorders, which do not allow arbitrary settings of recording width and height but provide choices from predetermined pairs.

c)       Error codes.  I had suggested some fixed error codes, and Jim's latest version suggests similar ones that are sufficient IMO.  The Geoloc. error reporting allows for vendor specific error messages in addition to pre-specificed codes.  I think we want to avoid such ambiguity in the spec, so I would recommend removing 'message' from RecordingError.  Also, based on my reading, UA-specific messages cannot be returned as DOMErrors but can be returned as DOMExceptions (see http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#domexception)).

d)      I am still unclear on how recording warnings will be used, and if we go with warnings in this spec it seems like we will be breaking new ground for web specifications.  I tend to agree with the POV offered by Robert O'Callahan in http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0094.html about erroneous API calls (e.g. pausing a recording that is in the 'inactive' state).  If the event is sufficiently significant that we feel the developer must be alerted and be allowed to define a handler, then the event should probably be accompanied by an error or exception.

-Giri

From: Travis Leithead [mailto:travis.leithead@microsoft.com]
Sent: Thursday, December 20, 2012 10:58 AM
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...

*         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).

*         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.

*         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 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.


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