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: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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C35077F@ESESSMB209.ericsson.se>
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

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