From hybrid labor to smarter workspaces, combining technology and touchpoints to provide exceptional experiences.
View DetailsUsing Baker's top-notch technology to create exceptional experiences for people, environments, and things.
View DetailsUnderstand best practices, explore innovative solutions, and establish connections with other partners throughout the Baker community.
From hybrid labor to smarter workspaces, combining technology and touchpoints to provide exceptional experiences.
Learn moreUsing Baker's top-notch technology to create exceptional experiences for people, environments, and things.
Learn moreUnderstand best practices, explore innovative solutions, and establish connections with other partners throughout the Baker community.
IndustryInsights
Video has become a core data source in many intelligent system projects. Command platforms, IoT systems, emergency dispatch centers, smart buildings, industrial parks, transportation hubs, and city-level management platforms all need to call live video, replay recordings, control cameras, receive alarms, and display visual information together with business data.
In earlier projects, camera SDK development was a common integration method. A device manufacturer provided an SDK, and the integrator used it to call live streams, control PTZ, read device information, obtain alarm callbacks, or build custom video functions. This approach can still work in a small and controlled environment, especially when all cameras come from the same vendor and the project requirements are fixed.
But the situation has changed. More intelligent system integrators now prefer video access gateways, standard protocols, media conversion, and unified API interfaces instead of developing directly against every camera SDK. This shift is not only a technical preference. It is a response to real project risks, multi-vendor complexity, delivery pressure, and long-term maintenance requirements.
Most intelligent applications do not simply need to “watch a camera.” They need to combine video with maps, alarms, device status, work orders, access control records, production systems, emergency events, or dispatch workflows. In these scenarios, video must be easy to call, easy to display, easy to manage, and easy to connect with business logic.
The problem is that video streams are not always ready for upper-layer business systems. Some cameras output RTSP. Some platforms need HLS or FLV for web viewing. Some emergency command systems require WebRTC for low-latency browser playback. Some communication systems need SIP-based video access. Without a middle layer, every protocol difference can become a separate development task.
This is why camera SDK integration often looks simple at the beginning but becomes difficult later. It solves one connection, but it may also create a long-term dependency between the business platform and one manufacturer’s device rules.
A camera SDK can provide useful functions, including live preview, playback, PTZ control, alarm information, device parameters, and stream management. For a single-vendor project, the method may look efficient. The development team reads the SDK documentation, writes the interface logic, completes testing, and delivers the first project.
The difficulty appears when the same software product must be used in another project, another city, another campus, or another industrial site. The camera brand may change. The device model may change. The firmware version may be different. The recorder platform and network environment may also be different. An SDK integration that worked in one site may not work smoothly in the next one.
For integrators building repeatable solutions, this is a serious issue. The more SDKs the platform depends on, the harder it becomes to keep the software clean, stable, and easy to maintain.
The video surveillance market includes many large manufacturers and many smaller device suppliers. Each vendor may provide its own SDK, and the interface style, authentication method, stream calling rule, playback logic, PTZ control method, and alarm callback mechanism may vary.
For one project, this may only mean extra development work. For a product-based integrator, it can become continuous adaptation. After completing one camera brand, the team may need to adapt another SDK for the next project. If the same site contains mixed camera brands, the workload becomes heavier.
The end user usually does not see this extra effort directly. They only expect the system to open video, control cameras, and link alarms reliably. But for the integrator, repeated SDK adaptation increases cost, delivery time, testing pressure, and maintenance risk.
Cameras and video recorders are long-life devices. In real projects, it is common to find cameras that have been installed for years. A platform may be developed using the latest SDK, while the customer site may still be using older cameras, older firmware, or a legacy video management platform.
Upgrading the entire customer video system just to match one SDK is usually not practical. In large security, transportation, industrial, and public safety projects, stable systems are not upgraded casually. One upgrade may affect recording, storage, platform compatibility, network behavior, security policies, or existing operation habits.
This creates a difficult situation. If the integrator follows every manufacturer’s latest SDK, old devices may become problematic. If the integrator keeps compatibility with old SDKs, the software stack becomes heavier over time. A video access gateway can reduce this pressure by placing compatibility adaptation in a dedicated video layer.
When a project has only a few cameras, direct SDK integration may still be manageable. But when the system includes hundreds, thousands, or even tens of thousands of video points, device-level access becomes inefficient.
Large-scale projects need directory management, grouping, online status, stream distribution, access permission, recording lookup, PTZ control, alarm linkage, location data, and unified operation. If the upper-layer business system must handle each camera SDK directly, the architecture becomes difficult to expand and difficult to hand over to the operation team.
A better model is platform-level integration. The business system should call video resources through standardized interfaces, unified directories, stream addresses, or gateway APIs. Camera differences should be handled by the video access layer, not scattered across the business application.
A video access gateway works as the middle layer between surveillance resources and intelligent applications. Instead of integrating every camera SDK separately, the gateway connects cameras, NVRs, VMS platforms, or video surveillance systems through standard protocols and then provides a unified calling method to the upper-layer platform.
This changes the integration model. The business system no longer needs to understand every camera manufacturer’s SDK details. It only needs to call the gateway’s stream address, API interface, directory data, control command, or event callback. The gateway handles video access, protocol conversion, stream distribution, and compatibility adaptation.
For long-term operation, this boundary is important. Cameras can change. Recorders can be replaced. Firmware can be upgraded. New stream formats may be added. As long as the gateway absorbs these changes, the upper-layer intelligent platform can remain more stable.
In many projects, GB/T28181 is used as a key access protocol for video surveillance integration. After years of development and deployment, it has become a mature option for platform-level video access. It supports common capabilities such as live preview, recording playback, PTZ control, alarm information, device catalog, geographic location, and platform-level interconnection.
For integrators, GB/T28181 reduces the need to connect every camera directly. If a customer already has a video surveillance platform, the gateway can access video resources through a structured framework. The intelligent system can then use standardized video resources without becoming deeply tied to every camera model.
This approach is especially useful in smart city, industrial park, campus, transportation, public safety, and emergency command projects where video resources are already deployed across different phases and different brands.
Different software systems need different video formats. A browser dashboard may need HLS, FLV, or WebRTC. A mobile application may need a lighter stream. A command center may need low-latency display. A professional video system may use RTSP. A media forwarding platform may use RTMP. A communication or dispatch system may require SIP video access.
A video access gateway can provide multiple standard outputs from one access layer. This prevents every business application from building its own conversion chain. It also makes the system easier to expand when new applications need to reuse existing video resources.
For example, one camera stream can be accessed by the gateway and then converted for browser viewing, mobile preview, command dispatch, SIP video linkage, and third-party platform integration. The camera side remains simpler, while the gateway provides the output format required by each application.
Video integration is not only about protocols. Codec format, bitrate, frame rate, and resolution also determine whether video can be decoded, transmitted, and displayed smoothly. A camera stream may be too heavy for a browser client, incompatible with a player, or unsuitable for a remote site with limited bandwidth.
With transcoding, the gateway can adjust the video encoding format, frame rate, bitrate, and resolution according to project requirements. This improves compatibility across browsers, mobile devices, command terminals, dispatch platforms, and integrated software systems.
In practical projects, this can reduce many on-site problems. Instead of asking every camera to output the same stream for every user, the gateway can generate suitable video outputs for different terminals and network environments.
A well-designed video access gateway should provide standardized stream calling rules and unified API interfaces. The intelligent platform can request live video, replay recordings, retrieve device lists, control PTZ, receive alarms, or link video with business events through consistent logic.
This allows the development team to focus on the real business workflow: alarm handling, GIS display, emergency response, production monitoring, traffic dispatch, campus security, access control linkage, or incident review. The video layer becomes a reusable capability instead of a repeated customization task.
For multi-site projects, this model is easier to maintain. When a new site is deployed, the team mainly adapts the access side of the gateway instead of rewriting the business application. When a new video format or device type is required, the gateway absorbs much of the change.
In smart city and public safety platforms, video resources often come from different districts, agencies, platforms, and construction phases. A gateway-based architecture allows the command platform to access large volumes of video through unified directories and standard streams, improving event handling and cross-department coordination.
In industrial parks and production sites, video may need to work with alarms, access control, emergency communication, production lines, storage areas, hazardous zones, and patrol workflows. Standardized video access helps operators view site conditions quickly without forcing the platform to adapt device SDKs from many manufacturers.
In transportation hubs, campuses, hospitals, office parks, and large buildings, phased construction often leads to mixed video systems. A video access gateway helps reuse existing surveillance assets while supporting browser dashboards, mobile terminals, centralized management, and new business applications.
The project team should begin by checking the existing video environment. This includes camera brands, NVRs, VMS platforms, network structure, stream types, recording storage, user permission rules, alarm linkage requirements, and whether a mature surveillance platform is already in place.
Output formats should be defined early. The project may need browser playback, mobile viewing, low-latency command display, SIP video linkage, public network access, private network access, or recording replay. These requirements determine whether the gateway should support HLS, FLV, WebRTC, RTSP, RTMP, SIP, or multiple outputs at the same time.
Transcoding capacity and network bandwidth should also be evaluated. Transcoding is useful, but it consumes computing resources. A project with many simultaneous video calls should confirm the number of channels, target resolution, bitrate, frame rate, expected concurrency, and cross-site bandwidth.
Open interfaces are another important factor. A video gateway should not become a new closed island. For long-term scalability, it should provide clear API documentation, stable stream rules, authentication control, event callback mechanisms, and management interfaces.
Camera SDK development is not obsolete. It still has value in small, fixed, single-vendor environments or when a project needs a specific device function that only the manufacturer’s SDK can expose. But for many intelligent integration projects, SDK dependency creates too much repeated adaptation, version risk, and maintenance pressure.
A video access gateway offers a more scalable path. It connects complex video resources through standard protocols, converts streams into formats required by modern applications, supports transcoding, and provides unified APIs for upper-layer platforms. For system integrators, this means shorter development cycles, clearer architecture, easier maintenance, and better project repeatability.
For projects that combine video, SIP voice, paging, emergency notification, and command dispatch, Becke Telcom / 贝克通信 can be considered as a practical integration partner for building a more unified communication and response workflow.
The reason intelligent projects are moving away from direct camera SDK development is clear. Modern video integration must support multi-vendor devices, large-scale deployment, web playback, mobile access, command dispatch, alarm linkage, GIS, API integration, and long-term expansion. Direct SDK integration often makes these requirements harder to maintain.
A video access gateway creates a more stable middle layer. It connects cameras and video platforms through standard protocols, converts streams for different applications, supports transcoding, and provides unified APIs. As intelligent systems continue to combine video with alarms, maps, IoT devices, communication platforms, and operational workflows, standardized video access will become more important than isolated SDK development.
Not always. A gateway can replace most common integration needs such as live preview, playback, PTZ, stream conversion, and alarm linkage. However, some highly specific device functions may still require the manufacturer’s SDK if they are not exposed through standard protocols.
No. Although GB/T28181 is widely used in public safety and security-related projects, it can also be valuable in industrial parks, transportation systems, campuses, energy sites, and large buildings where platform-level video access and structured device catalogs are required.
Key checks include supported access protocols, output stream formats, transcoding performance, channel capacity, API documentation, authentication method, recording access, PTZ support, alarm integration, deployment mode, and compatibility with the existing video surveillance system.
It may introduce some delay, especially when transcoding is involved. The actual delay depends on codec settings, network quality, gateway performance, output protocol, and player behavior. For low-latency scenarios, WebRTC or optimized RTSP workflows may be considered.
They should choose an architecture with clear standards, documented APIs, flexible authentication, open stream rules, and scalable deployment options. The goal is to make video a reusable service layer that can support multiple business systems over time.
Becke Telcom specializes in IP PBX business phone software systems for enterprises, offices, campuses, hotels, and industrial sites. Its platform supports SIP extensions, call routing, IVR, voicemail, recording, conferencing, operator console, and centralized management, helping organizations build flexible, scalable, and easy-to-manage VoIP communication networks.
