Feature request: setVideoDimensions on remote video publications (adaptive subscribe resolution)

[jiyeyuran]

Summary

The JavaScript/TypeScript client SDK exposes RemoteTrackPublication.setVideoDimensions({ width, height }), which lets subscribers request a target receive resolution per remote video track from the SFU. The C++ client SDK does not appear to offer an equivalent API today.

We would like parity with the JS SDK so native/C++ subscribers can adapt inbound video resolution to downstream layout needs (multi-party compositing, grid tiles, stage/speaker layouts) without subscribing at full publisher resolution for every track.

Use case

We run server-side media pipelines that subscribe to LiveKit rooms, composite many participants (grid / speaker layouts), and push to RTMP, HLS, or similar outputs. On our browser-based subscriber we already drive adaptive subscriptions from compositor tile sizes:

pub.setVideoDimensions({ width, height });

When a participant is shown in a small grid cell we request something like 320×180; when they are on stage we request a larger cap (e.g. 640×360 or 1280×720). This materially reduces CPU, bandwidth, and decode cost for N-way rooms.

We are building native pipelines on top of the C++ SDK and need the same capability there.

Expected API (rough sketch)

Something along the lines of:

// On a subscribed remote video track publication
publication-> setVideoDimensions(int width, int height);

Semantics should match the JS SDK:

• Request the SFU to deliver video at approximately the given dimensions (not necessarily exact pixels).
• Per-track, independent of other subscribers.
• Safe to call when subscription hints / layout change; idempotent when dimensions are unchanged.
• No-op or clear error when the publication is not subscribed or not a video track.

Why this matters

Without setVideoDimensions (or equivalent), a C++ subscriber tends to receive publisher-native resolution on every track. For 9+ participant grid layouts this means:

• Unnecessary downscale work in the compositor
• Higher SFU egress and client decode load
• More visible dimension churn during simulcast/SVC layer switches

The JS SDK already solves this; native subscribers should not be second-class.

References

• JS SDK: RemoteTrackPublication.setVideoDimensions on subscribed remote video publications.
• Related web SDK surface: subscription / dimension control on RemoteTrackPublication (naming may differ slightly by SDK version).

Environment

• Consumer: server-side subscriber (composite / transcode), not a typical mobile client
• Room sizes: often 4–16 video participants
• Codecs: typically H.264 from publishers; subscriber may decode and re-encode

Happy to provide more detail or help validate an implementation.