1243582 - Support for 90p video in simulcast

Status: RESOLVED DUPLICATE of bug 1244913

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[rdaware]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36

Steps to reproduce:

Currently, there is no support for 90p video if camera does not have 90p as native resolution.
Step to reproduce: 
1. Confirm if you camera does not support 90p resolution.
2. Try to get 90p resolution with this link: http://jsfiddle.net/swytxe44/


Actual results:

Should get 90p resolution


Expected results:

Cannot get 90p resolution if camera does not support it

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

There are two issues here: one is 90p video from getUserMedia(), which is what the description notes.  Right now we only supply sizes that the source camera offers.  Supporting sending video in 90p (single stream) requires implementing width and height settings in the RTPSender or applied to the track.  Jan-Ivar?

Support in Simulcast ("multicast" in the original title, but I presume this means simulcast) requires being able to set the resolution for the encoding via the simulcast interface.  I *think* this should now work in 46 and 47.  Byron?

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Rdaware, how is this different from bug 1227343?

Comment 3

[Byron Campen [:bwc]]

(In reply to Randell Jesup [:jesup] from comment #1)
> Support in Simulcast ("multicast" in the original title, but I presume this
> means simulcast) requires being able to set the resolution for the encoding
> via the simulcast interface.  I *think* this should now work in 46 and 47. 
> Byron?

No. We only support max-bitrate at the moment.

Comment 4

[rdaware]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #2)
> Rdaware, how is this different from bug 1227343?

Hi Jan-Ivar,

This is not different from bug 1227343. We know that currently firefox only support sizes offered by camera. I filed this bug to request this feature. We need this feature for our product. Would this be possible to be added anytime soon?

Thanks,
Rahul

Comment 5

[Maire Reavy [:mreavy]]

(In reply to rdaware from comment #4)

> This is not different from bug 1227343. We know that currently firefox only
> support sizes offered by camera. I filed this bug to request this feature.
> We need this feature for our product. Would this be possible to be added
> anytime soon?

Hi Rahul, I've made this a P1 bug which means we'll try to get this landed in Fx47 (the current Nightly cycle, which ends March 7th).

Jan-Ivar -- I think you are the best person to take this bug.  Can you give me a rough idea of how much effort this will take?  Thanks.

Comment 6

[Maire Reavy [:mreavy]]

After our conversations today in irc (you can check the #media log to see what we said), we're going to implement Bug 1244913 to satisfy the request in this bug.  If we want to discuss this further, let's have the discussion in Bug 1244913.  Thanks.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

To summarize the discussion in #media, gUM might not be the right place to solve this (assuming the need here is thumbnails in a WebRTC call).

The reason is that, Chrome notwithstanding, the spec's constraints mini-language used to determine fitness of discrete combinations of dimensions and frame rates, becomes pointless if we scale to fit whatever is passed in. The ability to discover inherent camera resolutions and framerates would disappear, and track.getCapabilities() would get real boring.

Instead, the spec seems to want us to use RTCRtpEncodingParameters.scaleResolutionDownBy to control encoding resolution (Bug 1244913).

Hopefully this will fit our needs here.

Note that rtpSender.getParameters().encodings is an array or RTCRtpEncodingParameters, so it can have a single entry (unicast) or several (simulcast).

To get a specific resolution, like e.g. 90p, would require something like:

    RTCRtpEncodingParameters.scaleResolutionDownBy = track.getSettings().height / 90;