W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2014

Re: replaceTrack proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 3 Sep 2014 20:29:06 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>
CC: Peter Thatcher <pthatcher@google.com>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D05E445@ESESSMB209.ericsson.se>
On 03/09/14 22:14, Martin Thomson wrote:
> On 3 September 2014 13:03, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>> With respect to the success/failure callbacks, I am wondering whether most of the potential errors wouldn't be handled via an Exception, rather than requiring a failure callback.  Also, I'd expect that setTrack would return quickly so that async behavior isn't an absolute requirement.   Or am I missing something that requires async behavior?
> Some checks (that both are audio, that both have identical
> peerIdentity constraints, that both are in the right state) are
> trivial and wouldn't require a dispatch.
> However, in our implementation, it's likely that confirming that a
> track is a compatible replacement could require asynchronous
> dispatches to a separate thread.  Blocking the main processing thread
> for a synchronous dispatch would be very bad.  In general, I'd prefer
> to have things that need to look at media be asynchronous to avoid any
> risk that a synchronous dispatch is needed.

In an earlier discussion Harald brought up the example of cameras that 
have built in encoders. If you switch track, isn't there a risk that the 
new track is sourced by a camera that produces a format that can be 
handled locally, but not by the remote end - and that won't be found out 
until after an SDP O/A?
Received on Wednesday, 3 September 2014 20:29:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:41 UTC