- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Tue, 12 Apr 2016 19:06:05 +0200
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>
- Cc: Justin Uberti <juberti@google.com>, "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <570D2AFD.1020401@gmail.com>
Don't blame me, I was just copy&pasting an RFC.. :)
If SVC only makes sense in SRST, shouldn't simulcast also only make
sense in SRST?
Best regards
Sergio
On 12/04/2016 18:59, Bernard Aboba wrote:
> SVC with multiple senders makes no sense to me, either with MRST or
> SRST. You would have a single bitstream that would need to be
> packetized by two or more senders, creating a lot of complexity in
> implementation. That said, given that VP8/VP9/AV1 are all SRST, the
> MRST case is probably not worth much of our attention (assuming that
> the HEVC vampire stays in its crypt).
>
> On Apr 12, 2016, at 12:38, Peter Thatcher <pthatcher@google.com
> <mailto:pthatcher@google.com>> wrote:
>
>> If an application wants to use multiple RtpSenders or one encoding
>> per RtpSender, it already can, and there's nothing difficult about
>> that. I don't see any "easiness of use" advantage there. On the
>> flip, side requiring all applications to use multiple RtpSenders has
>> a definite "easiness of use" disadvantage for those applications that
>> want to have one RtpSender with multiple encodings.
>>
>> However, I do question the worth of supporting SVC with multiple
>> RtpSenders. For simulcast, like I said, the app can always do so.
>> But for SVC? I don't see any good reason to support SVC across
>> multiple transports/RtpSenders, regardless of what the RFC says is
>> possible.
>>
>> On Tue, Apr 12, 2016 at 1:19 AM, Sergio Garcia Murillo
>> <sergio.garcia.murillo@gmail.com
>> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>>
>> Hi Justin, Peter,
>>
>> According to RFC 7656, there are three "usages" of SVC
>>
>> * SRST: Single RTP stream on a Single media Transport
>> * MRST: Multiple RTP streams on a Single media Transport
>> * MRMT: Multiple RTP streams on Multiple media Transports
>>
>> Currently, only SRST and MRST are supported as all the encoding
>> in the SVC must be in the same RTCRtpSender. The current spec
>> also gives the solution on how to support MRMT with same API,
>> just make the encodingIds global, so the SVC encodings could be
>> owned by different RTCRtpSenders.
>>
>> Same terminology could be used on simulcast, and also only SRST
>> and MRST would be supported by current ORTC spec, and MRMT would
>> be impossible with current API. Regarding performance of doing
>> simulcast with several encoders vs single encoder instance, I
>> fail to see how it could re-use encoding process for several
>> unrelated streams, but if you say so, I have to believe you.
>>
>> This could be overcome with a similar solution as the one
>> proposed for SVC MRMT, use the same encodingId in all encodings
>> belonging to the same simulcast across different RTPSenders.
>>
>> We would handle simulcast and SVC exactly in the same way:
>>
>> * SRST: Single RTPSender, one payload per encoding, one transport
>> * MRST: Multiple RTPSenders, one transport
>> * MRMT: Multiple RTPSenders, multiple transports
>>
>> I completely disagree with the "easiness of usage" of current
>> API, I feel that we are just using a jsonized-m-line containing
>> all the information and passing it to a RTCPeerconnection-like
>> object that is almost an static function. In this regards, IMHO,
>> this is against the reasons why ORTC was created on the first
>> place, and I don't see the benefits from moving from WebRTC to ORTC.
>>
>> Anyway, as stated above my main concern is the easiness of use,
>> and this was a non-distruptive proposal to try to improve it,
>> while doing the minimal changes required.
>>
>> I will follow Robin advice
>> (https://github.com/openpeer/ortc/issues/440#issuecomment-207794630)
>> and work on a set of slides to see if at least we agree on which
>> are the issues with current API design (maybe everyone else feels
>> they are fine as they are, and we are wasting our time here).
>>
>> Best regards
>> Sergio
>>
>>
>> On 12/04/2016 6:31, Justin Uberti wrote:
>>> Agree with Peter's argument here.
>>>
>>> It makes no sense to have multiple RtpSenders when doing SVC,
>>> and simulcast is just a special case of SVC.
>>>
>>> On Fri, Apr 8, 2016 at 7:31 AM, Peter Thatcher
>>> <pthatcher@google.com <mailto:pthatcher@google.com>> wrote:
>>>
>>> Here are the minutes from the main meeting:
>>>
>>> https://www.w3.org/2015/09/10-webrtc-minutes#item08
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2015%2f09%2f10-webrtc-minutes%23item08&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c8032f83dba90425e8a6508d362f0e881%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bgfC%2fqexEcweXH9iKLkbWHkio6h4UGWOkky06I3r738%3d>
>>>
>>> But that's probably hard to read.
>>>
>>> You could also check this more recent mailing list thread
>>> where I suggested using multiple RtpSenders in certain
>>> (bizarre) simulcast scenarios, and the disinterest in doing so.
>>>
>>> https://lists.w3.org/Archives/Public/public-webrtc/2016Feb/0020.html
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.w3.org%2fArchives%2fPublic%2fpublic-webrtc%2f2016Feb%2f0020.html&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c8032f83dba90425e8a6508d362f0e881%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7aIH7SBlhginkPT7oAFpKR1JmhPAxLAPDfGiJ6a3VNY%3d>
>>>
>>>
>>> My memory is a bit fuzzy, but I remember the main reasons being:
>>> - It's much easier to reason about performance degradation
>>> if you know there are 3 encodings in one RtpSender than 3
>>> RtpSenders.
>>> - It's much easier for implementations to get the
>>> performance right with 3 encodings in one RtpSender than 3
>>> RtpSenders.
>>> - When doing simulcast, it's easier to use the API with one
>>> RtpSender than many
>>> - Keeping simulcast and SVC more similar is nicer than
>>> making them look completely different. It's not reasonable
>>> to have 3 RtpSenders when doing SVC.
>>>
>>> On Fri, Apr 8, 2016 at 1:25 AM, Sergio Garcia Murillo
>>> <sergio.garcia.murillo@gmail.com
>>> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>>>
>>> On 07/04/2016 23:05, Peter Thatcher wrote:
>>>>
>>>>
>>>> On Thu, Apr 7, 2016 at 8:17 AM, Sergio Garcia Murillo
>>>> <sergio.garcia.murillo@gmail.com
>>>> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>>
>>>> Also take note that 2, with current propossal can
>>>> be implemented in two ways, one RTPSender per ssrc
>>>> (same as my proposal) or all ssrcs in same
>>>> RTPSender. In order to implement 3 with current
>>>> proposal it is only possible to do it with several
>>>> RTPSenders.
>>>>
>>>>
>>>> WebRTC only supports #2, and I think ORTC should only
>>>> support #2. You are correct that with the current
>>>> WebRTC and ORTC APIs, one could accomplish the same
>>>> thing with one RtpSender or many. But requiring many
>>>> is an option that was rejected by the WebRTC WG.
>>>>
>>>
>>> Do you know what were the objections for rejecting
>>> multiple RTPSenders for simulcast (with
>>> ssrc-multiplexing over same transport)?
>>> It is something that needs to be supported anyway by
>>> the browser and given that each layer is an independent
>>> encoder there should be no performance penalty.
>>>
>>> I mean, currently we can do this (in pseudocode)
>>>
>>> RTPSender.send({
>>> encodings: [
>>> {ssrc:1,pt:100,codec:vp8,},
>>> {ssrc:2,pt:100,codec:vp8,resolutionScale: 2.0},
>>> ]
>>> })
>>>
>>> or
>>>
>>> RTPSender1.send({
>>> encodings: [
>>> {ssrc:1,pt:100,codec:vp8,},
>>> ]
>>> })
>>>
>>> RTPSender2.send({
>>> encodings: [
>>> {ssrc:2,pt:100,codec:vp8,resolutionScale: 2.0},
>>> ]
>>> })
>>>
>>> Both will produce the same result
>>>
>>> Best regards
>>> Sergio
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
Received on Tuesday, 12 April 2016 17:06:33 UTC