Feed 0% source
AI/ML AI-generated

X-Stream: Exploring MLLMs as Multiplexers for Multi-Stream Understanding

Generated by a local model (nvidia/Gemma-4-26B-A4B-NVFP4) from a scientific paper, claim-checked against the full text. Provenance is open by design.

Current MLLMs Are Blind to the Room

Current AI models are excellent at watching a single video. However, they struggle when watching multiple camera feeds simultaneously. Most existing benchmarks use single-stream paradigms (processing one continuous flow of data). This leaves a gap in evaluating real-time, cross-stream reasoning. This is a hurdle for live sports broadcasting, autonomous driving, or multi-screen collaboration. These tasks require coordinating info from different angles and devices.

The authors find that state-of-the-art Multimodal Large Language Models (MLLMs) are inept at this task. When acting as "multiplexers" (systems that combine multiple signals into one), they achieve only about 50% accuracy. They also fail significantly at proactive reasoning (predicting or waiting for future events).

The Problem

Standard video understanding relies on single-stream processing. The model consumes one continuous flow of tokens (the basic units of data processed by the model). But real-world perception is rarely a single line of sight .

Figure 2
Figure 2. The illustration of the multi-streaming task. Fig.(a) and (b) showcase the practical examples in daily life. Essentially, the multi-streaming task involves multiple videos with temporal constraints and alignment, requiring the synchronization of video timestamps, as shown in Fig.(c).

A sports broadcaster manages dozens of cameras. An autonomous vehicle fuses front-facing cameras with side sensors. A robot might synchronize a shoulder mount with a wrist camera.

Existing multi-video datasets lack "streaming" characteristics. They lack the requirement for continuous, online inference with temporal alignment (matching timestamps across feeds). Most current benchmarks treat multi-view tasks as offline processing of complete files. They miss the core difficulty of streaming. The model must monitor incoming data in real-time. It must decide exactly when to respond to a query. Many datasets also suffer from "single-stream shortcuts." In these cases, a model answers a question by looking at only one stream .

Figure 3
Figure 3. The illustration of the 4 multi-stream abilities. To evaluate these abilities, our X-Streaming Benchmark includes 3 progressive dimensions and 11 subtasks.

This bypasses the need for true multi-stream cooperation.

How It Works

The authors introduce X-Stream. This benchmark treats MLLMs as "naive multiplexers." Since an MLLM handles only one token stream at a time, researchers tested three strategies to fit multiple streams into a limited token bandwidth :

Figure 5
Figure 5. MLLMs can only handle one token stream at a time, making a multiplexer essential for integrating multiple video streams into one token stream. To address this, we investigate three multiplexing strategies and uncover their inherent trade-offs.
  1. Spatial Division Multiplexing: This method stitches multiple streams into a single frame via pixel-level concatenation. It creates a "grid" of videos. Vertical-level stitching generally outperforms horizontal stitching [Figure D14]. This is because it avoids interleaving tokens during the model's raster-scan (reading pixels row-by-row).
  2. Time Division Multiplexing: Here, streams are processed as independent inputs. The model assigns them identical temporal embeddings (mathematical representations of time) to maintain synchronization. This allows the model to jump between streams.
  3. Semantic Division Multiplexing: This is the most sophisticated approach. It uses a Determinantal Point Process (DPP) kernel to select tokens [Equation 1]. This tool picks a subset of items that are both relevant to a query and diverse. This ensures critical visual information is preserved under tight token budgets.

To ensure the benchmark tests multi-stream intelligence, the authors used a dual-verification pipeline. They use a "Sufficiency and Necessity" protocol. A question is included only if a model can answer it when all streams are present (sufficiency). It must also fail if any single stream is removed (necessity).

Numbers

The results show a massive performance gap. Top-tier proprietary models like Gemini 3 Pro achieve high scores on single-stream tasks. However, their performance drops to approximately 49.60% on the X-Stream benchmark [Table 2]. This means even the best models fail half the time in multi-stream settings. The leading open-source model, Qwen3-Omni-30B-A3B, reaches only a 34.28% overall score [Table 2].

Failures follow a pattern. Models struggle most with "agency" and "decision-making" tasks. These require high-level logical cognition. Foundational grounding (like counting objects) is relatively stable. However, "proactive" tasks are a major bottleneck [Table 2]. These tasks require the model to respond only when a specific event occurs.

Multiplexing strategies involve clear trade-offs. Spatial division is excellent for cross-stream referencing. But as the number of streams hits three or more, visual info becomes too blurred. In those dense scenarios, Semantic Division is superior [Table 5]. It preserves critical information under strict token constraints.

What's Missing

There are gaps a practitioner should note. First, proprietary models cannot be evaluated using Semantic Division. Researchers cannot manipulate token-level input for closed APIs. This leaves a gap in understanding how top-tier models behave with semantic pruning.

Second, the impact of audio multiplexing is limited. The authors acknowledge that audio signals have stronger "coupling" (overlap) than pixels. Spatial Division causes audio tracks to overlap. However, the paper does not provide a rigorous framework for multiplexing multi-channel audio without creating noise.

Finally, the hardware footprint of Semantic Division is not fully quantified. This includes the overhead of the DPP kernel and MAP (Maximum A Posteriori) inference. For real-time streaming, the latency of this selection might outweigh the benefits of fewer tokens.

Should You Prototype This

Depends on your use case. If you are building a single-camera assistant, X-Stream won't change your roadmap. But if you work on multi-camera surveillance or autonomous fleets, this is a mandatory benchmark.

The "multiplexer" framework is a solid architectural blueprint. If you hit OOMs (Out of Memory errors) or high latency, prototype the Semantic Division approach. It is the only strategy that scales gracefully to 3+ streams. Code and data are reportedly available; see the paper for the canonical link.

Figures from the paper

Figure 4
Figure 4. Diversity analysis. Algorithm 1: X-streams Benchmark Pipeline Input: RawVideo Output: Multi-Stream QA Benchmark 1 MultiStreams = Preprocess(RawVideo); 2 AllCandQA = EmptySet; 3 FinalQA = EmptySet; 4 for Video in MultiStreams do 5 CandQA = GenerateQA(Video); 6 Append(AllCandQA, CandQA); 7 end 8 for
Figure 6
Figure 6. The case study in our X-Stream Benchmark. We choose a 4-stream, proactive, free-form QA (yellow) and a 2-stream, proactive, multi-choice QA (green) as examples. signals possess stronger inherent coupling than image pixels, our discussion is limited to simple multiplexing techniques.
Novelty
0.0/10
Overall
0.0/10
#multi-stream#streaming understanding#MLLM#benchmark#multiplexing
How this was made
Generation

Model: nvidia/Gemma-4-26B-A4B-NVFP4
Persona: habr_engineer
Refinement: 0
Pipeline: forge-1.0

Verification

Evaluator: nvidia/Gemma-4-26B-A4B-NVFP4
Score: 96% (passed)
Claims verified: 14 / 14

Translation

Model: nvidia/Gemma-4-26B-A4B-NVFP4

Hardware & cost

NVIDIA GB10 · 128 GB unified · NVFP4 · 100% local · $0 cloud
Tokens: 131,437
Wall-time: 423.7s
Tokens/s: 310.2

Next up

WebRISE: A New Benchmark for Evaluating Interactive Web Generation in MLLMs

8.2/10· 6 min