W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

Re: Summary of replace track status

From: Randell Jesup <randell-ietf@jesup.org>
Date: Mon, 01 Jun 2015 12:43:55 -0400
Message-ID: <556C8BCB.4090106@jesup.org>
To: public-webrtc@w3.org
On 6/1/2015 10:19 AM, Stefan Håkansson LK wrote:
> I agree, and if replaceTrack (initially at least) was specced to only 
> work if the UA could simply replace the content of existing outgoing 
> RTP stream(s) - SSRC and all being the same - would feel the simplest 
> (of course a full ref frame must be coded for the first frame of the 
> new track).

Note that replaceTrack should have no need to encode a full reference 
frame - though it may make sense to do so.

> Personally I think that would be the best approach for 1.0; the
> application can always resort to add/removeTrack (and perhaps mute /
> unmute events are a good indication at the remote side on when to switch
> video that is displayed?) if replaceTrack fails.

I want to keep it simple.  The above is simple, which I like.  It would 
require boilerplate to handle pre-encoded sources as you indicate, which 
is not great, but effectively is unneeded today - and I should note that 
using a pre-encoded source is currently not simple and far from ready 
for implementation - for example, how does bitrate control get passed 
back to the source?  How about error recovery?  etc.  So while the 
simple version of replaceTrack() may not handle such sources (forcing 
the workaround above on failure), I think that's something we can live with.

Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Monday, 1 June 2015 16:45:07 UTC

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