- From: Cullen Jennings via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Mar 2018 16:27:37 +0000
- To: public-webrtc-logs@w3.org
Sure, it's a trade off. Seems like a good thing for the WG to have consensus on not just get changed by the editors. Perhaps that happened and I just don't recall. There is also a big differences between requiring browsers to do this and forbidding them to do this. I would be against saying this was forbidden as it turns out to be really easy to do and often useful. > On Mar 22, 2018, at 4:20 PM, jan-ivar <notifications@github.com> wrote: > > @jan-ivar commented on this pull request. > > In webrtc.html <https://github.com/w3c/webrtc-pc/pull/1814#discussion_r176483406>: > > > @@ -5159,7 +5159,7 @@ <h2>Methods</h2> > non-null value, as defined in <span data-jsep= > "processing-a-local-desc processing-a-remote-desc">[[!JSEP]]</span>.</p> > <p>The <code>sendEncodings</code> argument can be used to > - specify the number of offered simulcast encodings, and > + specify the number of offered simulcast encodings for video, and > @fluffy <https://github.com/fluffy> Because of costs of implementing, testing and supporting any feature? Not to mention that features without strong use-cases driving them tend to end up broken anyway. I think the question must be flipped around: Why wouldn't simulcast be limited to video? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <https://github.com/w3c/webrtc-pc/pull/1814#discussion_r176483406>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANQcHbNF-Zkw7Hc2SYkeQbQYoIqPSKrks5tg89ogaJpZM4S2acG>. > -- GitHub Notification of comment by fluffy Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1814#issuecomment-375369544 using your GitHub account
Received on Thursday, 22 March 2018 16:27:40 UTC