Sources and Options
Every way to hand media to a Pop, and the options that shape how it is processed
A Pop describes what to run. A source is what to run it on: one image, one video, one live stream handed to a running session. Every inference is a source submitted to a session, whatever language you call from.
Each source carries its own options — a frame rate to throttle to, a region to crop, motion gating, per-component overrides. Options are set per source, so a single session can take a still at full resolution and a camera feed at one frame per second.
Upload or fetch
There are two ways the media reaches the worker, and the choice is usually made for you by where the media already is.
Upload
Fetch
Who moves the bytes
your application
the worker
Can reach
anything your process can read — local disk, memory, a browser File
anything the worker can reach over the network
Best for
files on the machine running your code, generated frames, browser uploads
camera streams, object storage, CDN-hosted media, anything large
Fetching keeps the media off your egress path entirely: you send a URL, the worker opens it. Uploading is the only option when the media is not reachable from EyePop's network — which is also the case for cameras on a private LAN, where Private Cameras covers the connectivity.
Supported sources
Local file
upload
upload(path)
process({ source: { path } })
Binary stream
upload
upload_stream(stream, mime_type)
process({ source: { stream, mimeType } })
Browser File
upload
—
process({ source: { file } })
HTTP(S) URL
fetch
load_from(url)
process({ source: { url } })
RTSP / RTSPS camera
fetch
load_from(url)
process({ source: { url } })
RTMP stream
fetch
load_from(url)
process({ source: { url } })
Browser webcam or screen (WebRTC)
push
—
process({ source: { mediaStream } })
Dataset asset
fetch
load_asset(asset_uuid)
process({ source: { assetUuid } })
Image group (2–16 images, one inference unit)
upload or fetch
upload_group, upload_stream_group, load_from_group
uploadGroup, uploadStreamGroup, loadFromGroup
Each is shown with runnable code in Source Types, and the image formats, video codecs, and containers behind them are listed in Supported Formats.
What comes back
A source produces a stream of predictions, delivered as they are produced rather than at the end:
an image — one prediction
a video or a live stream — one prediction per processed frame, until the source ends. A live stream ends when you cancel it
an image group — one prediction for the whole group, because a group is a single inference unit
Sources submitted to one session are queued and processed in order — submitting a second does not wait for the first to finish, but the worker runs them one at a time. To process several genuinely in parallel, use separate sessions.
Queueing is what the SDKs ask for, not the only thing the platform can do: the behaviour is chosen per source, and a source can also preempt whatever is running or be rejected outright. One source type takes that other path — a browser MediaStream preempts the running source, because live media that waits its turn is no longer live.
Next steps
Source Types — every source, with Python and Node examples
Supported Formats — the image formats, video codecs, and containers a Pop can decode
Source Options — frame rate, region of interest, motion gating, and component parameters
Pop Defaults — set options once on the Pop instead of on every source
Last updated