- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Wed, 13 Apr 2016 11:36:56 +0200
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: Peter Thatcher <pthatcher@google.com>, Justin Uberti <juberti@google.com>, "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <570E1338.5000201@gmail.com>
Hi Bernard,
I have always been a mcu-mixer guy, so thanks for the clarification ;)
AFAIK RFC 6051 is not meant to be supported, and if it was, we don't
have a way of knowing in the API if it is supported by the browser.
Also, DON is an h264 mechanism, shall we assume that all SVC codecs are
going to support a similar mechanism (i.e. VP9)? I mean, there is no
point in supporting MRST in the API, if there is no way to know if it
will work or not for a given codec.
Best regards
Sergio
On 13/04/2016 6:59, Bernard Aboba wrote:
> SVC can be done in MRST. There are a few advantages (such as not
> requiring the SFU to rewrite sequence numbers, simplified protection
> of selected layers with FEC) but alignment of the layers is trickier,
> requiring either a Decoding Order Number (DON) in the RTP Payload or
> RFC 6051. Overall, the simplicity of SRST probably makes it the
> preferred choice.
>
> Simulcast senders must use distinct SSRCs since simulcast by
> definition involves separate streams, each with their own sequence
> number space. So SRST simulcast does not make sense.
>
> On Apr 12, 2016, at 13:06, Sergio Garcia Murillo
> <sergio.garcia.murillo@gmail.com
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
>> 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> 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
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> 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> 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 Wednesday, 13 April 2016 09:37:24 UTC