FAQ
🚧 Documentation is under development
The Video Stitching for Embedded Systems guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
FAQ
This page answers common questions about RidgeRun's Video Stitching for Embedded Systems.
General
1. Is my use case a good match for RidgeRun's Video Stitching?
Video Stitching is intended for fixed multi-camera systems where overlapping camera views are combined into a larger panorama. Typical applications include panoramic video, surveillance, robotics, and autonomous systems.
The cameras must remain in the same relative positions used during calibration and adjacent views need enough overlap to be aligned and blended correctly.
Systems where cameras move independently after calibration, or where there is little or no overlap between views, are not a good fit.
See Configuration and Calibration for camera setup requirements.
2. Does it perform image quality or color transfer?
The Stitcher performs geometric transformation and blending, but it does not perform automatic color transfer, exposure matching, or white-balance matching between cameras.
For best results, the cameras should have similar image settings and image quality before stitching. If color matching is required, it can be performed elsewhere in the pipeline. RidgeRun also provides GStreamer Color Transfer for applications that require color consistency between streams.
Performance
3. How much GPU is used by RidgeRun's Video Stitching?
GPU usage depends on the platform, backend, resolution, and number of cameras.
For the three-camera 1920x1080 maximum-throughput tests, average device-wide GPU usage was approximately 43-48% on DragonWing and 28-55% on Jetson AGX Orin, depending on the backend and clock configuration. GPU utilization was not available for the i.MX95 tests.
These are whole-device measurements taken while running at maximum throughput, not a pipeline limited to 30 FPS.
See Performance - Resource Usage for the complete results.
4. How much latency does it add?
Latency depends mainly on the platform, backend, resolution, and number of cameras.
For three 1920x1080 inputs, the measured median Stitcher latency was approximately:
| Platform | Configuration | Median latency |
|---|---|---|
| DragonWing | rrstitcher / OpenGL
|
54.6 ms |
| DragonWing | rrglstitcher / OpenGL
|
41.1 ms |
| i.MX95 | rrstitcher / OpenGL
|
221.1 ms |
| i.MX95 | rrglstitcher / OpenGL
|
86.0 ms |
| Jetson AGX Orin | rrstitcher / CUDA
|
22.9 ms |
| Jetson AGX Orin | rrstitcher / OpenGL
|
23.7 ms |
| Jetson AGX Orin | rrglstitcher / OpenGL
|
18.8 ms |
The measurements cover the time from the Stitcher input to its output. Camera capture, decoding, display, and other pipeline stages are not included.
Camera synchronization can add additional delay. If streams arrive out of sync, waiting for corresponding frames may add approximately one frame period to the pipeline.
See Performance - Latency for measurements with different camera counts.
5. What is the limit on the number of cameras?
The Stitcher supports up to 16 calibrated inputs. The practical limit is normally lower and depends on the platform, input resolution, requested framerate, backend, and panorama size.
Performance has been characterized with 2, 3, 4, and 6 inputs at 720p, 1080p, and 4K. The 30 FPS Capability Summary shows the largest tested configuration that reached 30 FPS on each platform.
The 16-camera value is an element limit and should not be interpreted as a guarantee that every platform can process 16 cameras in real time.
Cameras and Calibration
6. What cameras are supported?
The Stitcher is not tied to a particular camera sensor or capture interface. A camera can be used as long as its stream can be brought into GStreamer and converted to the format required by the selected element.
rrstitcher accepts RGBA system-memory buffers. rrglstitcher accepts RGBA GstGLMemory buffers with 2D textures.
All inputs in a Stitcher instance must use the same resolution and framerate.
This allows the Stitcher to be integrated with camera capture sources, decoded video files, and other GStreamer video sources.
7. What is the recommended camera layout?
Adjacent cameras should have overlapping fields of view with enough common image content for calibration and blending.
The cameras should be mounted rigidly so their relative positions do not change after calibration. Keeping cameras physically close to each other also helps reduce parallax.
There is no single overlap percentage that applies to every camera arrangement. The required overlap depends on the lens field of view, camera placement, scene depth, and intended panorama.
For calibration, the overlap regions should contain well-lit and distinctive image features. More information is available in Configuration and Calibration.
8. Does the solution require hardware synchronization?
Hardware synchronization is not required by the Stitcher itself, but synchronized capture is recommended for scenes containing motion.
If the cameras capture the scene at different times, moving objects can appear at different positions in the overlapping views. This can produce visible artifacts around the stitching regions even when the geometric calibration is correct.
For static scenes or applications where small timing differences are acceptable, software-timestamped cameras may be sufficient. Applications with significant motion should use synchronized cameras whenever possible.
9. How is the stitching calibrated?
The Stitcher uses a calibration JSON file that describes the geometric relationship between the camera views.
For rectilinear stitching, calibration primarily produces the homographies used to align the cameras. Fisheye configurations additionally require projection parameters to convert the input images to the appropriate projection before alignment.
RidgeRun provides existing tools for homography estimation, lens undistortion, and fisheye projection calibration.
See Configuration and Calibration for the complete workflow.
Integration and Runtime
10. How is it used in an application?
The Stitcher is available through a C++ API or as a GStreamer plugin with two elements:
rrstitcherfor system-memory pipelines.rrglstitcherfor OpenGL pipelines usingGstGLMemory.
Camera capture, video decoding, conversion, stitching, display, encoding, streaming, or other processing can be connected in the same GStreamer pipeline.
See GStreamer Usage for supported caps and pipeline examples.
11. How can it be integrated with AI?
The stitched panorama is a regular GStreamer video stream and can be connected to downstream inference or computer-vision processing.
For applications that need inference over the complete panorama, the AI stage can run after the Stitcher:
Cameras → Stitcher → AI / Computer Vision → Application
It is also possible to process individual camera streams before stitching when the application needs per-camera inference.
The Stitcher itself does not provide an AI inference engine; the inference stage is integrated separately according to the target platform and application.
12. What happens during runtime failures?
The behavior depends on the type of failure:
- Camera disconnect or EOS: a missing input can stop the stitched output because all calibrated camera streams are expected.
- Timestamp drift: the views may become temporally misaligned, producing artifacts around moving objects.
- Invalid calibration: the element can fail during configuration or when creating the required sink pads.
- Insufficient processing performance: the pipeline may not sustain the requested framerate and upstream queues or downstream elements can become a bottleneck.
- Input resolution or framerate changes: all inputs must negotiate matching caps. If one camera changes mode, the pipeline may need to be renegotiated or restarted.
See GStreamer Usage - Troubleshooting for common configuration and runtime issues.
13. Where can I see example outputs?
See the Examples page for reference pipelines, camera arrangements, and stitched outputs.