Re: new draft of recording

Picking up on Really Old Threads:

On 04/12/2013 11:23 AM, Randy Lin wrote:
> For the RecordingErrorNameEnum & RecordingExceptionEnum webIDL,
> Could we let the naming style to like the DOMError naming?
> ie "INVALID_STATE" vs "InvalidStateError"

Note: DOMError specifies error names in the CamelCase form 
(invalidStateError) for string errors, and specifies the 
UPPER_CASE_WITH_UNDERSCORES form (INVALID_STATE) only as the name for 
integer errors, which are "retained for backwards compatibility".

We should not add more UPPER_CASE_WITH_UNDERSCORES, if I read the DOM 
spec correctly.

> BTW, what's the purpose for adding the interface:RecordingError?
> Is let UA can get the detail message from mediaRecorder object and limit the naming type of RecordingError?
> ---
> Randy
>
> ----- Original Message -----
> From: "Robert O'Callahan" <robert@ocallahan.org>
> To: "Jim Barnett" <Jim.Barnett@genesyslab.com>
> Cc: "Travis Leithead" <travis.leithead@microsoft.com>, public-media-capture@w3.org
> Sent: Wednesday, April 3, 2013 4:14:59 AM
> Subject: Re: new draft of recording
>
>
> On Wed, Apr 3, 2013 at 12:43 AM, Jim Barnett < Jim.Barnett@genesyslab.com > wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> OK I guess. What about stop, pause and resume?
>
>
>>> They’re part of the same use case that Travis described – letting the UI provide feedback about when recording is actually happening.
>
> The thing is that, bearing in mind the firing of the events can be delayed, they're not perfectly accurate anyway. So are you saying that in typical implementations, there *has to be* a long (order of seconds, I guess) delay between calling pause() and recording actually pausing? And ditto for resuming and stopping?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> At one of our prior F2F meetings, one of the use cases for warnings was to alert the user if the inbound stream configuration changes in such a way that could still be supported by the recorder, but might be something the code would want to respond to. For example, new tracks being added/removed while recording.
>
>
>
>
>
> That's covered by track add/remove events already specced on MediaStreams.
>
>>> It’s a more complicated case than that. Whether a track can be added to a recording that’s underway depends on the track type and the mime type. So the add/remove track events are not sufficient by themselves.
>
>
> Then I think we should have a specific API for that which allows the app to determine which track(s) aren't being recorded. It could be a specific unsupportedtrack event, or we could let the app listen for the addition of a new track, and provide an API on the StreamRecorder to check whether a MediaStreamTrack is being recorded by the recording. Maybe the latter is better since it would also be useful for the case where a newly-created StreamRecorder can't record all the existing tracks.
>
> Rob

Received on Wednesday, 12 June 2013 12:45:51 UTC