- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 7 Aug 2013 17:51:58 +0000
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: Jim Barnett <Jim.Barnett@genesyslab.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 8/7/13 7:42 PM, Stefan Håkansson LK wrote: > On 8/7/13 7:19 PM, Travis Leithead wrote: >> My general feeling is that the Recorder is a sink for media, just >> like <img> and <video>. Therefore, it should be able to configure >> it's recording dimensions just as independently as those other sinks >> do. > > But the media element can not be configured this way? For sure you can > adjust its display width and height, but the intrinsic video dimensions > are governed by the source (and can be read from the readonly videoWidth > and videoHeight attributes of a video element) - at least that is my > understanding. I take that back. While valid when you play a file, we've definitely discussed that the width/height of a video element (when playing MediaStreamTrack) should influence the dimensions. > > Also, to me it seems that this could be confusing. What happens if you > put mandatory constraints on a VideoStreamTrack to be 300*400, and then > sets the recording of the same track to 500*900? It seems cleaner to me > to set dimensions on the track to be recorded, and let the recorder just > record it. > > I don't have a strong view on this, I am as usual just looking for > opportunities for simplifications (without losing important > functionality) :) > >> >> -----Original Message----- From: Jim Barnett >> [mailto:Jim.Barnett@genesyslab.com] Sent: Wednesday, August 7, 2013 >> 7:16 AM To: Stefan Håkansson LK Cc: public-media-capture@w3.org >> Subject: RE: Width/height in MediaStream Recorder >> >> I think that the more general question is whether it is sufficient to >> have capabilities/settings only at the Stream level, or if users will >> want to set them on the Track level. I suppose that we could say >> that for Recording we support only Stream-level capabilities, but I'm >> not sure what use cases that would block. >> >> - Jim >> >> -----Original Message----- From: Stefan Håkansson LK >> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Wednesday, August 07, >> 2013 4:59 AM To: Jim Barnett Cc: public-media-capture@w3.org Subject: >> Re: Width/height in MediaStream Recorder >> >> On 2013-08-06 16:07, Jim Barnett wrote: >>> This could be a fairly general problem. We also list MimeType as >>> an attribute. Couldn't different Tracks have different mime >>> types? Different frame rates? Couldn't just about anything differ >>> between tracks? >> >> Regarding mime-types, isn't that something that is decided by the >> recorder (as long as they are just MediaStreamTracks, there are no >> mime-types involved)? So basically we could decide that the recorder >> uses one mime type that covers the entire MediaStream being >> recorded. >> >> I guess that in principle frame rate could differ between tracks, but >> that is nothing that is exposed in the Recorder API as far as I can >> tell. >> >> Could we not just remove the imageHeight/Width attributes (and the >> possibility to set them)? You can find out by attaching the recorded >> blob to a media element, and to set you could use constraints on the >> tracks of the MediaStream that you want to record. (I'm probably >> missing some important use case here.) >> >> Stefan >> >>> >>> - Jim >>> >>> -----Original Message----- From: Stefan Håkansson LK >>> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Tuesday, August >>> 06, 2013 8:20 AM To: public-media-capture@w3.org Subject: >>> Width/height in MediaStream Recorder >>> >>> Hi, >>> >>> (sorry if I miss something obvious) the MediaRecorder has >>> imageWidth and imageHeight readonly attributes. What will these >>> represent in cases when there is more than one VideoStreamTrack in >>> the MediaStream being recorded? >>> >>> Stefan >>> >>> >>> >> >> >> >> >> >> >> > >
Received on Wednesday, 7 August 2013 17:53:16 UTC