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

Re: New functionality in PR - priority

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sat, 23 May 2015 10:29:05 +0200
Message-ID: <55603A51.9010003@alvestrand.no>
To: public-webrtc@w3.org
On 05/23/2015 02:18 AM, Jan-Ivar Bruaroey wrote:
> On 5/22/15 10:02 AM, Peter Thatcher wrote:
>> I think that per-RtpSender is the wrong level for priority.  I think
>> RtpEncodingParameters is the right level.  It's true we don't have a
>> PR for RtpEncodingParameters, but I can fix that very quickly.
>>
>> Along those lines, has there been consensus on the list for having
>> RtpSender.priority as an attribute?  I would be opposed to that for
>> the same reason I was opposed to making any of the similar settings
>> being attributes, as was proposed recently.  Even if it's at the
>> RtpSender level, it should be part of RtpSender.setParameters, so
>> that many like changes can be made atomically (without relying on
>> strange Javascript idiosyncrasies).
>
> What strange Javascript idiosyncrasies? That it's not multi-threaded
> or in need of locking?

This value is going to be read by media senders, which will almost
certainly be running on other threads than the Javascript main thread.

That said, I don't see anything about this value that makes it
particularly critical (it's input to the decision about which packet to
send next), and it's only updated in one direction (from Javascript to
media engine), so it doesn't seem to offer any particular challenges wrt
synchronization.

On the third hand (Niven/Pournelle anyone?), I see no reason to treat it
specially, so if we want to expose parameters for RTP encoding as a
structure that we get/set, I see no reason to take this one out of the
structure.
Received on Saturday, 23 May 2015 08:29:37 UTC

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