Frame Rate

Throttle how often a video or live stream is run through the Pop

fps throttles how often a video or live stream is run through the Pop. It is the single most effective control over cost and over keeping up with a live source: a 30fps camera watching a door does not need 30 inferences a second.

The value is a fraction string — "1/1" for one frame per second, "5/1" for five, "1/2" for one every two seconds. Left unset, every frame the source delivers is processed.

Python

job = endpoint.load_from(
    "rtsp://camera.example.com/stream1",
    fps="1/1",
)
while result := job.predict():
    print(result)

Node

const results = await endpoint.process({
    source: { url: 'rtsp://camera.example.com/stream1' },
    fps: '1/1',
})

Throttling drops frames before inference; it does not change what a prediction looks like. Each prediction still carries its own seconds timestamp, so gaps in the sequence are visible rather than silent.

fps does not reduce network bandwidth. The throttle sits on the decoded video: the whole stream is still transferred and decoded, and frames are dropped after that, immediately before inference. What it saves is inference work, not transfer.

To spend less bandwidth you have to change what is sent. Re-encode the video at a lower frame rate before uploading it, or configure the camera to publish a lower rate — most IP cameras expose a second, lower-rate sub-stream for exactly this, and pointing the Pop at that sub-stream's URL is usually the cheapest fix.