Re: MediaStreams and state changes

On 08/01/2012 03:54 PM, Travis Leithead wrote:
>> -----Original Message-----
>> From: Randell Jesup [mailto:randell-ietf@jesup.org]
>> Sent: Thursday, June 7, 2012 7:18 AM
>>
>> For discussion as part of the constraints issues today:
>>
>> I have some unease about some parts of MediaStreams and getUserMedia
>> that we haven't addressed or haven't discussed in detail.
>>
>> One is changing video parameters after getUserMedia().
> This is relevant to the other thread I started (http://lists.w3.org/Archives/Public/public-media-capture/2012Jul/0069.html)--sorry, somehow I missed this particular thread. I did, however, want to share some thought here as well as they seem relevant to the general conversation.
>
>> Another is changing parameters of a stream that originates somewhere
>> other than getUserMedia.  video elements using
>> captureStreamUntilEnded(), PeerConnection-sourced streams (which might
>> want to renegotiate based on the request, or send RTCP feedback, or use
>> application-specific signaling), algorithmic generators (such as the Audio API),
>> etc.
>>
>> Right now, we've  somewhat waved our hands and said there'd be a method
>> to re-do constraints after a MediaStream is created.  I generally am uneasy
>> with this, and I'm especially uneasy when we're not talking about a
>> getUserMedia()-originated stream.
> So, now we have a proposal on the table for this. I took care to isolate the proposed API to a LocalMediaStream, and essentially punted on the option to allow downstream consumers to be able to apply change requests (directly through an API). I'd originally wanted to tie the API to the MediaStreamTrack, but then you allow any consumer (downstream or upstream) to be able to request changes, and these probably aren't relevant for Tracks that come from PeerConnection. What would be more ideal, is to have a derived LocalMediaStreamTrack object with these abilities, that is only created by getUserMedia, and whose interface cannot be obtained after forking the track (for example, such a local media stream track used in the constructor to a new MediaStream object would be handled only as a media stream track--losing its local-ness.)
>
(resurfacing from IETF-daze)

There are cases where changing constraints on an incoming MediaStream 
from a PeerConnection is quite relevant.

In particular, if the downstream processing of a MediaStream is of such 
a nature that the browser has no idea what the best resolution is, but 
the application has such an idea, it's likely that the best way to 
signal this is to set resolution on the incoming MediaStream - the 
implementation may choose to reencode the stream, renegotiate the 
resolution with the remote party, or both.

I'd define the "change constraints" API on the MediaStream and 
MediaStreamTrack, and just note that there's no expectation that all 
constraints can successfully be applied at any time.

                      Harald

Received on Saturday, 4 August 2012 00:36:11 UTC