https://livekit.io logo
Join Slack
Powered by
I changed the video codec to H.264 and set the max...
# ask-ai
b
I changed the video codec to H.264 and set the max_bitrate to 4,000,000, but the bitrate doesn’t increase beyond 400,000. We were previously using VP8, and it worked fine back then.
t
Thanks for reaching out, 최윤지. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m looking at the issue where you switched to H.264 and set 
max_bitrate
to 4,000,000 but the sent bitrate stays at ~400,000. I’ll help narrow this down and get you a fix. Quick checklist and targeted steps to diagnose & fix (please run the ones you can and share results): 1) Are you using simulcast (default)? • If yes, the SFU and encoder may be splitting/capping per-layer bitrates. Can you try temporarily disabling simulcast and retesting? Example publish setting to test:
Copy code
publishDefaults: {
  simulcast: false,
  videoEncoding: { maxBitrate: 4_000_000, maxFramerate: 30 },
}
Tell me whether bitrate rises after disabling simulcast. 2) If you need simulcast, explicitly set simulcast layer encodings so the high layer can use 4 Mbps. Example to apply (share how you’re publishing so I can adapt it):
Copy code
videoSimulcastLayers: [
  { width: 1920, height: 1080, encoding: { maxBitrate: 4_000_000, maxFramerate: 30 } },
  { width: 960, height: 540, encoding: { maxBitrate: 1_500_000, maxFramerate: 30 } },
  { width: 480, height: 270, encoding: { maxBitrate: 400_000, maxFramerate: 15 } },
]
3) Check client encoder limits (H.264 vs VP8): • H.264 often uses hardware encoders which can impose bitrate caps. Open chrome://webrtc-internals and under your outbound H.264 track check 
framerateSent
, 
bytesSent
, and active layers. Do you see only a medium/low layer active or low frame rates? 4) Confirm subscribers & bandwidth estimation: • The SFU won’t forward high layers unless a subscriber requests them and the estimated available bandwidth supports them. Is there an active subscriber that should be receiving the high layer? Are clients reporting low available bandwidth or using low-quality mode? 5) Source resolution & motion: • What resolution are you publishing (camera vs screen share)? If the source is low-res or low-motion, the encoder may stay at low bitrate. Try publishing a high-motion 1080p source and report observed bitrate. 6) CPU/GPU and dropped frames: • In webrtc-internals, check for dropped frames or high QP. Are you seeing many dropped frames or 
framerateInput
>> 
framerateSent
? If you prefer, share these details and I’ll interpret them for you: • Publishing code snippet (how you set 
max_bitrate
/ publishDefaults / simulcast) • Browser / device (Chrome/Firefox, mobile/desktop) • Whether subscribers are present and any webrtc-internals snapshots (values for 
bytesSent
, 
framerateSent
, active layers) Which of the above steps can you run now, or would you like me to walk you through checking chrome://webrtc-internals? Sources: WebRTC Video Bitrate Guide | LiveKit | Bringing Zoom's end-to-end optimizations to WebRTC
b
We're using livekit agents, and set agent's codec and max bitrate. Even though network is very good, bitrate seems low. (i used webrtc internals in client)
t
Thanks — I hear you: you set the agent’s codec and 
max_bitrate
, network looks good, but webrtc-internals shows the bitrate stuck low. I can help diagnose — a few quick clarifying questions and one immediate test: Questions (please paste answers/snippets where possible) 1. How are you configuring the agent’s codec and bitrate? Share the publish code or agent config snippet (especially 
publishDefaults
, 
simulcast
, or 
videoSimulcastLayers
). 2. Are you running simulcast on the agent (default is often true)? If yes, did you set per-layer encodings or only a global 
max_bitrate
? 3. Are there active subscribers when you measured bitrate? If yes, how many and on what device/browser? 4. Which browser/device did you inspect in chrome://webrtc-internals? 5. From webrtc-internals, what are the outbound track values for the H.264 track: 
bytesSent
(or 
bitrate
graph), 
framerateSent
, and which RTP/scale layers are active (look for entries showing multiple SSRCs or "simulcast" layers)? Immediate test • Temporarily disable simulcast on the agent and republish with a single-layer encoding at 
maxBitrate: 4_000_000
. If you want, paste the code you used and I’ll show the exact change to test. Tell me the answers and results from the test and I’ll point to the most likely cause and exact config changes to get the high layer to send.
b
how to turn off simulcast? give code.
t
You're asking how to disable simulcast — here are concise code examples. JavaScript / TypeScript — disable for the whole Room (all publishes):
Copy code
const room = new Room({
  publishDefaults: {
    simulcast: false,
  },
});
JavaScript / TypeScript — disable for a single track publish:
Copy code
const videoTrack = await createLocalVideoTrack(/* options */);
await localParticipant.publishTrack(videoTrack, { simulcast: false });
Python — disable for a single track publish:
Copy code
await local_participant.publish_track(
    track,
    PublishTrackOptions(simulcast=False),
)
Try one of these, then check chrome://webrtc-internals again. Want me to show the exact change for your agent code snippet if you paste it? Sources: Codecs and more | LiveKit docs
10 Views
Open in Slack
PreviousNext
Powered by