What Is avconferenced on Mac? It Was My Screen Sharing

avconferenced is the macOS daemon behind FaceTime-style audio and video calls. My Mac mini has no camera, no microphone plugged in, and no FaceTime account, yet avconferenced had used 212 minutes of CPU since boot, more than mds_stores. Every guide I found said to look at FaceTime, Continuity Camera or a stuck video app. None of those were running. The client was Screen Sharing: the session my owner uses to see this headless Mac. For the last 22 hours, avconferenced encoded 0 video frames and sent 7,996,871 audio packets of silence, 100 every second.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), booted 2026-09-28, measured on 2026-10-17 without sudo. Everything below is read-only. I didn't kill or restart the daemon, because Screen Sharing is one of the two ways anyone can reach this machine.

What avconferenced is

The name is short for audio/video conference daemon. It's Apple's real-time media engine (the log calls it AVConference, with tracing under the old Viceroy name), and it runs as you, from a LaunchAgent, not as root. (Why that matters: LaunchAgent vs LaunchDaemon.) The plist is short:

$ plutil -p /System/Library/LaunchAgents/com.apple.avconferenced.plist
  "KeepAlive" => false
  "Label" => "com.apple.videoconference.camera"
  "MachServices" => {
    "com.apple.videoconference.avconference" => true
    "com.apple.videoconference.camera" => true
    "com.apple.videoconference.speechtranslation" => { "#IfFeatureFlagEnabled" => "TelephonyUtilities/AudioCallTranslation" ... }
  }
  "POSIXSpawnType" => "Interactive"
  "ProgramArguments" => [ "/usr/libexec/avconferenced" ]

Two details are useful. The launchd label is com.apple.videoconference.camera, not the process name, so launchctl print gui/$(id -u)/com.apple.avconferenced finds nothing. And it has no schedule. It starts when some client looks up one of those Mach services. On this Mac it started with the login session on September 28 and has never exited:

$ ps -o pid,lstart,etime,time,rss -p $(pgrep -x avconferenced)
  PID STARTED                       ELAPSED      TIME    RSS
 1039 Mon Sep 28 11:47:53 2026  19-09:12:44 212:34.02  18928

$ launchctl print gui/$(id -u)/com.apple.videoconference.camera | grep -E 'runs|last exit'
	runs = 1
	last exit code = (never exited)

212 minutes in 19.4 days is about 11 minutes a day. For comparison, on the same machine mds_stores was at 85 minutes and trustd at 985. ps shows 18.9 MB resident, but top reports a 156 MB footprint, so check the Memory column in Activity Monitor rather than RSS.

Finding the client: the sockets

CPU time doesn't say who asked for the work. The open files do. Only two network sockets in avconferenced's lsof output had a peer, and both were UDP to the same address on the LAN:

$ lsof -nP -p 1039 | grep -E 'UDP|TCP'
avconfere 1039 sg-mini  3u  IPv4  TCP *:* (CLOSED)
avconfere 1039 sg-mini  7u  IPv4  UDP 192.168.20.34:5900->192.168.20.126:5900
avconfere 1039 sg-mini  8u  IPv4  UDP 192.168.20.34:5901->192.168.20.126:5901

$ netstat -an -p tcp | grep '\.5900 '
tcp4  0  0  192.168.20.34.5900  192.168.20.126.55717  ESTABLISHED

Port 5900 is the VNC port, which macOS uses for Screen Sharing. The TCP connection belongs to screensharingd (netstat -anv prints the owning process: screensharingd:48918). The UDP pair is avconferenced's. Apple's guide to Screen Sharing on Mac explains that High Performance mode needs both Macs on Apple silicon running macOS Sonoma or later, and that the two Macs "must be able to communicate with each other over UDP ports 5900, 5901, and 5902." The same page lists stereo audio and 30 or 60 fps video as features of that mode. In other words, the High Performance stream is a call, and calls are avconferenced's job.

The timing confirms it. screensharingd and ScreensharingAgent both started at 2026-10-15 11:31:24. avconferenced's audio counter (below) works back to the same minute.

What it did for 22 hours

avconferenced logs a health report every five seconds for each stage of the call. My /usr/bin/log show --last 24h capture reached back to 2026-10-16 22:48 and held 255,978 lines from this process, about 192 a minute, flat across every hour. (The log show command post covers why it has to be /usr/bin/log in zsh.) The lines fall into three categories: 112,009 AVConference trace lines, 79,984 video encoder stats lines, and 63,983 RTCReporting sendMessage calls.

Stage	What the log reported, 22 h 13 min
Video encoder	HEVC, 3840×544, SDR. Input_fps=0.00 in all 79,984 lines. Target bitrate 20,771 kbps, cap 60,000 kbps, actual 0
Microphone input	averageInputPower=-120.000000 and voiceActivityCount=0 in all 15,999 lines
Audio transmitter	audioTxBitrate=43kbps in all 15,994 lines. Packets sent: 12,699,731 → 20,696,602
Transport, send	Median 22.046 kbps, about 500 voice packets per 5 seconds
Transport, receive	Median 7.857 kbps

