W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2016

Re: maxHeight and maxWidth

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 17 Feb 2016 12:40:05 -0800
Message-ID: <CAJrXDUFyFY4kKsi7ejhytt041U2xmpeUGs1HRvmtg029C8ZKmw@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
The use case is the one that Adam started it with, which is sending exactly
90 pixels tall with an RtpSender, which is not possible if the track
outputs something smaller than 90 (even with maxHeight, it's still not
possible).

So then the question becomes: can we create a video track that outputs
exactly 90 pixels in height?  If so, then it's possible to make an
RtpSender send exactly 90 pixels in height (assuming the
DegradationPreference of "maintain-resolution" is very strict).  If not,
then this use case is impossible.

I merely choose MediaRecorder as an alternative use case for wanting a
video track of an exact resolution to simplify the discussion.   I can't
think of any other use cases for a fixed-resolution video track.  But the
real question is whether Adam's proposed use case is even possible to solve.



But while we're talking about video tracks, I am suprised that we don't
have something as simple as and useful as something like this:

var smallTrack = bigTrack.scale({downBy: 2})
var tinyTrack = bigTrack.scale({downToHeight: 90}).crop({toRatio: 16/9})

Of course, we could big-shed this for years, but the idea is have the
ability to do some processing on track to get a new track.  I thought that
track cloning and applyConstraints() could get us something like this, but
it sounds like you're saying that it can't.


On Wed, Feb 17, 2016 at 12:15 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/17/16 2:36 PM, Peter Thatcher wrote:
>
> On Wed, Feb 17, 2016 at 9:45 AM, Jan-Ivar Bruaroey < <jib@mozilla.com>
> jib@mozilla.com> wrote:
>
>> On 2/17/16 12:36 PM, Peter Thatcher wrote:
>>
>> The original thread was about both screencasts and rotating cameras, and
>> I've mostly been focusing on the screencasting case (trying to figure that
>> out before moving on to rotation).
>>
>> But, actually, I have a question for you about getUserMedia:
>>
>> If I specify an exact height of 90 pixels (min and max are 90) and the
>> camera can't open that small, what will an implementation of getUserMedia
>> be expected to do?  Will it scale the camera's input in order to get that
>> exact height, or will it just say "nope"?  Or is it implementation
>> dependent?
>>
>>
>> I believe Chrome will rescale it to whatever you want, whereas Firefox
>> will fail with OverconstrainedError, reflecting the fact that no camera on
>> the machine has a native 160x90 mode. Both are to spec btw, but which one
>> honors the intent of the spec?
>>
>>
> ​So the only way on Firefox to get a video track that outputs less than 91
> pixels in height (perhaps to put into a MediaRecorder to record a small
> video) is to open a bigger video track, open a PeerConnection, create an
> RtpSender, set the maxHeight to 90, hook that PeerConnection into another
> PeerConnection, create an RtpReceiver, and then use the track of that
> RtpReceiver?
>
> Or I guess you could do something like render to a canvas, do the scale in
> there, and then use the canvas as source of the track.
>
> Both seem crazy.
>
>
> Peter, I agree that seems crazy. Can you perhaps elaborate a bit on your
> use-case that requires this 160x90 video stream locally?
>
> .: Jan-Ivar :.
>
>
Received on Wednesday, 17 February 2016 20:41:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:47 UTC