RE: Feedback on the recording proposal

Comments on a couple of issues:

1.       The current draft states that stopRecording fires after the final dataavailable event, precisely so that it can serve as a signal that the app won’t be receiving any more packets.

2.       (This is in response to Robert’s suggestion that if we want to capture a single Track, we put it in its own MediaStream.)  Consider the case where we want to record audio and video into separate captures/files (so that we can run media processing on them individually) but will later want to play them back synchronized.  Hence we need to store some sort of ‘marker’ with each capture  that can be used for alignment.  Since synchronization occurs at the MediaStream level, wouldn’t we have to capture the underlying  Tracks from the same MediaStream so that the data is synchronized as we capture it?  Or is it the case that if we put Track1 and Track2 together in MediaStream1, and then place them separately in MediaStream2 and MediaStream3,  they will be synchronized as they are played in Stream2 and Stream3?  The spec doesn’t state how synchronization occurs, so I, at least, have had trouble figuring out issues like this.   

 

-          Jim

 

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Tuesday, October 09, 2012 8:01 AM
To: Adam Bergkvist
Cc: public-media-capture@w3.org
Subject: Re: Feedback on the recording proposal

 

On Wed, Oct 10, 2012 at 12:11 AM, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:

 On 2012-10-09 07:13, Robert O'Callahan wrote:

 Does the last dataavailable event happen before or after the
 stoprecording event? I guess it should be "before".

  

 What if the data (on some platforms) needs to undergo some processing before it can be handed to the application as a Blob. Shouldn't "stoprecording" fire when the recording is actually stopped and then "dataavailable" when the Blob is available.

 

How then would you know when you've received all the data packets?

Since events fire asynchronously, you can't fire stoprecording "when" the recording stops, only after it has stopped, so I think it's OK to delay it until after the last dataavailable.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47]