W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2013

Re: Width/height in MediaStream Recorder

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 7 Aug 2013 17:42:12 +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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C350746@ESESSMB209.ericsson.se>
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 

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:42:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC