- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 7 Dec 2012 19:51:39 +0100
- To: public-media-capture@w3.org
On 12/07/2012 07:34 PM, Travis Leithead wrote:
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>
>> On 7 December 2012 09:55, Travis Leithead
>> <travis.leithead@microsoft.com> wrote:
>>> In the call, it was mentioned that we have a requirement to be
>>> able to
>> change the source of a track while preserving the identity of the
>> track for the purposes of a PeerConnection and possibly other
>> reasons.
>>
>> I think that this is solving the wrong problem. We already have
>> this capability for <video> tags. Set the .src attribute to point
>> to a new URL.
>>
>> This is only a problem for RTCPeerConnection because it negotiates
>> streams based on MediaStream(Track) identifiers. That's the real
>> problem.
>>
>> Here's the solution that I propose:
>>
>> partial interface RTCPeerConnection { void addStream(MediaStream
>> newStream, optional MediaStream streamToReplace); };
>>
>> This of course has ramifications for how streams are handled.
>> It's still unclear whether a track identifier can change; and
>> whether new streams and tracks are created when a stream is added
>> to RTCPeerConnection. c.f. Adam's proposal on Outgoing/Incoming
>> streams.
>
> If this is the case, then I won't try to support changing a track's
> source as a functionality of the track or constraints.
I agree to that this is a problem that is mostly associated to when
tracks/streams travel over a PeerConnection. I support that we do not
solve it in the "Media Capture and Streams" doc, but rather in the
WebRTC doc (if we are convinced of the need).
>
Received on Friday, 7 December 2012 18:52:05 UTC