Re: replaceTrack proposal

On 9/3/2014 4:29 PM, Stefan Håkansson LK wrote:
> 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
 >> I thought that Martin's proposal was that the new camera had to 
produce the _same_ encoding, or the swap failed.  I think that it would 
make sense for the swap to be limited to cases where the exchange was 
transparent to the other end.
Jim

Received on Wednesday, 3 September 2014 22:53:54 UTC