W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: A Big Proposal: A way to control quality/resolution/framreate/simulcast/layering with RtpSender

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Feb 2014 13:38:43 -0800
Message-ID: <CAJrXDUFOZRDAs6oQdVJ3L45ywMLZa8Yjq_Z4FOKj7vE2qmCo7w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-orca@w3.org" <public-orca@w3.org>
On Wed, Feb 19, 2014 at 9:49 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 18 February 2014 17:17, Peter Thatcher <pthatcher@google.com> wrote:
> > As for priority, your "add bits proportionally" is exactly what I was
> > thinking, but, as you pointed out, it's "roughly proportionally", since
> you
> > can quite split up bit allocation that finely.  Whether a browser does
> it in
> > a simple fashion or with more fancy "curves" may simply be browser,
> codec,
> > and BWE dependent.  The JS gives the policy, and the browser does its
> best.
> I think that unless there is some amount of determinism here, we will
> leave applications doing funny heuristic things, browser sniffing and
> the like.  I understand that it might be hard to specify something,
> but I'd like something a little more deterministic than what you have
> specified.

I agree we should be as predictable for the application as possible.  But I
don't really know how detailed we can or should specify the implementation.
 That's probably a good item for discussion.

And, I should mention that I made this proposal as a starting ground for
discussion.  It's certainly not a complete specification as written.

So, let me add it to our virtual TODO list:
- Discuss how detailed we should specify the implementation such that
applications get predictable/consistent behavior.
Received on Wednesday, 19 February 2014 21:39:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC