Orbital Video

From 2013 to 2014, while working at Flexbricks, I was deeply involved in a startup called AngularMedia. Later it became OrbitalVideo, then Metepa, and today the product is known as Panora 360.

This was a true from-scratch effort. The overall product, workflow, and tooling were being built from the ground up rather than added onto an existing platform.

It was one of the most technically unusual projects I have ever worked on. The idea was to turn video into an interactive experience where the viewer could switch angles, rotate around the scene, and control how the moment was watched instead of passively consuming a single camera feed.

A short showcase clip from the Panora project.

What the product was

The platform is built around interactive multi-camera video. Several cameras are placed around a scene, their streams are processed into a single interactive asset, and that result is then published to the web or mobile apps for end users.

Core ideas:

  • capture a scene with 3 to 32 cameras
  • calibrate and align the camera images automatically
  • synchronize video tracks so interaction feels natural
  • publish the result for web, mobile, and other client players
  • let the viewer control rotation, zoom, and movement in real time

The product supports anything from inexpensive webcams to professional studio cameras, optional background removal, cloud-based storage and delivery, and easy embedding into existing websites and apps.

In practical terms, the system was trying to make immersive video feel immediate. Instead of rendering a synthetic 3D world, it used real recorded camera streams and gave the user control over which angle to see at any moment.

How it worked in practice

The core challenge was that the experience depended on many separate video streams behaving like one coherent video object.

Multiple cameras were positioned around the subject. Their footage had to be recorded with matching settings, processed into a special container, and then played in a way that allowed rapid switching between viewpoints. If synchronization drifted or random access was slow, the illusion broke immediately. Even small timing errors became visible during fast movement.

That meant the system was not just about video playback. It depended on several hard problems being solved together:

  • camera setup and calibration
  • synchronized capture
  • efficient multi-stream storage
  • low-latency seeking and camera switching
  • playback on multiple client platforms

My role

I was the lead and only desktop application developer in the startup.

My area was the desktop tooling that made the production workflow possible. I built all of my applications in the project from scratch, rather than inheriting or extending existing codebases. That included three Windows desktop applications, all delivered on time, using C# and .NET Framework 4.5:

  • a Windows player for the custom interactive video format
  • a recording control application for up to 32 cameras
  • an editor/transcoder for cutting and reprocessing recorded files

I also built a separate macOS player for the same interactive format. For that, I had to learn Objective-C and develop a native desktop application.

Other people on the team worked on the iOS app, Android app, web player, and the hardware and server side.

Technologies used

C# (.NET Framework 4.5), Objective-C, WPF, VLC, FFMPEG

The Windows player

The first major application I built was a Windows player that could open a special video file containing many streams. The user could switch between them to change cameras, effectively swiping around the scene while the video kept playing.

The stack for that application was built around the same core technologies listed above, plus the surrounding media pipeline.

The difficult part was not only decoding video. It was designing a format and access pattern that made interactive navigation feel smooth.

With 16 separate 4K streams, file sizes exploded very quickly. One minute of video could take roughly 3 to 4 GB. That forced us to do many iterations on the file structure and data layout. We needed fast seek performance so users could scrub through the file easily, but we also had to keep the storage cost below something absurd.

We spent a lot of time tuning the media pipeline, especially around keyframe placement in FFMPEG. The balance was delicate:

  • too many keyframes made files enormous
  • too few keyframes made seeking and angle switching feel bad
  • imperfect structure in the container made random access too slow

Getting that tradeoff right took repeated optimization passes, but it was essential for making the player feel like a product instead of a technical demo.

I later built a macOS version of the player as well. Surprisingly, seeking on the same files worked up to 10 times faster there than in the Windows version, and the final macOS player ended up feeling even better in practice.

The recording control application

The second application was used to control recording.

It displayed up to 32 camera feeds at once. Through it, operators could configure recording parameters for each camera, adjust them individually, verify that every camera was set correctly, and then start and monitor recording across the full setup.

This application was heavily multithreaded.

The hardest problem there was synchronized capture. In theory, you want every camera to start recording at the same moment. In practice, that is much harder than it sounds. We saw frame timing differences of up to about 100 ms between cameras, which produced visible jumps back and forth during active motion.

That kind of error was enough to damage the whole interactive effect. After a lot of experimentation, we ended up enforcing stricter uniformity in camera configuration and startup behavior. When cameras were configured identically and started together under controlled conditions, synchronization became acceptable enough for the product workflow.

It was a very real example of where software quality depended heavily on hardware behavior and operational discipline.

The editor and transcoder

After that, I built a third application for opening and editing the multi-stream files.

This tool allowed users to:

  • open a file containing all streams
  • play it back
  • cut unusable segments
  • transcode the result into other resolutions

It was built on the same desktop stack as the other tools in the project.

Compared with the recording tool, the editor looked simpler from the outside, but it still had to deal with the same underlying complexity: many related video streams had to remain usable as one artifact throughout playback, trimming, and re-encoding.

Why the project was memorable

All three desktop applications were completed and delivered on schedule. The team was friendly.

What made the project special was the combination of product ambition and low-level engineering problems. It touched UI, media playback, multithreading, file format design, encoding tradeoffs, synchronization issues, and real-world hardware limitations all at once.

Unfortunately, the startup was eventually sold and changed hands more than once. Even so, it was an excellent experience and one of the projects I still remember as genuinely exciting.