On Imou Open Platform, a cloud live address is a bearer credential. The bindDeviceLive documentation warns that once a live address is made public, others can directly view the camera footage. One call also creates more addresses than it returns — HD and SD streams over HTTP and HTTPS — so creating live URLs is an access-control decision and an inventory obligation, not a protocol preference.
The sentence most teams skim past
It sits at the top of the bindDeviceLive page: "After the live broadcast address is made public, others can directly view the camera video footage. Please take good care of your live broadcast address."
That is the entire security model, stated plainly. There is no second factor on the URL. Possession is authorisation.
Which means the moment your product calls this interface, you have minted something with the properties of a password and none of the handling conventions of one. It will end up in a support ticket, a Slack thread, a CMS field, a screenshot in a QA bug, or a partner email — unless you decide in advance that it will not.
What one call actually creates
This is the part that breaks people's mental model, and it is documented.
When a device channel creates a live broadcast, the platform creates HD main stream, SD secondary stream, HTTP and HTTPS address types by default in the background. The interface returns only the address for the currently selected stream over HTTP. The rest are discoverable through getLiveStreamInfo or in the developer console.
The liveList sample output shows exactly this: a single live token carrying four HLS entries — HD and SD, plain HTTP and HTTPS variants.
So "we issued one live URL" is almost never true. You issued a family of them, and your revocation story has to cover the family, not the string you happened to log.
HLS and RTMP are different tools with the same exposure
HLS (bindDeviceLive) |
RTMP (createDeviceRtmpLive) |
|
|---|---|---|
| Created by | bindDeviceLive |
createDeviceRtmpLive |
| Returns |
liveToken, liveStatus, stream entries with hls and coverUrl
|
rtmp (SD) and rtmpHD addresses |
| Typical consumer | Web, H5, embedded pages | Encoders, media servers, RTMP pipelines |
| Removed by |
unbindLive (by live token) |
deleteDeviceRtmpLive |
| Inventory |
liveList, getLiveStreamInfo
|
queryDeviceRtmpLive |
| Auth to create | Administrator accessToken
|
Administrator accessToken
|
| Exposure model | Whoever holds the address can watch | Whoever holds the address can watch |
Note the last two rows. Both creation interfaces require an administrator token, which makes them backend-only by construction — an app or browser that can call them is already a finding. And both produce addresses with identical exposure characteristics. Choosing RTMP because it feels more "internal" is not a security control.
Also worth knowing before you debug a black player: cloud live broadcast only supports H264 video coding and AAC audio coding outflow. The docking-mode page states this and directs you to the device's local LAN management page to switch encoding format for player compatibility. A device left on H.265 is a device that will not play through this path.
Treat live addresses as an operated asset
Four practices, offered as recommendations rather than as documented Imou requirements:
Own the ledger. Every live address you create should have a row: which device and channel, who requested it, why, when it expires in your policy, and who may hold it. liveList and getLiveStreamInfo tell you what exists on the platform. They cannot tell you who was supposed to have it.
Make revocation routine. unbindLive takes the live token; deleteDeviceRtmpLive removes the RTMP address. If nobody on the team has ever run either, you do not have a lifecycle — you have accumulation. One useful default: the documentation notes the live address is deleted automatically when the device is unbound, but do not let device offboarding be your only cleanup path.
Front the address with your own gate. If end users need to watch, serve them through a page your application authorises, rather than handing out the platform address. Your product owns who is allowed to watch; the platform only knows who is holding the string.
Watch the status field. liveStatus is documented as 1 open, 2 pause and 3 insufficient traffic. The third value is the one people never handle, and it turns a billing condition into a support ticket that looks like an outage.
The reframe
"Which protocol should we use?" is a two-minute decision driven by the consumer: a page takes HLS, a media pipeline takes RTMP. "Who is allowed to hold this address, and how do we take it back?" is the decision that actually determines whether a camera ends up somewhere it should not be.
Pre-publish verification
Recheck the live interface pages on publication day. Every protocol name, generated-address behaviour, status value and encoding constraint above is stated only as the official pages state it; the ledger, revocation and gating practices are labelled as recommendations.
Live interface documentation: Equipment live. Platform overview: open.imoulife.com. Video capability detail: Video Monitoring.
Top comments (0)