STREAMAX / DEVELOPER ECOSYSTEM
Develop on Streamax’s three-layer architecture: a shared SDK foundation, an industry baseline and your own application. Explore the interfaces, frameworks and integration paths behind the model.
For device developers, platform teams and solution partners.
APIs to build with
Development demos
Reusable components
FAQ cases
Resource availability depends on the device and SDK release.
01 / THE ARCHITECTURE
Keep the low-level complexity in the platform. Reuse the industry capabilities you need. Put your development effort into the features that make your solution different.
CUSTOMER CUSTOMIZATION
Build custom applications, alarms, workflows and private protocols on top of the SDK and industry baseline. Connect peripherals through serial, network and CAN interfaces.
Your team develops the application. Streamax supplies the underlying platform and development support.
INDUSTRY BASELINE
Reuse shared industry components, standard features and business-event handling. The architecture supports freight, bus and taxi baselines, with resources and configurations tailored to each industry.
The available baseline is confirmed for your device and project during evaluation.
SDK & CORE PLATFORM
Standard C, Android and web interfaces connect applications to audio/video, AI, storage, networking, device management and hardware adaptation.
The hardware adaptation layer handles chipset, wireless modules, AD modules and GPS.
READING THE THREE LAYERS
The Foundation supplies shared device capabilities; the Industry layer turns those capabilities into reusable industry behavior; the Customization layer adds a customer's interfaces, workflows, alarms and protocols. The foundation is the SDK Layer and includes standard products, the basic platform and hardware adaptation.
These are layers of software responsibility and reuse. They do not represent three separate devices or three network hops. The detailed interface layer includes Standard C APIs, Android APIs and Web APIs.
DIAGRAM 01 / INSIDE THE FOUNDATION
The SDK foundation combines application interfaces, reusable services and underlying frameworks. Each level builds on the capabilities beneath it.
BASIC PLATFORM
MANAGERS, SUBSYSTEMS & SERVICES
File system, recordings, black-box data, picture files and hot-plug handling.
Serial port, CAN, digital I/O and GPS access.
4G, Ethernet, Wi-Fi and Bluetooth connectivity.
Shared memory and message communication. IPC here describes software-process communication.
Encoding, decoding and audio/video inputs and outputs.
Algorithm input, middleware and signal-analysis plug-ins.
The shared framework for device and application parameters.
The logging framework shown as a shared platform service.
Common library components shared across the foundation.
WHY THE SEPARATION MATTERS
A hardware difference belongs at the adaptation boundary; a shared recording or networking function belongs in the platform; a customer workflow belongs in the customization layer. This is an architectural reading of the model, not a promise that every change can be isolated automatically.
WHAT STILL NEEDS CONFIRMATION
Confirm the supported interfaces, versions, resources and dependencies for the chosen hardware before implementation. Review API signatures, compatibility requirements and device support with the project team.
DIAGRAM 02 / INDUSTRY REUSE
The bus baseline below illustrates how shared platform capabilities become industry functions. Freight and taxi projects use their own applicable baselines, with modules confirmed during project evaluation.
Bus dispatch and active-safety protocols.
Event-linkage priority; station-reporting linkage; upgrade-parameter conversion; OSD overlay management.
Overspeed; skipped or delayed stations; signal events; standby compliance; crossing overspeed; yielding to pedestrians.
Station-reporting algorithms; CAN configuration; road snapshots; operation management; attendance management.
GUI, web interface, resources and configurations.
Bus peripheral integrations, including CAN interfaces, displays and LED devices.
Custom alarms, business processes and private protocols.
Customer GUI and web interfaces, resources and configuration files.
Serial-port, network-port and CAN-port integrations.
These modules build on the SDK and industry baseline. Different customers can implement their own applications over that shared starting point. Licensing and intellectual-property terms are agreed separately for each project.
02 / WHAT YOU CAN BUILD
From a CAN peripheral to a customer AI library, the SDK opens the functions that turn a device into your solution.
Read device status, integrate peripherals and control the parameters that your application depends on.
Work with audio/video, recordings and device storage through a common set of interfaces.
Connect your platform using the device protocol, or evaluate device-side development when your project needs custom behavior.
Integrate a customer AI library through the StreamaxAI adapter, or build an application with GUI, web and Android interfaces.
API REFERENCE OVERVIEW
Expand an area to explore its operations and the implementation questions to resolve for your project.
9 API areas
Voltage; vehicle key / ignition status; GPS; temperature; G-sensor.
Confirm available signals, units, update rates and device-specific behavior.
Serial port; network port; CAN port; digital I/O. Custom CAN / serial parsing with existing GUI or web interfaces.
Specify the peripheral model, interface, message format and required configuration screen.
Customer algorithm plug-in development. The AI adapter example exchanges YUV video and speed information for ADAS / DMS alarms.
Confirm the input format, target chipset, resource budget and alarm interface in the project SDK.
Audio/video encoding; image capture; preview; MP3 playback; text-to-speech playback.
Confirm channel counts, formats, encoding options and simultaneous-operation limits for the target model.
Parameter import and export; get and set; parameter monitoring.
Confirm which parameters are exposed, how changes take effect and which settings persist after restart.
Video query; playback; export; overlay; pre-recording.
Define the required time range, evidence format and pre-recording behavior with the supported SDK release.
Alarm queries; alarm linkage; custom alarm types.
Define the event conditions and required actions, then confirm event delivery and linkage behavior.
Custom types; queries; export.
Confirm data structure, timestamps, retention and export format in the detailed interface documentation.
Disk mounting; formatting; private file-system format; loop overwrite.
Confirm supported media, file-system requirements and storage lifecycle behavior on the selected device.
No matching area. Try a broader term or clear the search.
Consult the project-specific API documentation for function names, arguments, return values and error codes.
CORE CAPABILITY INVENTORY
Explore the platform capabilities by purpose. Confirm availability and performance for the selected device and software release.
Confirm applicable safety certifications, security requirements, positioning accuracy, boot time and resource limits for the selected product and release.
03 / CHOOSE THE INTEGRATION PATH
These are different development tasks. Start with the behavior you need to change, then decide which side of the connection needs development.
The N9M / 808 integration example includes preview, playback, evidence upload and snapshots over the network link. ONVIF is another network integration path. Obtain the applicable protocol specifications and access for your project.
DIAGRAM 04 / CUSTOMER AI INTEGRATION
The two modes share the application, adapter and SoC-library structure. The customer mode replaces the StreamaxAI library with a customer AI library.
YUV video
Speed information
ADAS alarms
DMS alarms
WHAT THE ARROWS MEAN
YUV video and speed information flow from the adapter to the AI library. ADAS and DMS alarms return to the adapter.
The algorithm implementation is the StreamaxAI library.
Confirm call signatures, memory ownership, threading, scheduling, supported chipsets and resource budgets using the target SDK documentation and project evaluation.
Switching modes changes this illustration only.
04 / FOLLOW ONE WORKFLOW
This illustrative trucking workflow combines the documented peripheral, alarm, recording and networking capabilities. It shows where each layer contributes; it is not a prepackaged feature or a live device simulation.
The device-management framework exposes interfaces such as serial, CAN, digital I/O and GPS. The exact signal set and API contract depend on the project hardware and SDK.
A project might define a custom event when an agreed vehicle signal changes, request a snapshot or recording action, then report the event to its platform. Signal conditions, recording behavior and delivery handling must be specified and validated for that project.
The SDK handles the device capabilities; the baseline provides applicable shared business behavior; the customer layer decides what the event means for its operation. A custom parser can be an industry or customer plug-in, depending on whether it is reusable or project-specific.
05 / DEVELOPER TOOLKIT
Development documents, demos and practical tools support your team from environment setup to integration and debugging.
THE DEVELOPMENT WORKSPACE
Find development guides, interface references, example demos and FAQ cases in the SDK resource environment.
PLAN STORAGE
Estimate bitrate and disk recording duration from channel count, resolution, image quality, frame rate and encoding format.
DEBUG APPLICATIONS
Debug custom functions, investigate crashes and assist performance analysis with tools supplied for the target chipset and model.
INSPECT NETWORKS
Inspect raw data streams during protocol development and platform integration to understand what is happening on the connection.
06 / APPLICATION EXAMPLES
See how common platform capabilities become specific customer applications.
Use the GUI toolkit and components to build customer interfaces, vehicle displays and video views that match your operation.
The school-bus example connects customer platform services with device status, alarms and video uploads. Custom functions include power scheduling, GPS reporting and resumable MP4 uploads.
Build custom CAN or serial parsing with SDK peripheral interfaces. Use the existing GUI or web framework to configure and present the integration.
Connect a customer AI library through the adapter layer while reusing the platform's audio/video and embedded business framework.
SCHOOL BUS
The X7V3 / X7V4 example combines preview, alarm upload, MP4 upload, device status and sleep / power control. Its baseline includes web functions, LED, overspeed alarms and serial peripherals; the underlying layer supplies AI alarms, recording, snapshots, networking, I/O, GPS and power functions.
RTSP, HTTPS and SFTP are shown between the customer program and its platform. Customer functions include timed power control, GPS reporting and resumable MP4 uploads. Define the transport and upload requirements for each function during integration.
PUBLIC TRANSIT
The example combines station announcements, door-linked video, passenger-flow input, AVM, CAN, GPS, video preview and media playback. In this case, the customer achieved basic product behavior within one month and later shipped in volume.
This is a reported case outcome, not a general delivery-time commitment. The public-transit features illustrate the development model and should not be assumed to belong to every freight baseline.
07 / FROM IDEA TO INTEGRATION
Work with your Streamax contact to evaluate the device, integration scope and resources your development team needs.
Share your target device, business requirements, interfaces and development team.
Confirm the development approach, industry baseline and SDK resource requirements.
After approval, receive an account and the project documents, branch and resources.
Develop with project management and FAE support, then verify the integration.
ACCESS, DELIVERY & SUPPORT
Project initiation, account provisioning and issue handling support your team through development and integration.
A practical engineering checklist derived from the architecture—not an additional promise of SDK functionality.
Device model, chipset, firmware, SDK branch, industry baseline, operating environment and required interface families.
Peripheral protocols, signal definitions, event conditions, UI behavior, recording and upload requirements.
CPU / memory / storage budgets, startup and shutdown behavior, update procedures and compatibility expectations.
Test hardware, representative data, error scenarios, acceptance criteria, documentation and named support contacts.
READY TO START?
Use the checklist to prepare a focused discussion with your Streamax representative.
Suggested device development team: one product manager, two Linux C++ developers and one QA engineer.
Not always. If you only need your platform to connect to an existing device protocol, start with protocol integration. Device-side SDK development is evaluated when you need custom device behavior.
SDK resources are provided through the customer development account process. Your Streamax contact helps evaluate the project and arrange the appropriate documents, resources and access.
Confirm the available APIs, components, baseline and tooling for your selected device and SDK release during project evaluation.
