RE: Questions/Comments on Media Stream Recording

Answers in-line set of by ‘>>’ to the extent that I have them:

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Friday, May 24, 2013 3:24 PM
To: Jim Barnett; robert@ocallahan.org
Cc: Adam Bergkvist; Frederick.Hirsch@nokia.com; public-media-capture@w3.org
Subject: RE: Questions/Comments on Media Stream Recording

Let me preface by saying that I am not arguing for a getStream() method.  Just had some questions.  Assume the following:

--Code snippet--
var mediaRecorder = new MediaRecorder(someStream);
mediaRecorder.ondataavailable = gotChunk;
mediaRecorder.start(timeSlice); // Start incremental recording

function gotChunk(evt) {
                var recStream = evt.target.stream;
                var recStreamTrack = recStream.getTrackbyID(0);  // Assumption that there is always a track ID 0
                rec.StreamTrack.applyConstraints({mandatory:  […]);
                }

--Code snippet ends--

My questions are (assuming that the code example I provided above is mostly accurate):


1.       Is recStream a clone of the MediaStream used in the contructor?
>> No.  I don’t see any reason to clone.

2.       What occurs when applyConstraints results in an overconstrained condition?
>> This depends on how the MediaStream behaves in an overconstrainted condition.  If media keeps flowing (i.e. using the previous valid constraint values), recording will continue. (I don’t see anything about this in the current draft, but I assume that this is what the MediaStream would do.)  If media stops flowing, the recording behavior will depend on exactly how the stop occurs.  Is it as if the MediaStream were ended?  If so, recording  would terminate normally.

a.       Does recording immediately cease?

b.      Is there an error or exception thrown?  If an error is thrown, would the condition be ILLEGAL_STREAM_MODIFICATION?
>> The MediaStream will throw an overconstrained error.  But if media keeps flowing, recording will continue and there won’t be any error at the recording level.

c.       If an error event is thrown, does it get thrown first or do the affected tracks overconstrained events get thrown first?

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Friday, May 24, 2013 11:53 AM
To: robert@ocallahan.org<mailto:robert@ocallahan.org>
Cc: Adam Bergkvist; Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>; Mandyam, Giridhar; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: RE: Questions/Comments on Media Stream Recording

Suits me.  I won’t add an accessor function.


-          Jim

From: rocallahan@gmail.com<mailto:rocallahan@gmail.com> [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Friday, May 24, 2013 1:34 PM
To: Jim Barnett
Cc: Adam Bergkvist; Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>; mandyam@quicinc.com<mailto:mandyam@quicinc.com>; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: Re: Questions/Comments on Media Stream Recording

On Fri, May 24, 2013 at 9:04 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
  It's just a quibble about style.  When I used to program in C++, I was taught never to write code like:

   // or if you have a reference to the recorder you
   // can access it directly
   recStream = recorder.stream;
The idea was that accessing instance variables directly broke encapsulation, and that it was better to always use an accessor function:
    recStream = recorder.getStream()

This does not apply to the Web at all. In Web APIs, it's completely normal (and indeed, encouraged) for attributes to be part of the public API of an interface.

Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Friday, 24 May 2013 19:38:06 UTC