HTTP Streaming Control
The ClientSDK provides powerful streaming capabilities that allow you to receive real-time data from your Aria Gen2 device. You can stream sensor data including camera feeds, IMU data, eye tracking, hand tracking, and machine perception outputs.
Every method on this page — USB, WiFi router and on-device hotspot — streams over the HTTP transport, which is what aria_streaming_viewer uses by default (--transport http). The alternative transport has its own page: see WebRTC Streaming for low-latency peer-to-peer and cross-network streaming.
Prerequisites
- Client SDK installed and virtual environment activated
- Device authenticated with your PC
- Device connected via USB (required to start/stop streaming, even for wireless methods)
Before using any streaming commands, you must authenticate your device by running aria_gen2 auth pair (see Device Authentication). This only needs to be done once per device-PC combination, but all streaming and recording operations will fail without it. You can verify your authentication status at any time with aria_gen2 auth check.
To orchestrate streams across two or more connected devices in one command, see Multi-Device Recording & Streaming.
Overview
Streaming enables you to access real-time data from your device:
- Real-time Data Access: Receive sensor data as it's captured
- Machine Perception: Access on-device VIO (Visual Inertial Odometry), eye gaze, and hand pose data
- Live Visualization: View streaming data in real-time using the streaming viewer
- Custom Processing: Build applications that process streaming data
Available Streaming Profiles
Before starting a streaming session, you can select a streaming profile that defines the sensor configuration, data rates, and resolutions. Project Aria Gen2 offers several pre-defined profiles optimized for streaming:
- mp_streaming_demo: Default streaming profile for visualization - Optimized for real-time visualization with VIO, eye gaze, and hand pose data
- profile9: General purpose streaming profile - Balanced configuration for streaming with lower bandwidth requirements
For detailed specifications of each profile including sensor rates, resolutions, and encoding formats, visit the Profiles Technical Specification page.
Custom Streaming Profiles
In addition to the pre-defined profiles, streaming fully supports custom profiles. You can create your own streaming profile to define custom sensor configurations, data rates, and resolutions tailored to your specific research or application needs.
Using a Custom Profile for Streaming:
aria_gen2 streaming start --json-profile <path_to_custom_profile.json>
For instructions on creating custom profiles, see the Custom Profile Guide.
Custom profiles are especially useful when you need specific sensor combinations or data rates that aren't available in the pre-defined profiles. For example, you might want to stream only RGB and IMU data at higher rates for a specific computer vision application.
Choose Your Streaming Method
Select the streaming method that best fits your use case. The first four all run over the HTTP transport and are documented on this page; WebRTC is a different transport with its own page.
| Method | Transport | Best For | Pros | Cons |
|---|---|---|---|---|
| USB Streaming | HTTP | Extended sessions, highest quality | Most reliable, no thermal issues | Requires cable connection |
| WiFi Router Streaming | HTTP | Untethered development, mobility | Wireless freedom, good for demos | Thermal concerns, requires network |
| On-Device Hotspot Streaming | HTTP | Field work, no network available | No external network needed | Highest thermal impact, limited duration |
| Remote Server Streaming | HTTP | Dedicated processing server, distributed systems | Process on powerful remote machine | Requires network setup, TLS certificates |
| WebRTC Streaming | WebRTC | Low-latency P2P; cross-network via signaling | Direct P2P on same network; NAT traversal across networks; can record to VRS while streaming | Image timestamps are host receive time |
New to streaming? Start with USB Streaming - it's the simplest and most reliable method.
Start Order and Streaming Certificates
Over HTTP, start streaming on the device first, then open the viewer:
aria_gen2 streaming start # terminal 1
aria_streaming_viewer --real-time --interpolate # terminal 2
The reason is certificate handling, not connection retries. HTTP streaming is mutually authenticated with TLS: the device holds a publisher certificate, and the host holds the matching subscriber certificate and root CA in ~/.aria/streaming-certs/persistent/. When aria_gen2 streaming start runs without --streaming-cert-name, it deletes those host files, generates a new root CA and key pairs in their place, and installs the new publisher certificate on the device. aria_streaming_viewer reads the host files once, when it starts, and holds the resulting TLS context for its lifetime — so a viewer opened first is still verifying against the previous root CA, and the device's connection fails the handshake.
Making the Order Irrelevant
Give streaming start a certificate that is already installed, so it does not mint a new one. Install one once with aria_gen2 streaming install-certs, note the cert name it prints, and pass that name on every subsequent start:
# Once per host + device pair. Prints the cert name:
# [AriaGen2SDK:Device][INFO]: Request installing streaming certs on device: cert_1769712774692532015
aria_gen2 streaming install-certs
# From then on these two can be run in either order:
aria_streaming_viewer --real-time --interpolate
aria_gen2 streaming start --streaming-cert-name cert_1769712774692532015
With --streaming-cert-name naming an already-installed certificate, streaming start installs nothing, the files the viewer read at startup stay valid, and the device retries the connection until the viewer is listening — so either order works. The cert name survives across runs, so this is a one-time setup.
--local-certs-dir has the same effect: pointed at a directory that already holds certificates, streaming start adopts the installed cert instead of generating one. Use the viewer's own directory, since aria_streaming_viewer has no certificate flag of its own and always reads ~/.aria/streaming-certs/persistent/:
aria_gen2 streaming start --local-certs-dir ~/.aria/streaming-certs/persistent
The Python API behaves the same way — device.start_streaming() regenerates unless the HttpStreamingConfig you pass to set_streaming_config() sets streaming_cert_name (or security_options.local_certs_root_path).
WebRTC does not install streaming certificates on the device, so aria_gen2 streaming webrtc start and aria_streaming_viewer --transport webrtc can always be started in either order. The one certificate it can involve is the signaling server's own, when the signaling channel runs over TLS — that is a trust anchor you point each peer at, not something installed per device, and it does not affect the start order. See Trusting a TLS signaling server.
USB Streaming
Stream data over USB connection for maximum bandwidth and reliability. This is the recommended method for getting started and for extended streaming sessions.
When to Use USB Streaming
- Extended sessions: No thermal concerns - stream as long as you need
- Highest quality: Maximum bandwidth and lowest latency
- Simple setup: Just connect and stream, no network configuration
- Development: Best for testing and development work
Quick Start
Run aria_gen2 streaming start first and aria_streaming_viewer second, in two terminals. Pinning an already-installed certificate with --streaming-cert-name lets you run them in either order — see Start Order and Streaming Certificates for more details.
# 1. Connect device via USB and verify connection
aria_gen2 device list
# 2. Start streaming (do this before opening the viewer)
aria_gen2 streaming start
# 3. In another terminal, visualize the stream
aria_streaming_viewer --real-time --interpolate --rerun-memory-limit 4GB
# 4. When done, stop streaming
aria_gen2 streaming stop
USB Streaming Details
Requirements:
- Device connected via USB
- Device authenticated (see Device Authentication guide)
- High-quality USB 3.0+ cable recommended
Command:
aria_gen2 streaming start
Default Profile:
The mp_streaming_demo profile is used by default, which provides smooth visualization with VIO, eye gaze, and hand pose data. See the Profiles Technical Specification for detailed sensor configurations and frame rates for all available profiles.
USB Troubleshooting
Device Not Found:
# Check device connectivity
aria_gen2 device list
# If not found, ensure device is authenticated
aria_gen2 auth check
Common Issues:
- USB cable: Try a different high-quality USB 3.0+ cable
- USB port: Try a different USB port on your computer
- Authentication: Run
aria_gen2 auth pairif device is not authenticated - Recording active: Stop any active recording with
aria_gen2 recording stop
Wireless Streaming
Wireless streaming allows you to stream data from your Aria Gen2 device over WiFi, eliminating the need for a USB cable. This is useful for untethered development, demos, and testing in various environments.
All device controls, including starting and stopping streaming, require a USB connection. For wireless streaming:
- Connect the device via USB to start streaming
- Unplug the USB cable after streaming has started
- Plug the device back in via USB when you need to stop streaming
Wireless streaming generates more heat than USB streaming due to WiFi radio activity. You must configure message batching using the --batch-period-ms option to manage thermal performance and prevent the device from overheating (thermal throttle at 42°C).
Message Batching
The --batch-period-ms option controls how messages are batched before being sent from the device. This reduces transmission overhead and optimizes thermal performance.
How it works:
- Messages are collected and batched over the specified period (in milliseconds)
- Batched messages are sent together, reducing WiFi transmission overhead
- Higher batch periods = better thermal performance but increased latency
- The batch period represents the worst-case delay for live streaming
Trade-off:
| Batch Period | Thermal Performance | Latency | Use Case |
|---|---|---|---|
| 100ms | Poor (near thermal limit) | Low | Short demos, testing |
| 200-400ms | Moderate | Medium | General wireless use |
| 500-800ms | Good | High | Extended wireless sessions |
WiFi Router Streaming
Stream data from Aria devices connected to the same WiFi network as your development machine.
When to Use WiFi Router Streaming
- Untethered development: Move freely without cable constraints
- Demos: Show live streaming without visible cables
- Multi-room testing: Stream while moving between areas
- Sessions > 30 minutes: With appropriate batch period settings
Prerequisites
- Same network: Both Aria device and computer must be on the same WiFi network
- Network ports: Ensure streaming ports are accessible on your network (default port: 6768)
- Device connected: Connect Aria to your WiFi network via the Companion App or via CLI
Quick Start
# 1. Connect device via USB first for initial setup
aria_gen2 device list
# 2. Verify device is on WiFi (check Companion App)
# 3. Start streaming with batch period for thermal management
# Do this before opening the viewer.
# Use 200ms batch period for a balance of latency and thermal performance
aria_gen2 streaming start --batch-period-ms 200 --interface wifi_sta
# 4. Unplug the USB cable - streaming will continue over WiFi
# 5. In another terminal, visualize the stream
aria_streaming_viewer --real-time --interpolate --rerun-memory-limit 4GB
# 6. When done, plug the USB cable back in, then stop streaming
aria_gen2 streaming stop
Recommended Batch Periods for WiFi Router
These are preliminary testing results and may vary across environments and devices.
| Environment | Batch Period | Notes |
|---|---|---|
| Cool environment (below 25°C) | --batch-period-ms 100 | Near thermal limit, monitor closely |
| Normal room temperature | --batch-period-ms 200 | Recommended starting point |
| Warm environment (above 28°C) | --batch-period-ms 400 | More conservative for thermal safety |
With --batch-period-ms 100, we have observed the device nearly reaching thermal throttle (42°C) during WiFi router streaming. Actual thermal behavior depends on your operating environment temperature. Start with higher batch periods and reduce if you need lower latency.
On-Device Hotspot Streaming
Connect directly to Aria's built-in WiFi hotspot for standalone wireless streaming without requiring external network infrastructure.
When to Use On-Device Hotspot Streaming
- Field work: No external WiFi network available
- Quick demos: Simple setup without network configuration
- Isolated testing: When you can't access local networks
- Short sessions only: Due to high thermal impact
On-device hotspot streaming generates significant heat because the device acts as both a WiFi access point AND performs streaming simultaneously.
Even with aggressive batching (800ms), the device will overheat during extended use.
Recommendations:
- Do NOT use for sessions longer than 20 minutes
- Take breaks to let the device cool down
- Monitor device temperature closely
- Consider USB streaming for longer sessions
Prerequisites
- Enable hotspot: Enable the hotspot feature on Aria via the Companion App
- Connect computer: Connect your development machine to Aria's WiFi hotspot
Quick Start
# 1. Enable hotspot on Aria device via Companion App or CLI:
# aria_gen2 device hotspot start
# 2. Connect device via USB to start streaming
aria_gen2 device list
# 3. Connect your computer to Aria's WiFi hotspot
# 4. Start streaming with aggressive batching for thermal management
# Do this before opening the viewer.
# 800ms batch period is recommended to extend usable time
aria_gen2 streaming start --batch-period-ms 800 --interface --wifi_sap
# 5. Unplug the USB cable - streaming will continue over WiFi hotspot
# 6. In another terminal, visualize the stream
aria_streaming_viewer --real-time --interpolate --rerun-memory-limit 4GB
# 7. When done, plug the USB cable back in, then stop streaming
# Stop before 20 minutes to prevent overheating
aria_gen2 streaming stop
Recommended Settings for Hotspot Streaming
These are preliminary testing results and may vary across environments and devices.
| Session Length | Batch Period | Notes |
|---|---|---|
| Under 10 minutes | --batch-period-ms 500 | Short demo, higher risk |
| 10-20 minutes | --batch-period-ms 800 | Maximum recommended duration |
| Over 20 minutes | Not recommended | Use USB streaming instead |
Hotspot Streaming Limitations
| Limitation | Impact | Mitigation |
|---|---|---|
| High thermal load | Device overheats | Limit to 20 min sessions max |
| Battery drain | Faster battery consumption | Keep device charged |
| Higher latency | 500-800ms delay | Not suitable for real-time critical applications |
| Single client | Only one device can connect | Use WiFi router for multi-client scenarios |
If you encounter issues with wireless streaming, see the Wireless Streaming Troubleshooting Guide for common solutions.
Streaming Commands Reference
For complete streaming command documentation, including all available options, see the CLI Reference - Streaming Commands.
Quick Reference:
# Start streaming (USB)
aria_gen2 streaming start
# Start streaming (WiFi with batch period)
aria_gen2 streaming start --interface wifi_sta --batch-period-ms 200
# Stop streaming
aria_gen2 streaming stop
Visualize Streaming Data
Run aria_gen2 streaming start first and aria_streaming_viewer second, in two terminals. Pinning an already-installed certificate with --streaming-cert-name lets you run them in either order — see Start Order and Streaming Certificates for more details.
Open the streaming viewer in a separate terminal while streaming is active:
aria_streaming_viewer --real-time --interpolate
The viewer shows:
- Live camera feeds (RGB, SLAM, eye tracking)
- Machine perception data (VIO trajectory, eye gaze, hand pose)
- Sensor readings (IMU, magnetometer, etc.)
- Performance metrics (frame rates, latency)
Custom Layout with a Rerun Blueprint
By default the viewer generates its layout from the device calibration. A Rerun blueprint — a .rbl file — replaces that layout with a saved arrangement of views, panels, and visibility settings, so you can keep a workspace you like across sessions.
The SDK ships one ready-made blueprint, aria_video_focused_rerun_0.33.rbl: a video-focused layout with the RGB camera at the center, the SLAM cameras arranged around it, and eye gaze overlaid on the video streams. Export it together with the sample scripts:
python -m aria.extract_sdk_samples --output ~/Downloads/
There are three ways to load it. All three work the same on the HTTP and WebRTC transports.
1. The --blueprint flag. Pass the file when starting the viewer and it is applied before the first frame arrives:
aria_streaming_viewer --real-time --interpolate \
--blueprint ~/Downloads/projectaria_client_sdk_samples_gen2/aria_video_focused_rerun_0.33.rbl
The viewer checks that the path exists and exits with an error if it does not. While --blueprint is set, the auto-generated layout is skipped entirely — the blueprint is the layout.
2. Drag and drop. With the Rerun window already open, drag the .rbl from your file manager onto the window. The live stream keeps running; only the layout changes.
3. The Rerun menu. In the Rerun window, open the menu from the button at the top-left of the viewer and choose Open file…, then pick the .rbl. Rerun's file dialog accepts .rbl blueprints alongside .rrd recordings.
To make your own, arrange the views however you like in a running viewer, then use the same menu's Save blueprint… entry — "Save the current viewer setup as a Rerun blueprint file (.rbl)" — and pass the result back with --blueprint.
The .rbl format tracks the Rerun release, which is why the shipped file carries rerun_0.33 in its name — the Rerun a rerun-sdk ~=0.33.0 install brings in. Rerun migrates older blueprints forward when it opens them, but a blueprint saved by a newer Rerun than the one you are running may load with missing or misplaced views. If a blueprint does not look right, re-save it from the Rerun version you are running, or drop --blueprint to fall back to the auto-generated layout.
Stopping the Viewer
This applies to both the HTTP and WebRTC transports. Press CTRL+C, or simply close the Rerun window — the viewer shuts the receiver down and exits on its own, so it does not keep receiving and decoding into a window that is no longer there. Pass --no-exit-on-viewer-close to keep the session running after the window is closed.
Example Visualization
Streaming vs Recording
Choose the right tool for your needs:
| Feature | Streaming | Recording |
|---|---|---|
| Real-time Access | Yes | No |
| Data Saved on Device | No | Yes |
| Machine Perception | VIO, Eye Gaze, Hand Pose | VIO, Eye Gaze, Hand Pose |
| Connection Required | During capture | No |
| Use Case | Live monitoring, real-time processing | Data collection for offline analysis |
| Best For | Development, live demos, debugging | Research data collection, post-processing |
- Use streaming when you need to see data in real-time or process it live
- Use recording when you need to save data for later analysis or offline processing
Best Practices
Choosing the Right Method
- Development & Testing: Use USB streaming for reliability and ease
- Demos & Monitoring: Use USB streaming with long cables for mobility during short sessions
- Field Work: Use hotspot streaming when no network is available
- Long Sessions: Always use USB streaming (no thermal concerns)
General Tips
- Start Simple: Begin with USB streaming to verify everything works
- Test First: Run a short streaming session before important captures
- Monitor Temperature: Watch for device heating during wireless streaming
- Keep Device Charged: Wireless streaming consumes more battery
- Close Applications: Free up system resources for better performance
- Use Quality Cables: USB 3.0+ cables for best USB streaming performance
Thermal Management
- If device gets hot: Stop streaming and let it cool before continuing
- Extended sessions: Always prefer USB streaming
Next Steps
- Switch transport with WebRTC Streaming for low-latency P2P and cross-network sessions
- Learn about Recording to save data for offline analysis
- Check out Streaming Examples to build custom streaming applications
- Visit the CLI Technical Specs for complete command reference