Support for 90p video in simulcast

RESOLVED DUPLICATE of bug 1244913

Status

()

Core
WebRTC: Audio/Video
P1
major
Rank:
15
RESOLVED DUPLICATE of bug 1244913
2 years ago
2 years ago

People

(Reporter: rdaware, Unassigned)

Tracking

44 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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
(Reporter)

Updated

2 years ago
Severity: normal → major
OS: Unspecified → All
Hardware: Unspecified → All

Updated

2 years ago
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
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?
Status: UNCONFIRMED → NEW
Rank: 15
Ever confirmed: true
Flags: needinfo?(jib)
Flags: needinfo?(docfaraday)
Priority: -- → P1
Summary: Software support for 90p video support in multicast → Support for 90p video in simulcast
Rdaware, how is this different from bug 1227343?
Flags: needinfo?(jib) → needinfo?(rdaware)

Comment 3

2 years ago
(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.
Flags: needinfo?(docfaraday)
(Reporter)

Comment 4

2 years ago
(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
Flags: needinfo?(rdaware)
(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.
Flags: needinfo?(jib)
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jib)
Resolution: --- → DUPLICATE
Duplicate of bug: 1244913
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;
You need to log in before you can comment on or make changes to this bug.