Skip to main content
Your request
ENDEFR
Your request
ENDEFR

Dynamic Stream Selection 2.0

Modern video management systems face a fundamental architectural trade-off:
On the one hand, the number of cameras displayed simultaneously per client continues to increase (e.g. large control rooms with dozens of streams), while on the other hand camera resolutions and bitrates are steadily rising.
Conventional streaming architectures, especially single-stream or simple dual-stream approaches, reach physical limits at GPU, CPU, and network levels.
 

Dynamic Stream Selection 2.0 (DSS 2.0) addresses this challenge by consistently decoupling stream generation, stream processing, and stream consumption.

Core Principle of DSS 2.0

DSS 2.0 is based on a clear architectural concept:

Stream selection no longer occurs at the input (Camera to Server), but at the output (Server to Client).

Key Elements: 

  • The camera provides up to four parallel configurable streams to the server
  • These streams typically differ in resolution (e.g. low, medium, high, very high)
  • All configured streams are transmitted to the server continuously
  • The server dynamically decides, individually for each stream, which stream is delivered 

Clients include: 

  • Operator viewers (e.g. G-View, G-SIM clients)
  • Web clients (Web API / WebSocket streaming)
  • Video analytics (e.g. G-Tect)
  • Recording (continuous or event-based)

Client-specific stream selection

Each client provides the following information when requesting video: 

  • The actual pixel dimensions of its viewer
  • Optional preferences (e.g. quality vs. performance prioritization)

 Based on this information, DSS 2.0 selects the most suitable stream by using an approximation method.

A client’s stream decision has no impact on other clients of the same camera.

Example 

  • An operator opens a camera in fullscreen mode (4K required).
  • At the same time, video analytics continues to process a low-resolution stream.
  • Other operators view the same camera at different resolutions. 

No client forces other clients to switch to a higher resolution.

Comparison with other streaming models

DSS 2.0

  • Streams are permanently available
  • Switching is internal and seamless
  • No encoder reconfiguration on the camera
  • Significant performance gains even with just two streams 

Key difference to classic dual stream: 

All configured streams run continuously, enabling instant switching without delay or recording gaps.

Classic Dual Stream

Fixed assignment: 

  • Stream A: Recording
  • Stream B: Live viewing 

Disadvantages: 

  • Stream switching can cause encoder-resets
  • Potential recording gaps during events
  • No client-specific behavior
  • Camera must reconfigure streams on-the-fly when requirements change

Single Stream

  • One stream for all purposes
  • High GPU load with many viewers
  • No scalability for varying viewer sizes

Suitable when:

  • Camera to server bandwidth is extremely limited
  • Only a single use case exists (e.g. recording only)

Integration with Recording and Analytics

Recording

Recording resolution remains defined by the media channel/profile.
DSS 2.0 ensures that: 

  • The appropriate stream is already available
  • Switching occurs without recording gaps (iFrame-synchronous)

Video Analytics (G-Tect: AD / VMD / VMX / LPR)

  • Analytics automatically access the optimal stream
  • No forced processing of high-resolution streams
  • Reduced system load without loss of analysis quality

Configuration and requirements

Supported via: 

  • Plugin Loader
  • RTSP Universal Plugins
  • E4 and E5 Plugins

Streams are referenced directly via RTSP-URLs or configured on the camera using the Plugin Loader 

All streams within a DSS set use the same codec (e.g. H.264 or H.265). Stream selection is primarily based on resolution, not frame rate.

Network bandwith

DSS 2.0 shifts bandwidth requirements:

Camera to Server:
Tends to be higher, as multiple streams are transmitted in parallel. Depends on:

  • Number of streams
  • Resolutions
  • Bit rate profiles of the camera

Server to Clients:

  • Lower, as clients only receive the resolution they actually need

Important:
The effective additional bandwidth is not linear at a factor of 4, but typically in the range of 1.5×–1.75×, depending on stream profiles.

System resources

The biggest technical advantage of DSS 2.0 is the drastic reduction in decoding load (CPU/GPU)

  • Small viewers decode small streams
  • Large viewers decode large streams
  • No unnecessary 4K decoding for thumbnails
     

Example:
35 camera streams/viewers on 3 monitors.
Before DSS 2.0:

  • GPU utilisation: ~90–100%
  • Jerkiness

After switching to DSS 2.0 (two streams per camera):

  • GPU utilisation: ~40–45%
  • Smooth streams
  • Full resolution when double-clicking on a single image

Limitations (intentional)

DSS 2.0 currently does not distinguish between identical resolutions with different frame rates.

Use cases such as: 

  • Low FPS during normal operation
  • High FPS during events 

must still be handled using classic mechanisms (e.g. resolution switching). 

This limitation is intentional to ensure stability and predictability.

Summary of Benefits

Dynamic Stream Selection 2.0 provides: 

  • Client-specific stream selection
  • Massive reduction in GPU and CPU load
  • Significantly improved workstation scalability
  • Seamless switching without encoder resets
  • Optimal use of high resolutions where needed
  • Clear separation of recording, analytics, and display requirements 

DSS 2.0 is not an incremental improvement, but a fundamental architectural redesign of stream distribution and was introduced with G-Core 8.2.