1289665 - Concurrent gUM call with effectively different constraints doesn't resize video in time for loadedmetadata

Status: NEW

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

Description

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

STR:
  1. In Nightly, open https://jsfiddle.net/jz4sjj2u/
  2. Allow camera twice.

Expected result:

  gUM({"width":{"max":200},"height":{"max":150}})
  got track: {"frameRate":30,"height":144,"width":176}
  resized video1 to 176x144
  video1 metadata loaded: 176x144
  video1 after 1 sec: 176x144

  gUM({"width":{"max":160},"height":{"max":120}})
  got track: {"frameRate":30,"height":120,"width":160}
  resized video1 to 160x120
  resized video2 to 160x120
  video2 metadata loaded: 160x120
  video2 after 1 sec: 160x120

Actual result:

  gUM({"width":{"max":200},"height":{"max":150}})
  got track: {"frameRate":30,"height":144,"width":176}
  resized video1 to 176x144
  video1 metadata loaded: 176x144
  video1 after 1 sec: 176x144

  gUM({"width":{"max":160},"height":{"max":120}})
  got track: {"frameRate":30,"height":120,"width":160}
  resized video2 to 176x144
  video2 metadata loaded: 176x144
  resized video1 to 160x120
  resized video2 to 160x120
  video2 after 1 sec: 160x120

The actual result is undesirable because the video changes size after loadedmetadata has fired, which may surprise the script.

This is not a regressions per se, since before bug 1213517 all concurrent gUM calls were locked to the resolution of the first gUM call, which is also not the expected result, and is arguably inferior behavior.

However, the new behavior is arguably poor since resizing happens after JS is likely to read the size (though the spec allows browsers to resize at any time).

Comment 1

[Andreas Pehrson [:pehrsons]]

Can we do something other than delaying the success callback?

Comment 2

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

FWIW I'd be happy with delaying the success callback if there's something specific to wait on other than a timer.

Comment 3

[Andreas Pehrson [:pehrsons]]

Do we know when the camera has restarted?

We can always let MSG tell us when it has processed something by doing something like [1] with a Pledge.

Or perhaps just pass in a track listener to the MediaStreamTrack (pipes through to the MSG) and look at the queued segments. Then schedule a runnable to trigger the success callback on main thread. See [2].


[1] http://searchfox.org/mozilla-central/rev/d9a04f71630ce4203ff0a5e26722723045d035b5/dom/media/MediaStreamGraph.cpp#3190
[2] http://searchfox.org/mozilla-central/rev/d9a04f71630ce4203ff0a5e26722723045d035b5/dom/media/MediaStreamListener.h#158

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.