Chrome is beginning to default their SDP semantics to the WebRTC standard
'Unified Plan', and Verto does not currently construct its SDP according
to this standard. For now, force the browser to use 'Plan B' semantics.
The Verto libs currently have total control over the streams associated with
placing any kind of call, handling both their creation and teardown
automatically.
This patch provides the option for a developer to instead pass pre-created
MediaStream objects when instantiating the Verto object, or when calling
Verto.newCall(), and the library will bypass the work of creating those
streams, and of destroying those streams when the call is torn down.
This is particularly useful if the application wants to manage its own streams,
such as re-using them in other non-Verto aspects of the application.
The patch also creates some internal convenience functions for managing the
video element related to a local video stream.
This patch adds an onRemoteStream callback, which can be specified on the Verto
instance, or per dialog. The callback is fired when the remote stream from a
call is received, and receives two arguments, the first is the remote stream,
the second is the Verto dialog object.
As described at https://bugs.chromium.org/p/chromium/issues/detail?id=862325,
some Android devices using Chrome fail a getUserMedia() request when
frameRate.min is specified.
This is due to a bug in both the device (reporting a 0 min frameRate), and
Chrome, which fails to catch this and set a reasonable fallback value.
While a fix has gone into Chrome, it might be awhile before this fix makes it
into their stable release, so filing this with my quick hack to prevent the
error on Android devices.
Note this fix could certainly be more robust (maybe detect Chrome version, or
some test to see if min frameRate from the device returns 0), and it gets the
job done as a start.
getMediaParams() was using a legacy version of the video constraint param to
specify a deviceId.
checkRes() was incorrectly setting video constraints such that it was not
properly testing specific video devices.
iOS requires a 'playsinline' attribute to be added to video tags, however a
'controls' attribute was erroneously added, and is unneeded.
See https://github.com/webrtc/samples/issues/929#issuecomment-330816567 and
following comments for confirmation.
Removing this attribute reduces UI noise and 'click contention' on video
elements.
QQVGA is a standard 160x120 resolution, useful for cases of very slow
upload bandwidth. Adds the resolution to the core FSRTC lib, and to
the Verto video demo and Verto Communicator
