Subject: Re: [rtcweb] LS groups (Re: Cullen Notes from RTCWeb interim on June 18, 2015)

From: Harald Alvestrand <[email-masked]>
Date: Mon, 06 Jul 2015 10:35:14 +0200

Den 29. juni 2015 19:24, skrev Cullen Jennings:
> 
> I think that LS makes more sense. Doing both LS and MSID was a comprise the WG came to long ago. We need for a say to synchronized audio and video and the IETF has already defined a widely deployed way of doing that so I don't see a gain in ignoring it and inventing something else. 

As I've said before, I've got no qualms about adding LS for
interoperability, for the cases where it makes sense.

I do have strong qualms about changing the definition of LS so that
stuff only interoperates some of the time (the "make it declarative"
solution).

I have also heard some people mumble about discarding the MSID mechanism
and only using LS; this is a proposal that I do not think will satisfy
the group's requirements.

And with regard to whether the WG came to the conclusion that we should
do both LS and MSID "long ago": I was present long ago, and I don't
recall the group coming to such a conclusion.

I've found a proposal for such a solution
(draft-jennings-rtcweb-plan-01, February 25 2013, section 7 bullet 7),
but that proposal seems to ignore the one-way nature of MediaStreams
(which is what led to the current isuse), and I've found no evidence of
a WG consensus on that part of that specification.

> 
> 
>> On Jun 22, 2015, at 5:19 AM, Harald Alvestrand <[email-masked]> wrote:
>>
>> On 06/18/2015 08:00 PM, Cullen Jennings (fluffy) wrote:
>>> * make sure to add note well slide to slide deck
>>>
>>> LS Behavior
>>> - Magnus points out that if JSEP overrides 5888, we will have issue with legacy things
>>> - Martin points needs more thought to make declarative groups
>>> - Martin raised point that we might be able to add some extra signaling that indicates that we can support this declarative LS usage
>>>
>>> Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2
>>>
>> Just FWIW:
>>
>> Personally, I don't see the added value in adding LS groups.
>>
>> We already have a well defined, declarative (=one-way) means of declaring synchronization in the form of the MSID values, which bind MediaStreamTracks into MediaStreams, which you're supposed to try syncing if you can (it's not a hard requirement in the spec that you should succeed).
>>
>> If we want to be extra helpful for non-WebRTC implementations, and end up in the case where we have one audio and one video track from one stream in one direction using the same media descriptions as an audio and video track in the other direction (which will be the normal case when your application is trying to emulate a single-channel VC unit), I have no particular problems with adding LS group markings to those media descriptions - but I don't want to spend resources changing the semantics of LS groups (and thereby imperiling the exact interworking we're trying to make easier) when we already have something that fulfils all the requirements for a pure WebRTC scenario.
>>
>> My $0.02.
>>
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>