@mega-yfue/eufy-sdk / LiveVideoFrame

Interface: LiveVideoFrame

One decoded video access unit, as Annex-B (H.264 or H.265).

A WHOLE access unit, always: a station serves a unit larger than its chunk size as several frames, and those are reassembled before delivery — so deciding anything per access unit (begin at a keyframe, switch codec at a keyframe, count frames) operates on what it says it does. A unit the transport could not complete is dropped rather than delivered short, because an access unit shorter than its own slice headers promise decodes to no picture at all.

Properties

codec

codec: VideoCodec;

Codec of the elementary stream this access unit belongs to. Sniffed off the parameter sets on a keyframe and carried on the delta frames that follow (a delta frame has no config to sniff).

---

data

data: Buffer;

Annex-B bytes (one or more NAL units, start-code prefixed).

---

height

height: number;

See width — the same field, and it moves with it.

---

keyframe

keyframe: boolean;

True on an IDR — a unit a consumer may begin decoding at, never a continuation of an earlier one.

---

width

width: number;

Frame geometry as the station's own frame header states it — height is the same field.

A camera reconfigures its live source WITHIN one session, so these change between frames of one stream. Measured on eight cameras and both codecs: four of them changed, 2 to 9 times per 25-60 s, oscillating up and down a ladder rather than only climbing it; the other four held one geometry throughout. A change arriving on a keyframe carrying fresh parameter sets is what every run but one showed, and that run is not accounted for, so it is not a property to rely on.

This is what the station REPORTED. The size a decoder will actually produce is stated by the parameter sets, and a consumer is told it through LiveStreamConsumer rather than having to retain these and diff every frame against them.