[whatwg] PeerConnection and Stream API feedback
per-erik.brodin at ericsson.com
Wed Jun 8 00:21:39 PDT 2011
We have made an experimental implementation of PeerConnection and the
Stream API and would like to provide some feedback that we have
collected so far.
The TrackList feature seems to be a good way to control the different
components of a Stream. Although it is said that tracks provide a way to
temporarily disable a local camera, due to the nature of the
ExclusiveTrackList it is still not possible to disable video altogether,
i.e. to 'pull down the curtain' in a video conference. I noticed that
there is a bug filed on this issue but I do not think the proposed
solution there is quite right. There is a state in which no tracks are
selected in an ExclusiveTrackList, when the selected index returned is
-1. A quick fix would be to allow also setting the active track to -1 in
order to deselect all the other tracks.
I think a note would be appropriate that although the label on a
GeneratedStream is guaranteed to be unique for the conceptual stream,
there are situations where one ends up with multiple Stream objects with
the same label. For example, if the remote peer adds a stream, then
removes it, then adds the same stream again, you would end up with two
Stream objects with the same label if a reference to the removed Stream
is kept. Also, if the remote peer takes a stream that it receives and
sends it back you will end up with a Stream object that has the same
label as a local GeneratedStream object.
We prefer having a StreamRecorder that you have to stop in order get the
recorded data (like the previous one, but with asynchronous Blob
retrieval) and we do not understand the use cases for the current
proposal where recording continues until the recorder is garbage
collected (or the Stream ends) and you always get the data from the
beginning of the recording. This also has to be tied to application
quota in some way. The recording example does not seem correct either,
it never calls record() and then it calls getRecordedData() directly on
the GeneratedStream object.
Instead of blob: we would like to use stream: for the Stream URLs so
that we very early on in the media engine selection can use the protocol
scheme to determine how the URL will be handled. Blobs are typically
handled in the same way as other media playback. The definition of
stream: could be the same as for blob:.
In addStream(), the readyState of the Stream is not checked to see if it
is ENDED, in which case adding a stream should fail (perhaps throwing a
TypeError exception like when passing null). When a received Stream is
removed its readyState is not set to ENDED (and no 'ended' event is
PeerConnection is an EventTarget but it still uses a callback for the
signaling messages and this mixture of events and callbacks is a bit
awkward in my opinion. If you would like to change the function that
handles signaling messages after calling the constructor you would have
to wrap a function call inside the callback to the actual signal
handling function, instead of just (re-)setting an onsignal (or
whatever) attribute listener (the event could reuse the MessageEvent
Perhaps signalingMessage() could be renamed to
add/handle/process/SignalingMessage() or similar to better indicate that
it is used to input signaling messages received from the other peer.
There is a potential problem in the exchange of SDPs in that glare
conditions can occur if both peers add streams simultaneously, in which
case there will be two different outstanding offers that none of the
peers are allowed to respond to according to the SDP offer-answer model.
Instead of using one SDP session for all media as the specification
suggests, we are handling the offer-answer for each stream separately to
avoid such conditions.
We recently published a snapshot of our modified WebKitGTK+ library as
an installable Ubuntu 11.04 package, should anyone wish to experiment
with the API. (Note that the API entry points are prefixed with the
'webkit' vendor prefix, e.g. webkitPeerConnnection)
More information about the whatwg