Re: [MMUSIC] Unified Plan for SDP Handling

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<https://www.ietf.org/mailman/listinfo/mmusic>
>