Re: recording proposal

On 10/07/2012 09:45 PM, Jim Barnett wrote:
>
> Harald,
>
> Travis and I started with record() attached to MediaStream, but we ran 
> into problems:
>
> 1.Nothing I see requires that a MediaStream have only a single video 
> track.  Should recording blend all the video tracks into one 
> incomprehensible mess?  (The <video> element has a concept of the 
> 'active' or 'primary' video track, but MediaStream doesn't.)
>
I'm not sure this is a valid issue, or it may be container format dependent.
If one tries to record something with multiple tracks onto a container 
format that does not support them, failure is to be expected. But I 
think some container formats can do this just fine (witness DVDs with 
alternate camera angles). Subject matter expertise is needed here.
(I don't know the formats well enough.... I know it's possible to write 
codecs in Javascript, but is writing a Matroska or DVI container 
producer in Javascript something we expect people to do and get right?)
>
> 2.Any form of media processing (e.g., inserting still images into the 
> video stream is one of the use cases, talking to an ASR system will be 
> another) requires access to the individual media streams.
>
Yes, but that's not recording. (Which use case from the use cases 
document were you thinking of?)

I can certainly argue for an API for individual stream access, but a) I 
would not call it recording, and b) I would not call that satisfactory 
for our recording use cases.
>
> As far as I can tell, you need both combined recording and access to 
> the individual tracks.  If that's the case, it's better to start off 
> with a Track level API and figure out how to form a combined recording 
> on top of it, than to start off with a Stream level API and try to 
> extract the individual tracks from it.
>
I think the common case is the full-stream recording, and the access to 
individual-track data is the advanced case. I'd want to do the common 
case first.
YMMV.
>
> -Jim
>
> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Sunday, October 07, 2012 1:40 PM
> *To:* public-media-capture@w3.org
> *Subject:* Re: recording proposal
>
> On 10/05/2012 03:55 PM, Jim Barnett wrote:
>
>     partial interfaceMediaStreamTrack  :EventTarget  {
>
>          void         record  <imap://hta@eikenes.alvestrand.no:143/fetch%3EUID%3E.INBOX.W3C.webrtc.media%3E872#widl-record>  (optionaltimeSliceType  <imap://hta@eikenes.alvestrand.no:143/fetch%3EUID%3E.INBOX.W3C.webrtc.media%3E872#idl-timeSliceType>  timeSlice);
>
>          void         stopRecording  <imap://hta@eikenes.alvestrand.no:143/fetch%3EUID%3E.INBOX.W3C.webrtc.media%3E872#widl-stoprecording>  ();
>
> Oops..... I got lost here.
>
> A MediaStreamTrack contains either audio or video.
>
> Recording, for any practical purpose, requires that one records audio 
> and video together - synchronized, and in some kind of container format.
>
> This also means that the format produced by record() cannot possibly 
> be compatible with the MediaSource API, since that's a combined format.
>
> I don't think this is what people expect of us.
>
> (I see this is listed under "open issues", but I don't think we should 
> even start down this path with this fundamental limitation in place.)
>
>                   Harald
>