Implement getDisplayMedia for screen capture to comply with spec changes

NEW
Unassigned

Status

()

Core
WebRTC: Audio/Video
P3
normal
Rank:
25
a year ago
14 days ago

People

(Reporter: mchiang, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(URL)

As discussed in bug 1313758 comment 8, we currently implement an outdated draft [2] of the spec.

Updated

a year ago
Rank: 25
Priority: -- → P2
In the latest Screen Capture draft (Draft 27), the constraint is reduced to a simple boolean, app won't be able to indicate the surface type, then we have only two choices:

1) Let user choose the surface type; then let user choose the window / screen / applicationto share.
2) Always provide one type of surface type.
In hindsight, I think an obstacle to implementing the spec here is that our current implementation allows passing in constraints to downscale the resolution and decimate frame rates from the very first frame. Constraints do not filter the selection list one bit.

We consider this a useful feature, since desktops tend to be of extremely large resolution, and their high frame rate to be overkill for most WebRTC use.

The spec on the other hand disallows constraints on getDisplayMedia, except on subsequent calls to track.applyConstraints presumably.

This presumably means JS would need to expect the full-size full-frame-rate stream first, and then issue

    await track.applyConstraints({width, height, frameRate})

on the video track before attaching it to a sink.

Martin, does this match your intent? Do you have any guidance on how to implement this in a performant manner? Should we be concerned that this may cause capture to fail in situations where returning the unscaled result might fail where a downscaled version might not?
Flags: needinfo?(martin.thomson)

Comment 3

4 months ago
Can you take that as an issue to the screen sharing repo.  The intent behind removing the constraints was primarily to avoid the constraints being used to guide selection.  No one had a use case that they could articulate for other constraints, so removing them entirely was easier.  Adding them back isn't impossible.
Flags: needinfo?(martin.thomson)
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Duplicate of this bug: 1400224
You need to log in before you can comment on or make changes to this bug.