WebRTC Codec Settings That Improve Startup Time for AI Avatar Calls
Learn how VP8/H.264, low startup bitrate, modest resolution, and keyframe timing reduce WebRTC avatar call startup latency.
Introduction
For AI avatar calls, “startup time” is usually the time from user intent to first usable media: audio starts, video appears, and lip sync feels aligned. That delay is rarely dominated by the model alone. In practice, WebRTC negotiation, codec choice, packetization, keyframe timing, and browser decode behavior can easily add hundreds of milliseconds before the first frame is rendered.
If you are shipping a realtime avatar experience, you can usually improve perceived startup time without changing your model or your backend architecture. The main lever is to make the media path easier to establish and cheaper to decode at the client. By the end of this post, you should know which WebRTC codec settings matter, why they matter, and how to pick sane defaults for a production avatar call.
What “startup time” actually includes
People often talk about startup time as if it were one number. For avatar calls, it is better to break it into four stages:
Session setup: signaling, auth, room join, ICE candidate gathering, DTLS/SRTP setup.
First media packet: the first encoded audio/video frames leave the server or media worker.
First decode: the browser receives a decodable keyframe and/or audio frame.
First stable render: the video element is actually painting and the face is lip-synced enough to feel “live.”
Codec settings affect the second, third, and fourth stages the most. A codec that is technically efficient but slow to initialize, slow to decode on your target devices, or sensitive to packet loss can make the avatar feel sluggish even when your agent is responding quickly.
Prefer the simplest codec path your clients can decode well
For browser-delivered avatar video, the default choice should usually be the codec with the broadest hardware support and the lowest startup overhead on your target devices. In many deployments that is VP8 or H.264, not because they are always the best codecs in the abstract, but because they tend to start fast and decode predictably in real browsers.
Startup time gets worse when you optimize for compression at the expense of initialization. A codec profile with more complex prediction, larger reorder buffers, or a higher dependency on receiving a clean keyframe can delay the first visible frame. That is particularly painful for avatars, where the first impression is dominated by motion onset and lip sync continuity, not absolute bitrate efficiency.
Codec settings that usually help
There is no single magic configuration, but these choices are generally favorable for avatar startup:
Use a widely supported video codec such as VP8 or H.264 unless you have measured a clear reason not to.
Keep resolution modest at start. A 720p or even 540p initial stream often looks better than a 1080p stream that arrives late.
Prefer a low initial bitrate and let adaptation ramp up after the connection is stable.
Request a keyframe immediately on start so the first rendered frame is not blocked behind delta-frame dependencies.
Minimize encoder complexity during the first seconds of a call.
The important point is that startup is a “time to first acceptable frame” problem, not a “maximize video quality from second one” problem. You can raise quality after the avatar is already visible and speaking.
Keyframes matter more than people expect
For video, the browser cannot render a clean stream until it has a decodable reference frame. If the first packets are delta frames and the receiver has to wait for a keyframe interval, your avatar may be connected but still invisible.
That is why forcing an early keyframe is one of the most practical startup optimizations. In WebRTC stacks, this is often done by sending an RTCP Picture Loss Indication (PLI) or by configuring the sender to emit a keyframe when the track is attached or when the session transitions to active speech. The exact mechanism depends on your media pipeline, but the goal is simple: make the first frame independently decodable.
This matters even more for avatars than for generic talking-head video. If the face appears late, users interpret the entire agent as slow, even if the audio already started. A fast audio start with a delayed face can feel worse than slightly delayed audio and video together.
Bitrate and resolution: start small, then scale
Developers often over-allocate video quality at startup because they are optimizing for steady-state appearance. That can backfire. Large frames require more encoding time, more network time, and more decode work, all before the user has seen anything.
A good pattern is:
Begin with a smaller frame size and conservative bitrate.
Confirm the connection is stable and the browser has rendered the first frame.
Increase resolution or bitrate only after the call is clearly established.
This is especially useful on mobile networks and on laptops with aggressive thermal throttling. The smaller initial payload improves not just network transit time, but also the chance that the receiver can decode and paint the frame without dropping it.
For avatar systems, a modest starting resolution is often acceptable because the subject is a face, not a full scene. Facial details matter, but the perceived quality gain from very high resolution is usually lower than the gain from fast onset and stable motion.
Browser and device support should drive your codec choice
Do not choose a codec based only on theoretical efficiency. Choose it based on the browsers and devices your product actually supports.
Hardware acceleration can make a larger difference to startup than codec efficiency on paper. A codec that hits the hardware decode path on your common devices can start and render faster than a more compact codec that falls back to software decode. Conversely, if your user base includes older browsers or constrained environments, a “better” codec can produce the opposite result.
In practice, you should test:
Chrome, Safari, and Firefox on desktop.
At least one iOS device and one Android device.
Cold start versus warm start.
Good network versus lossy or high-latency network.
Measure the time from session start to first painted frame, not just connection establishment. That is the number users feel.
Codec settings are only one part of the media pipeline
If startup still feels slow after you pick a sane codec, the next suspects are usually:
ICE gathering and relay usage: long-path TURN relays can add real delay.
Signaling orchestration: unnecessary round trips before the peer connection is created.
Avatar generation latency: the model or rendering pipeline may not be producing the first frame quickly enough.
Client-side autoplay or rendering policy: browsers can block playback or delay paint until user gesture requirements are satisfied.
It is worth separating these layers when you measure. Otherwise you can spend time tuning codec settings to fix a problem that is actually in the signaling path.
What this looks like in a LiveKit-based avatar agent
If your agent runs in LiveKit, the practical place to apply these ideas is where you attach the video track and configure the sender. The goal is to make the avatar video behave like a low-latency realtime track, not like a conventional uploaded media asset.
With the LiveKit-based quickstart or the LiveKit Agents plugin, you typically keep the media path narrow: create the session, join the room, attach the avatar track, and ensure an early keyframe is produced when the track becomes active. The exact field names and supported options are in the docs, but the shape is usually something like this:
The key point is not the specific API call. It is that the avatar should enter the room with a codec and initialization path optimized for immediate decode, not just good steady-state quality.
If you are building your own control plane around avatar sessions, the REST API is the place to manage those sessions and associated parameters. A minimal session creation request might look like this:
Use the exact session fields documented at docs.protoface.com; the useful part here is the workflow: choose a quality tier that matches your startup and bandwidth goals, then validate the first-frame timing end to end.
A simple checklist for faster avatar startup
If I were reviewing a production avatar call for startup latency, I would check these items first:
Is the initial video codec one the browser can decode efficiently on your target devices?
Is the starting resolution smaller than the final steady-state resolution?
Is the initial bitrate conservative enough to avoid network ramp-up delay?
Is a keyframe guaranteed immediately on track start?
Are you measuring first paint, not just peer connection time?
These five questions usually surface the real bottleneck quickly.
Conclusion
For AI avatar calls, startup time is mostly a media engineering problem. The fastest wins usually come from choosing a broadly supported codec, starting at a smaller resolution and bitrate, and ensuring the first frame is a keyframe the browser can decode immediately. Those changes reduce perceived latency without forcing you to redesign the rest of the stack.
If you are integrating an avatar into a voice agent or realtime app, keep the optimization goal focused: get a believable face on screen and synchronized with speech as quickly as possible, then scale quality after the session is live. For implementation details, examples, and supported options, see docs.protoface.com and the relevant quickstarts in the GitHub org.