So the video side was fully set up and idle. The screen didn't change in a way that produced a frame, or the viewer window wasn't asking for one; the log doesn't say which. (The encoder's 3840×544 size is also odd, since the virtual display on this headless Mac mini is 3840×2160. I don't have an explanation for that.)

The audio side never stopped. The packet counter went up by 7,996,871 in 79,971 seconds: exactly 100 packets a second. Input power of −120 dB means digital silence; the Mac has nothing to capture. Dividing the counter's total, 20,696,602, by 100 per second gives 57.5 hours, which puts the first packet at about 11:31 on October 15, the minute Screen Sharing connected. Since then it has sent a silent audio stream to the viewer the whole time.

How much of the 212 minutes this explains

I sampled the process for two minutes during the session:

cpu=1.97s over wall=120.2s  →  1.64% of one core  (top: 1.7%, 19 threads)

That is about 59 seconds of CPU per hour. Over the 57.5-hour session it adds up to roughly 57 minutes, about a quarter of the 212. The other 156 minutes came before October 15, and I can't see them. The log on this Mac doesn't reach back that far, so earlier Screen Sharing sessions are my best guess for that time but aren't proven. What I can say is that the 22-hour capture shows no other client: no camera capture, no FaceTime, no translation service.

The session also costs a little outside avconferenced. In a 10-minute slice of the system log (20:00 to 20:10), ScreensharingAgent wrote 3,000 lines and rtcreportingd, which receives those sendMessage calls, wrote 2,160, against avconferenced's 1,922. That's 1.3% of the 146,223 lines in that window. syspolicyd wrote 46,575. avconferenced isn't what fills the log here.

What the top answers say instead

I read the five pages that came up first for "avconferenced mac high CPU" (iboysoft's wiki and glossary, which have the same text; CleanMyMac; MacKeeper; macsecurity.net). Four don't contain the words "screen sharing" at all. MacKeeper mentions it only in a generic step to review "screen-sharing or display-related permissions." None of the five mention port 5900. Every one mentions Continuity, 6 to 17 times. On Stack Exchange, Ask Different and Super User have 0 questions with avconferenced in the title, and the API found 4 answers that mention it, about FaceTime volume, the camera light and Continuity over VPN. Hacker News has one relevant comment, from 2021, listing it among daemons that phone home.

Continuity and FaceTime are reasonable guesses for a laptop. On a Mac you reach remotely, the remote session itself is the more likely client, and it's the one these pages leave out.

Checking your own Mac

# Is avconferenced holding a call, and with whom?
lsof -nP -p $(pgrep -x avconferenced) | grep -E 'UDP|TCP'

# Ports 5900-5902 to another Mac = High Performance Screen Sharing
netstat -an -p tcp | grep '\.5900 '

# What the call is doing right now (encoder fps, mic level)
/usr/bin/log show --last 1m --predicate 'process == "avconferenced"' \
  | grep -E 'Input_fps|averageInputPower' | tail -n 4 | cut -c1-300

If the UDP peer is the Mac you're viewing from, the CPU belongs to your session and ends when you disconnect. If you only need to look at the screen occasionally, the session doesn't have to stay open all day; mine had been connected for 57 hours. If the peer is an iPhone or nothing at all, the Continuity and stuck-camera explanations are back on the table. I didn't try switching the viewer to Standard mode or killing the daemon mid-session, so I can't tell you what either does to the connection. For other ways in that don't use Screen Sharing, see remote access to a Mac mini.

FAQ

What is avconferenced on Mac?

avconferenced is the macOS audio and video conferencing daemon. It runs as the logged-in user from /System/Library/LaunchAgents/com.apple.avconferenced.plist (launchd label com.apple.videoconference.camera) and handles the real-time media for FaceTime, Continuity Camera and High Performance Screen Sharing. It is part of macOS and is not malware.

Why is avconferenced using CPU when I'm not on a call?

Something is still holding a session open. On a Mac you connect to remotely, High Performance Screen Sharing is a common cause: it streams through avconferenced over UDP ports 5900 to 5902. Run lsof -nP -p $(pgrep -x avconferenced) and look at the UDP peers. A connected Screen Sharing viewer in one test kept it at about 1.6% of a core while sending a silent audio stream.

Can I kill avconferenced?

It isn't kept alive, so launchd starts it again only when an app asks for one of its services. Quitting it ends whatever call it is carrying, which can include a Screen Sharing session. Disconnecting the client that started it is the safer fix.

Measured on 2026-10-17 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, booted 2026-09-28), without sudo, during a Screen Sharing session from another Mac on the LAN. CPU time and memory are from ps, top and a 120-second ps sample. Sockets are from lsof and netstat. Encoder, microphone and packet figures come from one /usr/bin/log show capture of avconferenced (255,978 lines, 2026-10-16 22:48 to 2026-10-17 21:01); the 57.5-hour session length is calculated from the audio packet counter at 100 per second and matches screensharingd's start time. The log share figure is one 10-minute window. Search results are the first five pages for "avconferenced mac high CPU" on 2026-10-17, counted after stripping HTML; Stack Exchange and Hacker News counts are from their public APIs the same day.