Osprey
Dynamic, multi-stream video-analytics library built on NVIDIA DeepStream 8.0
— installable with pip, run bare-metal on the host.
import osprey.server as osprey
# Configure the model + tracker, then start the server (its own process).
osprey.configure(gie_config="/models/gie.txt", tracker="NvSORT")
osprey.serve() # returns once the server is healthy
osprey.add_stream("rtsp://camera/stream", stream_id="cam1")
# Write your analytics with the client — no GStreamer/pyds knowledge needed.
from osprey.client import DeepStreamClient, FrameData
class VehicleCounter(DeepStreamClient):
def _process_frame(self, frame: FrameData):
for obj in frame.objects:
self._draw_object(frame.surface, obj) # box + tracking label
VehicleCounter().start() # serves RTSP for every discovered stream
One file: configure → serve runs the DeepStream inference pipeline + REST
control plane in a separate process, while your DeepStreamClient runs the
analytics and serves annotated RTSP. Prefer the CLI (osprey-server /
osprey-client) for a production two-service deployment — see below.
What Osprey installs for you
Osprey is a Python layer on top of the DeepStream SDK. The GStreamer plugins
(nvstreammux, nvinfer, nvtracker, nvunixfdsink/src, nvdsosd, …) and the
pyds bindings are not on PyPI. Rather than make you set that up by hand,
Osprey ships an end-to-end bootstrap that installs the full DeepStream 8.0
stack bare-metal — so a fresh Ubuntu 24.04 box becomes a working Osprey host.
Target platform (DeepStream 8.0, x86/dGPU):
| Component | Version |
|---|---|
| OS | Ubuntu 24.04 |
| NVIDIA driver | R570.133.20 |
| CUDA | 12.8 |
| TensorRT | 10.9.0.34 |
| cuDNN | 9.7.1 |
| GStreamer | 1.24.2 |
Quick start (end-to-end)
# 1. Install the Python package (pure-Python + precompiled parser .so)
pip install ospreyai
# 2. Bootstrap the DeepStream stack bare-metal (needs root; ~one-time)
sudo osprey-bootstrap
# 3a. Run as two services (production)
osprey-server # FastAPI control plane on :8000 (POST /api/v1/add …)
osprey-client # discovers sockets, serves RTSP per stream
# 3b. …or a single Python file (see the example at the top)
python3 my_app.py # configure() → serve() → your DeepStreamClient
Configuration is either programmatic (osprey.configure(...), shown above)
or via environment variables (GIE_0_CONFIG, DS_TRACKER, DS_MODEL_WIDTH
…) for the osprey-server CLI. See examples/ for a runnable
single-file app.
osprey-bootstrap runs five stages (each also runnable on its own; see below).
If the NVIDIA driver is (re)installed in stage 10, reboot before running the
pipeline.
Bootstrap stages
| Stage | Does | Mirrors |
|---|---|---|
00_system_deps |
apt build toolchain + GStreamer runtime | image apt layer |
10_cuda_trt_cudnn |
driver R570 + CUDA 12.8 + cuDNN 9.7 + TensorRT 10.9 | base image |
20_deepstream_sdk |
DeepStream 8.0 SDK .deb from NGC → GStreamer plugins |
base image |
30_pyds |
build + install pyds for your Python |
image bindings build |
40_native_libs |
verify shipped parsers/serializer; TRT-plugin patch is manual | image compile step |
Useful toggles (read by the scripts, pass straight through):
sudo OSPREY_ASSUME_CUDA=1 osprey-bootstrap # already have driver/CUDA/TRT/cuDNN
sudo OSPREY_ONLY=30 osprey-bootstrap # run a single stage (e.g. just pyds)
sudo OSPREY_DS_VERSION=8.0 osprey-bootstrap # override DeepStream version
Security note. Osprey does not auto-download or overwrite your system TensorRT library. Some ONNX models embed end-to-end NMS (
EfficientNMS_TRT) and need a patchedlibnvinfer_plugin; because that means replacing a system library with an external binary, Osprey leaves it as a deliberate manual step (see the referencepatch_libnvinfer.sh). Standard YOLO/RT-DETR detection and segmentation need no patch.
Python environment — gi + pyds must share the interpreter
Osprey needs three pieces in the same Python interpreter:
| Piece | Comes from | Lives in |
|---|---|---|
ospreyai |
pip |
wherever you pip install |
gi (PyGObject) |
apt (python3-gi) |
system Python |
pyds |
built by osprey-bootstrap |
the Python active during bootstrap |
Because gi and pyds are not PyPI packages and live in system Python, a
plain virtualenv can't see them — that's the usual cause of
ModuleNotFoundError: No module named 'gi' (or 'pyds'). Use one of:
# A) No venv (simplest) — install next to system gi/pyds
pip install --break-system-packages ospreyai
# B) A venv that can see system packages (any path)
python3 -m venv --system-site-packages ~/osprey-venv
source ~/osprey-venv/bin/activate
pip install ospreyai
A plain python3 -m venv (without --system-site-packages) will not
work — it hides system gi/pyds. The venv's Python must also be the same
minor version as system Python (3.12 on Ubuntu 24.04).
Verify any interpreter with:
osprey-doctor # checks gi + pyds + osprey + plugins, prints the fix if not
Already have DeepStream 8.0?
Skip the bootstrap and just use the library:
pip install ospreyai
python3 -c "from osprey.client import DeepStreamClient; print('ok')"
The bundled native libraries (osprey/**/lib/*.so) are compiled for
DeepStream 8.0 / CUDA 12.8 and match the platform table above.
CLIs
| Command | Purpose |
|---|---|
osprey-bootstrap |
Bare-metal end-to-end DeepStream install (root) |
osprey-doctor |
Check gi + pyds + osprey + plugins in the current interpreter |
osprey-server |
FastAPI control plane — add/remove streams at runtime |
osprey-client |
Discover sockets, run app logic, serve RTSP |
osprey-build-engines |
Pre-build TensorRT engines from GIE_N_CONFIG |
Testing
To exercise the library in a GPU DeepStream container (install → REST add →
GPU inference → RTSP output), see docs/TESTING.md. It's the
exact runbook used to validate Osprey end-to-end.
Metadata
Release files for ospreyai 0.1.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| ospreyai-0.1.4-cp312-cp312-manylinux_2_39_x86_64.whl | CPython 3.12 | CPython 3.12 | Linux glibc 2.39+ x86-64 | Details |
Release files / ospreyai-0.1.4-cp312-cp312-manylinux_2_39_x86_64.whl
| Download URL | ospreyai-0.1.4-cp312-cp312-manylinux_2_39_x86_64.whl |
|---|---|
| Size | 109.8 kB |
| Tags | CPython 3.12 Linux glibc 2.39+ x86-64 |
|
SHA-256 checksum How to use checksums |
c84c405d2da80669807508f0f59fde5a8291304123c8a05033a58988f2bb1991
|
|
BLAKE2b-256 checksum How to use checksums |
6fe54650ce07ec93052e8733a85baf86f100d256c2279c49111a4a1e435c7a2b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.12.3
|
Security for ospreyai 0.1.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.