Supported Formats
The image formats, video codecs, and containers a Pop can decode
The worker decodes media itself, so what it accepts is a property of the platform rather than of the SDK you call it from. The same list applies to an upload, a fetched URL, and a live stream.
Format is identified by inspecting the bytes, not by trusting the file extension or the declared media type. A .jpg that is really a PNG decodes fine, and so does a stream declared application/octet-stream. Declaring the right type still matters in one place: the upload boundary reads it to decide whether the source is video, which is what selects videoMode handling and the 1 GiB buffer cap.
Images
JPEG
.jpg, .jpeg
image/jpeg
PNG
.png
image/png
WebP
.webp
image/webp
HEIF / HEIC
.heic, .heif
image/heic
TIFF
.tif, .tiff
image/tiff
BMP
.bmp
image/bmp
GIF
.gif
image/gif
SVG
.svg
image/svg+xml
ICO
.ico
image/x-icon
SVG is rasterized before inference — a vector drawing is analyzed as the picture it renders to. An animated GIF is decoded as video rather than as one still, so it produces one prediction per frame. An animated WebP is not — it is analyzed as a single still.
Video codecs
H.264
AVC
H.265
HEVC
VP8
VP9
AV1
H.264 is the safe default: it is what cameras, phones, and encoders produce by default, and it is the codec every runtime decodes in hardware where hardware decoding is available. MPEG-1 and MPEG-4 Part 2 are also decoded, for older files.
AV1 has to arrive inside a container — MP4 or WebM. A bare .obu elementary stream is rejected, because the framing cannot be established from those bytes alone; remux it into MP4 first.
A runtime is configured for one decode platform — software, NVIDIA, NVIDIA V4L2, Intel VAAPI, V4L2, or Apple VideoToolbox — rather than detecting what the hardware offers. The list of formats above is the same on every platform; only the throughput differs. A format outside it fails on that platform rather than falling back to a slower path.
Containers
MP4 / QuickTime
.mp4, .mov, .m4v
video/mp4, video/quicktime
Matroska / WebM
.mkv, .webm
video/x-matroska, video/webm
MPEG-TS
.ts, .mts
video/mpegts
AVI
.avi
video/x-msvideo
An MPEG-TS stream may also carry a timed-metadata track alongside the video. The worker reads it to recover the capture time of a relayed camera; any other data track is ignored rather than rejected.
A container carries a codec, and both have to be supported — an MKV of H.264 works, an MKV of a codec that is not in the table above does not. MP4 with H.264 is the combination to reach for when you get to choose.
Live transports
H.264, H.265, VP8, VP9
H.264, H.265, VP8, VP9
H.264, H.265, VP8, VP9 — negotiated with the browser
H.264 is what an IP camera or an encoder publishes unless it has been configured otherwise, and it is the one to pick when the choice is yours.
AV1 is absent from these lists on purpose. It decodes from a file or a fetched URL, but the worker carries no RTP payload format for it, so it cannot arrive over RTSP or WebRTC.
Constraints
Minimum 64 × 64 pixels. Anything smaller is rejected rather than upscaled. There is no maximum: large frames are scaled to what the ability needs.
One video stream per source. The first video stream in a container is the one analyzed; a second is ignored.
Audio is discarded. A file with an audio track is fine — the track is dropped, not an error.
An image group holds up to 16 still images.
When a format is not supported
The source fails with an error naming the type the worker detected, and the prediction stream ends. Nothing partial is returned.
Re-encoding is the fix, and ffmpeg covers most cases:
-an drops the audio track. It is not required — the worker discards audio anyway — but it makes the upload smaller.
Next steps
Source Types — every way to submit a source
Source Options — frame rate, region of interest, motion gating, and component parameters
Last updated