Re: Simulcast V1

     As I understand it, the simulcast draft is going double the number 
of payload types used on the send m-section for the full/thumbnail 
use-case, and have no effect on the recvonly m-sections. There isn't 
going to be a combinatorial explosion or anything. This could become a 
problem if an MCU/SFU/what-have-you needs the payload types to be unique 
across all PeerConnections, but if it does you're already in (half as 
much) trouble without simulcast. Or am I missing something?

Best regards,
Byron Campen

On 8/14/15 2:56 PM, Bernard Aboba wrote:
> 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 20:43:07 UTC