Re: Feedback on the recording proposal

On Wed, Oct 10, 2012 at 2:13 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

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

Ah, great.


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

I would hope that the start of the recorded tracks would be an acceptable
synchronization point...

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

Yeah, I don't think that's specified right now. In Gecko all the streams
that share tracks would be synchronized, though.

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]