- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 8 Oct 2012 08:33:56 +0200
- To: public-media-capture@w3.org
On 10/07/2012 11:30 PM, Harald Alvestrand wrote: > On 10/07/2012 09:45 PM, Jim Barnett wrote: > 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. I tend to agree. In my mind I had a model similar to the media element when it comes to handling of individual tracks. There the app can select which (there can be several active - if so they are mixed) audio tracks that are actively contributing to the output audio; and select one of the video tracks (if more than one in the source) that is played. I think it should be similar for recording, only that all tracks are recorded by default (but the app can select to disable one or more if it so wishes). > 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 >> >
Received on Monday, 8 October 2012 06:34:21 UTC