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

Re: Al PR for adding various fields to RtpParameters and RtpEncodingParameters

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 25 Aug 2015 18:43:03 -0700
Message-ID: <CAJrXDUFk_hW0t45urQud6_rAObGZs1mwvK1h3+xsqVdrTX4djQ@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Aug 25, 2015 at 6:34 PM, Randell Jesup <randell-ietf@jesup.org>
wrote:

> On 8/24/2015 6:01 PM, Peter Thatcher wrote:
>
> maxFramerate can be accomplished with a gUM constraint, so I don't think
> it's needed on the RtpSender.
>
>
> Not all sources come from gUM (video.captureStream() for example, or
> canvas.captureStream(), or even another PeerConnection, etc).  Also, a
> stream may have more than one consumer with different needs.  (On a side
> note, I was surprised looking at some stats that show a non-trivial number
> of peerconnections are carrying 60fps video.)
>
>
I
‚Äčt still seems like it's a transformation on the track we really want to
have.  Tell the track to control its framerate.  It's probably more
efficient that way anyway for things like canvas.


>
> Also, I should mention that I didn't include "minQuality" from ORTC, since
> I didn't think we'd ever be able to resolve what "quality" means in the 1.0
> timeframe, even if it's relative quality.
>
>
> :-)  I had the same thought...
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
> Please please please don't email randell-ietf@jesup.org!  Way too much spam
>
>
Received on Wednesday, 26 August 2015 01:44:11 UTC

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