@mega-yfue/eufy-sdk / LiveStreamConsumer

Interface: LiveStreamConsumer

One consumer's view of a live stream, carrying the flow control a sink needs to apply backpressure.

A sink that cannot keep up calls pause, and the frames it would have received queue against a bound instead of accumulating behind the sink. Crossing that bound drops the backlog and resynchronises at the next IDR, so a sink that stays slow resumes on decodable media rather than replaying stale media. resume stops the moment the sink pauses again, so the bound keeps applying to whatever is left.

This is per consumer: pausing never stalls the shared source or any peer consumer.

Extends

• LiveStreamHandle

Extended by

• LiveConsumer

Properties

awaitingKeyframe

readonly awaitingKeyframe: boolean;

True while this consumer is dropping frames after crossing its bound, waiting for the next IDR.

Methods

nudge()?

optional nudge(force?): void;

Re-issue the media-start command (start-race retry / keepalive nudge). Optional.

force states that the channel is NOT being served, so a real start is required rather than a keepalive. An own-session camera sends one or the other depending on whether its session believes the channel is already started — a belief that outlives a station which acknowledged a start and then served nothing.

Parameters

force?

boolean

Returns

void

Inherited from

LiveStreamHandle.nudge

---

on()

Call Signature

on(event, listener): this;

The coded configuration of the video that follows, announced immediately before the first frame carrying it and again whenever it changes.

A camera reconfigures its source repeatedly within one session, and an encoder opened for one geometry cannot accept a frame of another — so a consumer adapting this source to a fixed output has to rebuild on every change. Fires once per change rather than per frame, beginning with the first frame this consumer receives, so a consumer holding media it has not been told the configuration of is not a state it can reach.

Per consumer, against what THIS consumer was last given: a consumer that joins mid-session is primed with a cached keyframe it did not witness arriving, and one that crosses its bound resynchronises onto a later IDR having skipped the frame the source saw the change on. Announcing what the source saw would leave both holding an encoder built for media they never received.

Only a consumer announces this, never a bare LiveStreamHandle: it is read from the parameter sets a shared source watches every frame for, which the raw pull underneath it does not do. That is also why the inherited events are restated here — a subtype may add an overload only by declaring the whole set.

Parameters

event

"video-config"

listener

(config) => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

One whole video access unit — see LiveVideoFrame.

Parameters

event

"video"

listener

(frame) => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

One audio access unit, in the codec the station declared for it.

Parameters

event

"audio"

listener

(frame) => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

Battery-budget elapsed — extend to keep streaming or let it auto-stop (battery cameras only).

Parameters

event

"start" | "stop"

listener

() => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

Why this consumer's stream is over, including a warm-up that never produced a keyframe.

Parameters

event

"error"

listener

(err) => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

Battery-budget elapsed — extend to keep streaming or let it auto-stop (battery cameras only).

Parameters

event

"budget"

listener

(notice) => void

Returns

this

Overrides

LiveStreamHandle.on

Call Signature

on(event, listener): this;

A media start was repeated to its acknowledgement deadline and abandoned.

The start is repeated byte-identically, so an abandonment is many sends with no reply — the device was never told to stream, and a warm-up waiting on it can only time out. Distinct from error: the transport is intact and the session is simply not being heard.

Parameters

event

"unacknowledged"

listener

() => void

Returns

this

Overrides

LiveStreamHandle.on

---

pause()

pause(): void;

Hold delivery — frames queue against the bound until resume.

Returns

void

---

resume()

resume(): void;

Release delivery and hand over the queued backlog, stopping if the sink pauses again mid-drain.

Returns

void

---

start()

start(): this;

Returns

this

Inherited from

LiveStreamHandle.start

---

stop()

stop(): void;

Returns

void

Inherited from

LiveStreamHandle.stop