Imou-OpenPlatform

Posted on Aug 31

Implementing Two-Way Talk and Video Download with Imou Mobile OpenSDK

#camera #automation

Two-way talk and recorded-video playback and download are client OpenSDK capabilities on Imou Open Platform, not things you get from a cloud live URL. The homepage lists monitor video play, two-way talk, and record video play and download under Client openSDK Development. The docking-mode page confirms it from the other side: cloud live broadcast docking supports real-time preview but not video playback and not voice intercom.

Why the SDK, and not the live address

This is the single most common architecture mistake in this area, so it is worth stating precisely.

Imou's Select docking mode page compares three docking modes. Read the rows rather than the marketing:

	Mobile application docking	Cloud live broadcast docking	Desktop application docking
Support agreement	Private agreement	hls	Private agreement
Real-time preview	Support	Support	Support
Video playback	Support	Not support	Support
Voice intercom	Support	Not support	Support
Equipment configuration	Support	Not support	Not support
Docking cost	High	Very low	High

If your requirement is "operators need to talk to the site and pull the clip afterwards", the cloud live column has already disqualified itself. A cloud live HLS address is a one-way viewing surface. No amount of frontend work turns it into an intercom.

That leaves the client SDK path — and on mobile, that is the mobile OpenSDK.

What the mobile guide says the SDK owns

The mobile application development guide is explicit about the division. Device network configuration, device initialization, audio and video playback, and picture decryption are implemented with the client SDK, referring to the DEMO. Everything else — account binding, device binding and unbinding, device management, device operation, cloud storage management, alarm message management — is recommended to go through your background service calling the open platform HTTP interfaces.

The guide also notes that video preview does not require an HTTP interface call at all: you call the OpenSDK embedded in your application, and follow the SDK instructions and DEMO for the playback implementation.

So the media path — preview, talk, recorded playback and download — is SDK territory. The control and business path is HTTP territory. Your app talks to both, but for different reasons.

Capability is a per-device question

Nothing here is a brand-level guarantee, and the official pages are careful about this.

The Video Monitoring page puts it plainly: two-way audio is available for supported devices and integration methods, and developers should check device capabilities and the SDK/API documentation for implementation requirements. The same page frames live preview, playback, PTZ, screenshots, recording and two-way talk as available "depending on device capabilities and the selected SDK or API".

There is corroborating evidence in a neighbouring component. The ImouPlayer JavaScript SDK — a different product from the mobile OpenSDK, so treat this as illustrative rather than transferable — documents an explicit error for a device that does not support video talk, alongside errors for intercom address retrieval failure, an existing talk stream source, a busy line, and the device hanging up. That is what device-dependence looks like once it reaches an error table.

Design consequence: your UI must be capability-gated. Ship the talk button as a per-device flag resolved from your ledger, not as static chrome. A disabled control with an explanation is a supportable product. A live button that returns an error is a ticket.

A reference implementation flow

Backend obtains accessToken. appId and appSecret never enter the app binary. This is the first of the four core functions in the mobile guide.
Backend queries the device list and persists a ledger row per device and channel, including whatever capability information your integration documents. Your UI reads the ledger.
Backend authorises the action against your own permission model before anything else happens. Imou's sub-account model gives you the vocabulary — each sub-account is associated with a user in your application, and interface pages state the minimum permission required, such as RecordReplay on a cam: resource for cloud recording queries.
App embeds the OpenSDK and performs preview through it, following the SDK instructions and DEMO from the component download.
App initiates talk through the SDK, gated on the capability flag from step 2 and the authorisation from step 3.
Backend enumerates recordings over HTTP. For cloud recordings, getCloudRecords returns clips in reverse chronological order, a maximum of 30 per call, with recordId, beginTime, endTime, size, thumbUrl, encryptMode and a recording type. Paginate by feeding the smallest beginTime from the previous page back as the next endTime.
App plays back and downloads through the SDK. Recorded video play and download is listed as an openSDK capability; the enumeration that tells you which clip is an HTTP concern.

Note the shape: HTTP decides what exists and who may see it; the SDK moves the media.

Timing: request stream sources late

One documented operational point is worth carrying across. The ImouPlayer FAQ notes that for real-time recording, talkback, live streaming and video download you should avoid making requests in advance — trigger the interface to obtain the stream address only when it is actually needed, to prevent stream-source timeout and to avoid confusion from simultaneous requests to different stream sources.

That is written for the Light App component, but the underlying behaviour is the same class of problem in any client: a stream source fetched optimistically at screen-load and used thirty seconds later is a stream source that may already be dead.

Recommendation (mine, not a documented Imou requirement): wire talk and download to explicit user intent. Do not pre-warm them when a detail view opens.

Things this article will not tell you

Being direct about the gaps is more useful than filling them:

Codec requirements for talk. Not asserted here. The cloud live path has a documented encoding constraint, but that is a cloud live constraint and does not describe the SDK's private-protocol talk path. Confirm against the SDK documentation for your platform and firmware.
Half-duplex versus full-duplex. Not established by the pages cited. Do not design a push-to-talk versus open-channel UX on an assumption; verify on real hardware.
A per-model support matrix. Models change. Query capability.
Specific mobile SDK function names. Take these from the SDK instructions and DEMO in the component download rather than from an article.

Pitfalls

Building talk on top of a cloud live URL. The docking-mode table says it is not supported; the failure will be architectural, not a bug.
Putting an administrator token in the app so the client can call HTTP interfaces directly.
Assuming download means a plain file. Cloud recordings carry an encryptMode, and alarm images have a separate decryption path that the docs place in the client SDK.
Requesting more than 30 cloud recording clips in one call, or paginating forward instead of walking backwards from the smallest beginTime.
Promising talk in a roadmap before a representative device — not the demo unit — has been verified.

DEV Community