Closed
Bug 1359668
Opened 9 years ago
Closed 9 years ago
Screen-sharing track.getSettings() should reflect actual video width and height once frames come in.
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla55
| Tracking | Status | |
|---|---|---|
| firefox55 | --- | fixed |
People
(Reporter: jib, Assigned: mchiang)
Details
Attachments
(1 file)
(A follow-up to bug 1359662) From my best reading of the mediacapture-main spec [1] track.getSettings() should return the device's current resolution in width and height.
For screen-sharing this would I suppose translate to the actual dimensions of the shared screen/window (after being proportionally scaled to fit within any max constraints).
STR:
1. Open https://jsfiddle.net/jib1/77nqay6w/
2. Pick Screen to share: "Entire screen", and share screen.
3. Click the button named "160".
Expected result: Applied 160 x 120 got 176 x 110
(where 176 x 110 are the numbers that match the live video.videoWidth and video.videoHeight)
Actual result (after bug 1359662 fixed): Applied 160 x 120 got 160 x 120
The tricky part is that for screensharing we don't know the source dimensions until the first frame arrives. I see a couple of options:
A) Return 160 x 120 until the first frame arrives, then 176 x 110 and update live from then on.
(yes, resizing a shared window changes the video dimensions dynamically!)
B) Somehow delay gUM success until frames arrive, or do a dry-run somehow.
I thinking (A) might suffice, and that people wait for video.onloadedmetadata.
The reason I broke this out as a separate bug is it's a bit tricky. See original patch [2] for background.
In short, dst_width and dst_height are known on the incoming frame on a render thread here [3].
We probably need to register some form of callback [4] to get this data out to the media thread where we send a runnable to main thread with the values (see code in bug 1359662).
[1] https://w3c.github.io/mediacapture-main/getusermedia.html#dom-constrainablepattern-getsettings()
[2] https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1211656&attachment=8683444
[3] https://dxr.mozilla.org/mozilla-central/rev/f229b7e5d91eb70d23d3e31db7caff9d69a2ef04/media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc#703
[4] https://dxr.mozilla.org/mozilla-central/rev/f229b7e5d91eb70d23d3e31db7caff9d69a2ef04/media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc#533
Updated•9 years ago
|
Rank: 25
Priority: -- → P2
Updated•9 years ago
|
status-firefox55:
--- → affected
status-firefox57:
affected → ---
| Comment hidden (mozreview-request) |
| Assignee | ||
Updated•9 years ago
|
Assignee: nobody → mchiang
| Reporter | ||
Comment 2•9 years ago
|
||
| mozreview-review | ||
Comment on attachment 8862776 [details]
Bug 1359668 - update mSettings.mWidth and mSettings.mHeight when there is a frame size change.
https://reviewboard.mozilla.org/r/134656/#review138104
Great! That was a lot simpler than I thought. Thanks! :)
Attachment #8862776 -
Flags: review?(jib) → review+
| Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/cff101ea16af
update mSettings.mWidth and mSettings.mHeight when there is a frame size change. r=jib
Keywords: checkin-needed
Comment 4•9 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•