Why we cap Facebook feeds at ~4 Mbps instead of making you re-encode

Facebook Live is the destination most likely to object when a multistream sends a high-bitrate master unchanged. Above roughly 4 Mbps of video, the Facebook leg can disconnect or degrade even while the same source is acceptable elsewhere.

You should not have to lower the whole show for one destination. ApexStream keeps the source you send us and applies a roughly 4 Mbps cap only to the Facebook outbound leg. YouTube, Twitch, and the other connected destinations can keep the source or follow their own destination rules.

The cap is per destination

The media-node destination profile carries Facebook's approximate 4,000 kbps ceiling. If the source is above that ceiling, the relay uses a constrained outbound path for Facebook. The source-quality enforcer also knows about the Facebook-specific limit so it can warn when an outbound feed would otherwise be too high.

This does not change the bitrate you are allowed to send into ApexStream. Hobby allows 6,000 kbps at ingest, Creator 9,000, Scale 15,000, and Enterprise 50,000. Those are account limits. Facebook's roughly 4 Mbps rule is a destination limit. Fan-out is where the two rules separate.

Why the source should not be 4 Mbps by default

If you encode locally for Facebook, you have two unattractive options:

• Run a second encoder and pay for another CPU-heavy process.
• Drop the entire program feed to Facebook's rate and give every other destination a softer source.

Neither makes much sense when one relay can create the constrained copy after ingest. Free supports 2 destinations, Hobby 3, Creator 5, Scale 8, and Enterprise 50. A single source lets the relay apply the lowest common denominator only where it is needed.

The same design handles other destination differences. Facebook uses 44.1 kHz audio while the default audio path stays at 48 kHz. You send one source; the relay translates the Facebook leg.

Passthrough or transcode?

If your source is already below Facebook's ceiling and otherwise compatible, the relay can use a cheaper copy path. A 9 Mbps Creator source cannot be copied to Facebook at 9 Mbps, so that destination needs a constrained encode. YouTube or Twitch can still receive a higher-rate copy when their rules and your plan allow it.

That is why one destination can look unhealthy while another continues. Facebook may be rejecting a rate or the destination-specific path may have failed; it does not automatically mean the source or every platform is down. The point of per-destination handling is to keep one picky platform from taking down the whole show.

What to set in OBS

Before the show, check Facebook's status separately from the other destinations. A Facebook leg that is clamped is not evidence that your YouTube source should be lowered. If the Facebook destination remains unhealthy, inspect the destination connection and session state after confirming the source is within the ApexStream plan.

Set OBS or your encoder to a bitrate your ApexStream plan allows and your source resolution can use. If Facebook is one of several destinations, you can keep a 6 Mbps-class 1080p source when that fits the workflow and let the relay reduce Facebook's copy. If Facebook is the only destination, encoding at or under roughly 4 Mbps is also a reasonable choice; it simply should not be a requirement for every multistream.

Web Studio follows the same relay behavior after its WHIP uplink. There is no separate Facebook bitrate control in Scenes because the policy belongs at the destination edge.

If you change the source bitrate to troubleshoot Facebook, remember what that change affects: every destination, the recording source, and the source-quality check. Test the Facebook leg first so a destination-specific problem does not lead you to weaken the whole program.

The goal is a stable Facebook copy without making your best source profile conform to the most restrictive destination in the set.

Keep the source profile consistent and let the relay do the one-platform adjustment.

Your source settings describe the show. Facebook's limit describes Facebook. The relay keeps those two facts from fighting inside your encoder.

The cap is intentionally narrow: lower the Facebook copy, keep the rest of the fan-out useful, and give you one source profile to maintain.