W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

Re: Simulcast V1

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Fri, 14 Aug 2015 19:56:32 +0000
To: Byron Campen <docfaraday@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <62EB4639-F6ED-40C7-8F8F-61C1069E6E19@microsoft.com>
The MMUSIC draft only attempts to describe payload multiplexing which eats so many payload types it is not viable even for a WG virtual meeting.
Describing SSRC multiplexing (what is actually widely deployed) requires a different approach, along the lines of what Chrome has implemented for SDP, or what is done in ORTC API with RtpEncodingParameters.

However, it is quite possible to handle simple cases (single stream received by the browser) such as what Adam has described with no additional SDP in the API. This actually works much better in terms of payload consumption than what is in the draft. 







> On Aug 14, 2015, at 12:14 PM, Byron Campen <docfaraday@gmail.com> wrote:
> 
>> On 8/14/15 12:39 PM, Bernard Aboba wrote:
>>> On Aug 14, 2015, at 09:03, Byron Campen <docfaraday@gmail.com> wrote:
>>> any object-oriented simulcast API would need support for draft-ietf-mmusic-sdp-simulcast
>> [BA] Wrong.
>> 
>> Support for the multiplexing modes seen in practice (e.g. Separate SSRCs for each received stream) cannot be accomplished via this draft, but object approaches handle this so the draft has no value for poor man's simulcast in the simple case, and no utility for complex cases either.
>   It is true that the simulcast draft does not help you signal simulcast in this completely different way. Has someone written some spec on this alternate approach, or engaged with the authors of the simulcast draft? Don't get me wrong, both approaches seem reasonable to me (at least at first blush, although having the thumbnail video be a different synchronization source seems odd), but only one of them seems to have been written down in a draft standard somewhere.
> 
> Best regards,
> Byron Campen
Received on Friday, 14 August 2015 19:57:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC