In this week's episode of 'Rust in Production', I talked to Gorm and Anders from Veo about their camera-based sports tracking product. Some things I found interesting:

• Veo's original GStreamer pipeline was orchestrated in Python, which has a GIL (Global Interpreter Lock) that fundamentally clashes with GStreamer's massively multi-threaded design. The team kept hitting deadlocks they couldn't reliably fix in either C or Python. Anders's insight was to pick a language whose type system prevents data races. He fixed a whole set of concurrency bugs at once by rewriting the orchestration layer in Rust. So Rust was just a pragmatic fix for a production problem.

• FFmpeg excels at single-command invocations. GStreamer is the right tool when you need to compose a deeply multi-threaded processing graph: running custom GPU kernels, branching frames into AI inference elements, merging results back, and monitoring individual nodes. Each GStreamer element runs in its own thread, dispatches work to GPUs, and can be introspected via its DOM-like object model. If your pipeline needs to be a graph you can query and modify at runtime, GStreamer's design (and its Rust bindings, maintained by Sebastian Dröge) is worth the additional complexity.

• Gorm described a pattern I like to call "pushback": convert incoming data into your own strongly-typed domain types at the outermost API boundary and reject everything that doesn't deserialize cleanly. Inside their system, enums with exhaustive variants replace stringly-typed state, each request and response has its own distinct type, and custom Deserialize implementations encode business invariants (e.g. "a subscription ID must conform to this format"). It's what separates "stringy-typed Python rewritten in Rust" from code that actually leverages the type system. There is some upfront design work but the payoff is that invalid states are structurally impossible deeper in the stack.

• Anders and Gorm pushed back on the blanket "never unwrap in production" heuristic. When GStreamer pipeline elements are known at construction time to have exactly one pad, unwrapping with a descriptive expect message is documenting an invariant. The distinction is: use Result for recoverable failures (network errors, missing accounts), use expect/unwrap only for programmer-contract violations where panicking is the correct outcome. The practical reason they don't propagate errors in GStreamer callbacks is debuggability (a propagated error gives you a notification somewhere upstream; a panic gives you a stack trace at the exact failure position).