Re: [MMUSIC] Unified Plan for SDP Handling

This is weird - I see your reply but i don't see Stephan's email 

On Jul 18, 2013, at 8:43 PM, Justin Uberti <juberti@google.com> wrote:

> 
> 
> 
> On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach <adam@nostrum.com> wrote:
>> On 7/17/13 09:08, Stefan Håkansson LK wrote:
>>> I have a couple of specific questions/comments, coming from a very
>>> WebRTC centric (sorry for that) perspective:
>>> 
>>> * Simulcast: In the current API model, MediaStreamTrack is about the
>>> lowest you can get to. And the same source (camera, microphone) can
>>> source several MediaStreamTrack - and each of those can use individual
>>> constraints for width, height, framerate, etc. So in a WebRTC context,
>>> there seem to me we would not need the simulcast solution you have
>>> included. The different resolutions can be sent as different
>>> MediaStreamTrack's - meaning they would be separate m-lines.
>> 
>> That's what we meant to convey with this (section 2, bullet 1): "This does not preclude 'application level' simulcasting; i.e., the creation of multiple media stream tracks from a single source."
>> 
>> It's true that we don't broach the issue of how to indicate the need for simulcast via a WebRTC javascript API. I think this is something that would be future work, probably in the W3C. I'm going to leave any further explanation to Justin, as most of the simulcast ideas in the document came from him.
> 
> Consider the parallel with layered coding - in that case, you have multiple dependent encodings of the track, but it's doubtful you want the recipients to end up with multiple MediaStreamTracks and display them all in their UI.
> 
> This mechanism is basically a way to say that I have a single MediaStreamTrack coming in, and while there might be multiple independent or dependent encodings of it on the wire, the recipient should only create and display a single MediaStreamTrack on its side.
>> 
>> 
>>> * Direction attribute: The current WebRTC API is "sender" oriented: the
>>> application can select MediaStream(Track)'s to send. Would it for WebRTC
>>> make sense to have all m-lines being unidirectional (send/recvonly)?
>> 
>> I understand how this makes things cleaner in general. The issue I have is that it interacts poorly with legacy uses.
>> 
>> 
>>>   (If
>>> they should be sendrecv we also need to specify when a return track
>>> should reuse an existing m-line, and when a new m-line should be created.)
>> 
>> I agree that this could stand to be spelled out more clearly. I do not think that doing so will prove particularly controversial.
>> 
>> 
>> /a
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic