All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=643694

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgkdKBswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgkdC5owkM


Bot(s) for this bug's original alert(s):

webrtc-mac-large-tests

Hi Per, It looks like there was a regression on mac in encode perf stats, and it looks like it was caused by your revert CL: https://codereview.webrtc.org/2250123002
Could you have a look to see if this is expected?

So the metric measure how long time it take to encode a frame on average compared to the input frame rate. 

This cl replaces a platform_thread that indeed ran with high priority and was replaced with a tq that does not set thread priorities. 

This regression only seems to be noticeable on Mac on IOS where we use threads from grand central.
I think this is acceptable. 

It would be interesting to see if the difference gets larger with increased load as well.

There does not seem to be any tests with higher load on mac but there are with lower load.
https://chromeperf.appspot.com/report?sid=ba15b1f4f71ba150a9ed470823ab48d9d80c2146748bfaed587d6c8ee08b238b&rev=14014


It is also possible to set priorites on gcd queues.... But I wonder if we really want to run the encoder with higher priority than other things.

https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html#//apple_ref/doc/uid/TP40008091-CH102-SW7

Working as intended. We now run the encoder on normal thread priority.