Re: New functionality in PR - priority

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.