Traditional live streaming has one broadcaster and many viewers. Collaborative streaming inserts guest broadcasters who must exchange low-latency media with the host while viewers continue watching the combined channel. The transition changes more than layout. It can change RTMP to RTP, AAC to Opus, CDN origin, congestion-control state, and the location where streams are mixed.
TikTok’s first architecture, DualNet, kept the mature live path and added a separate collaborative path[1]. That minimized the first rollout but made every invitation a switchover between two systems. Viewers effectively subscribed to another stream, the host created a new transport session, and audio encoders carried different delays. Audio and video stalls appeared at the point intended to increase engagement.
AnchorNet makes the publishing path invariant. The host maintains one RTC application and transport session. RTC servers bridge it to the same CDN node in both modes. When guests join, a server-side mixer combines their streams and returns the program output to that path. Leaving collaboration removes the mix without changing the channel’s CDN identity.
Why mixing remains on the server
Mixing can occur on the host device, at a media server, or in each viewer. Host mixing saves server compute and gives the broadcaster direct switch control, but requires multiple uplinks and makes phone CPU, battery, and access bandwidth part of channel capacity. ByteDance’s prototype consumed about 15% additional host CPU for mixing, and adding seven guests added another 15% CPU. Two competing uplinks can also halve viewer bitrate on a constrained first mile.
Viewer-side mixing distributes compute but asks every viewer to fetch and synchronize several streams. For a service with more than a billion users, subscription and device diversity make that fan-out expensive. Server mixing produces one stream for CDN distribution and removes client performance as the maximum guest-count boundary.
AnchorNet therefore retains server-side mixing. An RTC selective forwarding unit exchanges media among broadcasters, while a multipoint control unit mixes and transcodes the viewer program. The host publishes one stream toward the CDN. The price is an SFU-to-MCU round trip and CPU plus memory for every active mixing task.
The architecture is not claimed as universal. A small conferencing product may prefer SFU delivery to viewers, and a high-end broadcaster can mix locally. AnchorNet’s choice follows its device population, existing CDN, and very large viewer fan-out.
Codec delay makes a simple switch audible
Basic live streaming uses AAC end to end, while broadcaster RTC uses Opus for lower delay and loss resilience. Encoders buffer samples before producing a valid frame. If a controller switches at a packet timestamp without accounting for those buffers, it can insert silence, duplicate samples, or discard part of speech.
AnchorNet coordinates broadcaster and RTC server at audio-sample granularity. It tracks the encoder delay of the old and new paths, selects a splice point, and aligns timestamps so the first sample after the switch follows the last delivered sample. The goal is continuous audio even if video briefly repeats during a screen-layout transition.
This asymmetry is deliberate. Viewers notice a click or missing syllable immediately, while a momentary repeated video frame can be concealed by the UI changing from one large host view to a guest grid. AnchorNet may replay or re-encode several video frames for audio-video synchronization and adjust playback speed after the switch. The system optimizes perceived continuity rather than insisting that both media timelines move identically.
Small-scale tests found no audio rebuffering for AnchorNet switches. DualNet produced seconds-scale audio and video stalls, and another evaluated product introduced roughly 100 milliseconds of audio pause per switch. The controlled setting isolates the splice mechanism but does not represent weak mobile access links, which is why the production A/B test is the stronger result.
Four weeks of production switching
The 2024 fourth-quarter A/B test lasted four weeks and assigned almost equal user populations to AnchorNet and DualNet. Reported differences reached at least 95% statistical confidence. When a channel moved from live to collaborative mode, video stall duration per viewer fell 60.3% and stall count fell 60.1%. Audio duration and count fell 67.4% and 64.5%.
The reverse transition improved more. Collaborative-to-live video stall duration fell 78.9% and count 78.5%; audio duration fell 77.1% and count 76.3%. The asymmetry reflects the different startup and teardown work in the two architectures. “More than 60%” is a safe summary, but the direction of the switch remains part of the result.
Daily active time increased 0.53% for host broadcasters, 2.15% for guest co-broadcasters, and 3.83% for viewers. The paper argues that the viewer metric reflects genuine engagement because each viewer session already includes every mode switch; merely shortening a stall does not mechanically add the same amount to watching time. It is still an online correlation inside one product rather than proof that every streaming service gains 3.83%.
The experiment also illustrates why a transition system needs mode-specific instrumentation. An aggregate stall rate would mix ordinary playback with the short interval where the publishing graph changes, hiding whether a lower number came from a better transport or simply fewer collaborative sessions. AnchorNet records direction, media type, duration, and count for each switch. A deployment team should additionally split results by access network, device codec capability, guest count, and distance to the selected mixer. Those dimensions determine whether a single global average represents the population or masks a slow regional tail.
AnchorNet also improved ordinary live mode because its user-space congestion control handled uplink variation better. Video and audio rebuffering fell by as much as 13.47% and 11.02%, and host push frame rate increased 3.11%. Host CPU fell 1.33% because the implementation preferred hardware codec acceleration, while GPU usage rose 0.8% and memory 0.31%. Those are implementation effects separate from the unified-path mechanism.
Mixing cost and geography set the boundary
At the median, one server-side mixing task stayed below four-tenths of a logical CPU core while occupying 220 MB of memory. ByteDance estimates that a 128-thread server with more than 500 GB of memory can support about 15,000 to 30,000 concurrent collaborative channels using 100 mixer instances. Capacity varies with guest count, codec, resolution, and percentile, so the range is a deployment estimate rather than a fixed server specification.
The extra SFU-MCU path is visible when the mixer is far away. Globally, AnchorNet’s end-to-end streaming delay was similar to DualNet because DualNet reserved a larger CDN jitter buffer during collaboration. In a selected country far from the nearest MCU, AnchorNet added an average 170 milliseconds in collaborative mode. Wider edge-MCU placement can reduce that delay but increases fleet cost and operational surface.
Mixing and transcoding add hundreds of milliseconds between solo and collaborative modes even when the switch itself is smooth. CDN and viewer jitter buffers conceal variation; they do not remove propagation or compute time. Services with tighter end-to-end needs, such as interactive commerce, may need more edge mixers or a different viewer path.
The unified session also concentrates dependency on RTC servers. A bridge failure can affect both modes rather than only collaboration. Migration must preserve sequence numbers, timestamps, congestion state, and CDN ingest continuity. AnchorNet reduces the number of components coordinated during a planned mode change, but failover remains a separate design obligation.
The architectural lesson is continuity of identity
AnchorNet treats the channel, transport session, and CDN ingest as stable identities while media composition changes behind them. That prevents a feature transition from becoming an origin migration. The same principle applies to services that switch codecs, presenters, or compute backends during a user session: preserve the external subscription and move variability behind one anchor.
Continuity needs media-aware handling. Packet sequence alone cannot bridge codec lookahead, and a mathematically synchronized timeline may be perceptually worse than hiding a video repeat under a layout change. Measurements should therefore include audio and video stall count, stall duration, end-to-end delay, device pressure, server mixing cost, and engagement.
Rollout order matters as much as steady-state capacity. A service can first anchor publishing sessions while retaining the old viewer path as a fallback, then enable server mixing for a controlled cohort, and only later remove the parallel RTC path. This sequence keeps the rollback unit at the session or region level. It also makes protocol compatibility explicit: every intermediate state must preserve timestamps and codec parameters that both the old CDN ingest and the new mixer understand. The architectural simplification is realized only after this coexistence period, not at the first successful switch.
ByteDance’s production result demonstrates that architectural consolidation can repay migration complexity. It also shows the remaining trade: smoother mode switching is purchased with server mixing and additional path length. The correct deployment point depends on viewer fan-out, phone capability, edge-MCU coverage, and how much latency the application can exchange for a single stable publishing path.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the deployed architecture, measurements, and limits in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX ATC 2025 presentation page. Copyright remains with the authors, 2025.