Question about CPU usage of WebRTC threads
Carlos Rafael Giani
embedded platform. Note that the video en/decoding is hardware
accelerated and definitely _not_ the bottleneck.
Running htop on that platform, I saw that a child press contains several
threads that use up a serious amount of CPU%. These threads are:
AudioInputDevice, Chrome_ChildIOThread, WebRTC_Network,
WebRTC_Signaling, Media. However, something in that child process' main
thread is also consuming serious amounts of CPU%.
I realize this is little to go on, but is it at least known why the
WebRTC_Network and WebRTC_Signaling threads need so much CPU%? This is
the code from Chrome 87.0.4280.144.
Dale Curtis
--
You received this message because you are subscribed to the Google Groups "media-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to media-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/64fa1529-1e9e-4a4a-75a2-8ce60f5d2744%40gmail.com.
Carlos Rafael Giani
I was able to lower the AudioInputDevice thread's CPU usage by disabling a series of audio processing stages through the WebRTC media constraints. I also used the devtools for remote profiling. However, while those indicate a large amount of activity in WebRTC_Network, the tasks in that thread are opaque - no details are given.
I did add the extra flags to args.gn as indicated in
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/profiling.md#General-checkout-setup
, except the tcmalloc (it caused segfaults) and
blink_symbol_level=2 (I set it to 1, otherwise ld would complain
with "ELF section name out of range"). Unfortunately, this did not
help - the WebRTC_Network tasks are still opaque. Is the remote
devtool even the proper tool for this? My next attempt would be
with perf, but I do not know if perf support is still up to date.
