We are experiencing an issue with Custom Livestreaming and would appreciate clarification on the expected behavior.
Environment
Zoom Meeting SDK (Web) - Component View
Custom RTMP Livestream to Amazon IVS
Livestream started programmatically via Zoom API
Livestream layout configured as follow_host
Issue Description
We expect the livestream output to reflect the layout selected by the host. However, regardless of the layout selected by the host, the RTMP stream sent to IVS always appears to remain in Active Speaker View.
What We Have Observed
The host joins the meeting and changes layouts (e.g., Gallery View, Speaker View).
The layout changes are reflected correctly within the meeting experience.
The livestream is configured with layout=follow_host.
Despite this, the RTMP output received by IVS remains in Active Speaker View and does not appear to follow the host’s selected layout.
Troubleshooting Performed
Verified that the livestream is configured with layout=follow_host.
Attempted programmatic layout changes.
Confirmed that the meeting UI reflects the requested layout changes.
Observed that the RTMP output remains unchanged and continues to behave like Active Speaker View.
Questions
Is layout=follow_host expected to work when the meeting is being hosted/joined through Meeting SDK Component View?
Does the RTMP livestream compositor follow layouts from Component View, or only from native Zoom clients (Desktop/Web/Mobile)?
Are there any known limitations or requirements when starting a custom livestream via API that would cause the stream to remain in Active Speaker View?
Is there a supported way to force Gallery View in the RTMP livestream output when using Meeting SDK Component View?
Any clarification on the expected behavior would be greatly appreciated.
This seems like an undocumented behavior gap rather than a confirmed IVS issue. Zoom’s meeting livestream status API supports a livestream layout setting with follow_host, gallery_view, and speaker_view, and it says action mode can control a meeting livestream view at runtime. The docs only define follow_host as following the host view. They don’t say that Component View layout changes are used as the source for the RTMP compositor.
The supported way to force Gallery View for a meeting livestream is to drive it through the livestream status API with gallery_view, not through the SDK UI layout. Two checks: after the stream is already started, send action mode with settings.layout set to gallery_view and confirm whether the IVS output changes. Also verify the host and account meet Zoom’s custom livestream requirements, since custom streaming must be enabled and the host must be licensed. If that API-level gallery_view change still stays in Active Speaker, I’d escalate to Zoom with the meeting ID, SDK version, API request body, timestamp, and IVS capture.
For capture workflows where livestream layout behavior is a risky integration point, Recall.ai’s Meeting Bot API may be a cleaner option.
Hi @Gdrum@Staging1 Just got a response from engineering. There are a couple of points:
Component View officially does not support Live Streaming according to our client <> component comparison doc here. This would explain why the messaging pipeline does not initially work in your testing. This would also explain why the workaround using the desktop client works since the correct signaling is then established once they are granted the host permissions. I understand this might be confusing since the live stream option is still available on the component view so I will work with engineering on better updating the docs to explain what exactly is not supported in that case.
Engineering has recommended some solutions which might be similar what we already discussed:
Use Client View — it’s an exact copy of the Zoom Web Client and fully supports live streaming with the follow_host layout. This is the recommended path. I have a meeting with our web team managers and can get more details on React 19 support.
Host transfer workaround (your current workaround) — Temporarily assigning the host to a Zoom Desktop Client user, then transferring back, forces the stream to follow that user’s view. This works because the Desktop Client properly implements the host-view signaling.
Use explicit layout values — Instead of follow_host, set layout to "speaker_view" or "gallery_view" explicitly via the REST API. These static layouts don’t depend on host-view signaling and will render correctly regardless of the client type.
Additionally, we do have the RTMS option to explore for this and other use cases you’ve mentioned.
I’ll continue to update you on the internal meetings from today.
@ticorrian.heard@Staging1 Ticorrian, thank you for the prompt response. The documenation on live stream support for component view will be helpful, curretnly it only notes Webinar is not supported. Note we are using meeting not webinar if that makes a difference. Let’s connect on React 19 rendering def. and if any issues with iframe, etc.
The RTMS from my look, seemed like we would have to design a gallery view so if there is some better info on how that works to recreate a speaker, spotlight, gallery and it’s reasonable that would seem like an option too.
Hi again @Gdrum I spoke with some of our engineering managers recently and confirmed that live streaming is indeed supported on both client and component view. As it turns out, the documentation referenced from my last response was actually out of date. Apologies for the confusion here! Our doc team is working on updating that guide and I am working with engineering on classifying the behavior youre experiencing as a bug.
Regarding React 19, engineering confirmed that the development for this is slotted for q1 of next year due to other priorities with the product. In this case, I believe our best course would be to fix the component view bug youre experiencing for the short term.
