Re: [MMUSIC] Unified Plan for SDP Handling

[Stefan Håkansson LK <[e-mail]>]

On 7/19/13 5:43 AM, Justin Uberti wrote:
>
>
>
> On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach <[e-mail]
> <mailto:[e-mail]>> 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.

I think it is not a good parallel. With layered encoding you need the 
base layer to have any use of any enhancement layer. With simulcast of 
the other hand every stream is a complete representation and can be used 
on its own.

>
> 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.

That's fine. What I was saying was that in a WebRTC context we don't 
really need this functionality for simulcast, and using it would require 
a new set of API functionality. But I understand Adam's response as that 
simulcast can be solved using 'application level' simulcasting, so there 
is really no issue.

>
>
>
>         * 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>