StreamingBench：首个流式视频理解基准——多模态大模型离人类实时感知还有多远？

📄 论文 : StreamingBench: Assessing the Gap for MLLMs to Achieve Streaming Video Understanding 🏛️ 机构 : 清华大学计算机系 & 人工智能研究院(AIR)、北京邮电大学 👥 作者 : Junming Lin, Zheng Fang, Chi Chen, Zihao Wan, Fuwen Luo, Peng Li, Yang Liu, Maosong Sun 🔗 代码与数据 : github.com/THUNLP-MT/S... 📅 发布: 2024年11月 (arXiv: 2411.03628)

一、介绍：为什么需要「流式视频理解」？

当前多模态大模型（MLLMs）在视频理解方面取得了长足进步，GPT-4o、Gemini 1.5 Pro 等模型在多个离线视频基准上已展现出色表现。但这里有个根本性问题------这些模型都是「事后诸葛亮」。

所谓离线视频理解，就是先把所有视频帧一股脑塞给模型，然后才提问。这就像看完一部电影再写影评------和你一边看电影一边跟朋友吐槽完全是两码事。

人类是怎么看视频的？我们边看、边听、边想、边回应------这是实时的、流式的、连续的。你不会等一部24分钟的纪录片播完才去思考「刚才那个人说了什么」，你是在观看过程中实时做出判断的。

但现有的视频理解基准（Video-MME、MLVU、LVBench 等）全都是离线范式：

基准	#视频	#QA	Timestamp	音频	流式交互
Video-MME	900	2,700	✗	✓	✗
MLVU	1,334	2,593	✗	✗	✗
LVBench	500	1,549	✗	✗	✗
VStream-QA	32	3,500	✓	✗	✗
StreamingBench	900	4,500	✓	✓	✓

注意看 VStream-QA------这是此前唯一一个跟「流式」沾边的基准，但它只有 32 个视频，任务类型仅5种，不涉及音频，问题之间相互独立。说白了就是不够用。

StreamingBench 的核心诉求：填补流式视频理解评估的空白，真正测试 MLLM 在「边看边答」场景下的能力。

二、原理：三大核心评估维度

StreamingBench 评估体系架构如下：

StreamingBench 的设计哲学非常清晰------它从三个维度拆解了流式视频理解和离线视频理解的本质区别：

2.1 Real-Time Visual Understanding（实时视觉理解）

核心问题：模型能不能在视频流的任意时刻，对「刚刚发生」或「正在发生」的视觉内容做出准确判断？

这里的关键设计是时间戳绑定------每个问题都附有一个查询时间点，问题只与该时间点之前的视频内容相关。而且问题中刻意使用了时间指示词如 "right now"、"just now"、"currently"，同一个问题在不同时刻会得到不同答案。

这一维度包含 10 个子任务：

任务代号	任务名称	核心能力
OP	Object Perception	识别视频中的特定物体
AP	Attribute Perception	感知物体的属性（颜色、形状等）
TR	Text-Rich Understanding	识别视频中的文本内容
SU	Spatial Understanding	理解空间位置关系
CT	Counting	计数能力
ACP	Action Perception	动作识别
CR	Causal Reasoning	因果推理
CS	Clips Summarization	片段摘要
ATP	Action/Event Temporal Perception	动作/事件时序感知
PR	Prospective Reasoning	前瞻推理（预测下一步）

2.2 Omni-Source Understanding（全源理解）

核心问题：模型能不能同步处理视觉和音频信息，并在需要两者结合时做出正确判断？

举个具体例子：「视频中发出 $某种声音$ 时，画面上发生了什么？」------这种问题不看视频听不懂，只看视频听不全，必须视听同步才能回答。

这一维度包含 4 个子任务：

任务代号	任务名称	核心能力
ER	Emotion Recognition	情绪识别（需结合视觉表情+语音语调）
SCU	Scene Understanding	场景理解（描述同时发生的视觉+音频场景）
SD	Source Discrimination	来源判别（谁说了这句话？需视听结合）
MA	Multimodal Alignment	多模态对齐（某句话说出时，画面是什么？）

关键约束：所有 Omni-Source 问题都被设计为「不看音频就答不出来」，确保真正测试跨模态同步理解能力。

2.3 Contextual Understanding（上下文理解）

核心问题：模型能不能在冗余信息干扰和连续交互的复杂上下文中保持准确判断？

这是最有挑战性的维度，包含 4 个子任务：

任务代号	任务名称	核心能力
MCU	Misleading Context Understanding	抗误导能力（区分当前状态和历史干扰信息）
ACU	Anomaly Context Understanding	异常检测（识别不寻常事件）
SQA	Sequential Question Answering	顺序问答（前后问题之间有引用关系）
PO	Proactive Output	主动输出（条件满足时自主触发输出）

PO 任务特别有意思------它要求模型像人一样「盯着看」，当满足某个条件时主动说出来。比如「当记分牌上美国队首次显示97分时，输出'97'」。这不是被动回答问题，而是模型需要自主判断时机。

三、数据构建流程

3.1 视频选择

900 个 YouTube 视频覆盖 8 个类别：

🎬 生活记录（旅行 vlog、房屋参观等）
⚽ 竞赛（足球、篮球等）
🎮 觸戏（电竞、觸戏视频）
📚 教育（讲座、教程）
📺 TV节目（剧集、脱口秀、新闻）
⚡ 异常事件（车祸、魔术表演、恶作剧）
🌍 纪录片（科学纪录片、文化探索）
🎞 动画&电影

视频时长从 3 秒到 24 分钟不等，覆盖了丰富的实时流式场景。

3.2 QA 生成

StreamingBench 采用混合标注策略：

自动生成部分（实时视觉理解 + PO 任务）：

以 1fps 采样帧，给每帧左上角打上时间戳水印
每 20 帧一组送入 GPT-4o 生成带时间粒度的描述
基于时间戳描述，GPT-4o 生成 QA pair 并自动分配查询时间戳

手动标注部分（Omni-Source + SQA + MCU + ACU）：

需要音频信息的问题和需要复杂上下文推理的问题，纯靠人工标注确保质量。

质量控制：所有 QA pair（包括自动生成的）都经过人工审核，过滤掉模糊、错误、不需要看视频就能回答的问题，并随机化选项顺序。

3.3 数据统计

维度	#视频	#问题
实时视觉理解	500	2,500
全源理解	200	1,000
上下文理解	200	1,000
总计	900	4,500

每个视频 5 个问题，分别在不同时间点提出。

四、实验结果与分析

4.1 整体表现

13 个模型参与评测（3 个闭源 + 10 个开源），结果让人清醒：

模型类型	最佳模型	Overall Acc	与人类差距
闭源	Gemini 1.5 Pro	67.07%	-24.59%
闭源	GPT-4o	60.15%	-31.51%
闭源	Claude 3.5 Sonnet	57.68%	-33.98%
开源	LLaVA-OneVision	56.36%	-35.30%
开源	Qwen2-VL	54.14%	-37.52%
人类	-	91.66%	-

Gemini 1.5 Pro 只有 67.07%，比人类低了近 25 个百分点。GPT-4o 更是只有 60.15%。这个差距说明：当前的 MLLM 在流式场景下远未达到人类水平。

4.2 按维度拆解

维度	Gemini 1.5 Pro	GPT-4o	人类
实时视觉理解	75.69%	73.28%	91.46%
全源理解	60.22%	44.50%	90.26%
上下文理解	48.73%	38.70%	93.55%

三个维度的难度递增：实时视觉 > 全源 > 上下文。全源理解中 GPT-4o 只有 44.5%，上下文理解中最高才 48.73%------这两个维度对当前模型来说是真正的硬骨头。

4.3 时间线索类型的影响

论文将问题按线索类型二维分类：

时间维度：Prior（线索在查询之前）、Concurrent（线索在查询时）、Subsequent（线索在查询之后）
数量维度：Single Clue（一帧即可）、Multiple Clues（需要多帧）

线索类型	Prior	Concurrent	Subsequent
单线索	53.91%	43.79%	8.93%
多线索	53.57%	44.07%	3.01%

关键发现：模型性能跟线索数量无关，但跟线索位置强相关。Prior 类型明显优于 Concurrent 和 Subsequent。原因很直觉------当前训练数据大多侧重"事后回顾"型任务，缺乏"边看边判断"和"推断接下来会发生什么"的训练数据。

4.4 冗余信息的影响

MCU 和 ACU 任务专门测试模型在冗余信息干扰下的表现。论文做了一个精妙实验：手动去掉冗余帧后重新评测：

模型	MCU w/冗余	MCU w/o冗余	提升
LLaVA-NeXT-Video	30.40%	65.60%	+35.20%
MiniCPM-V 2.6	31.60%	49.60%	+18.00%
Qwen2-VL	26.00%	67.20%	+41.20%
LLaVA-OneVision	36.00%	68.00%	+32.00%

去掉冗余信息后，MCU 任务准确率直接翻倍甚至更多！当前模型完全不具备从冗余视觉信息中精准提取关键信息的能力。

4.5 顺序问答中的引用问题

SQA 任务中，后续问题经常引用前面的交互内容，比如「上一个问题提到的球队得了多少分？」。论文实验发现：当你把引用显式解析出来（比如直接写「GS队」），大多数模型表现都有提升。这说明模型还不会自动处理跨问题的引用关系。

4.6 Proactive Output：最难的任务

PO 任务的评估方式本身就是一大创新------轮询策略：

在 ground truth 时间戳前后 $-4s, +4s$ 区间内，每秒问模型一次「Is it the right time to output XXX?」
模型回复 "Yes" 时，再问它输出具体内容
实际输出时间与 ground truth 差距 <2s 才算正确

结果？所有模型都惨败。Gemini 1.5 Pro 在 PO 任务上只有 45.1%，开源模型大多在 15-30% 之间。

但放宽容差阈值后（比如允许 5 秒偏差），准确率迅速提升------这说明模型有能力识别关键信息，但缺乏精确定时能力。

五、GitHub 代码拆解

代码仓库地址：github.com/THUNLP-MT/S...

整体项目结构：

php 复制代码

StreamingBench/
├── data/
│   ├── real/               # 实时视觉理解数据
│   ├── omni/               # 全源理解数据
│   ├── sqa/                # 顺序问答数据
│   └── proactive/          # 主动输出数据
├── src/
│   ├── eval.py             # 主评估入口
│   ├── benchmark/          # 基准实现
│   │   ├── Benchmark.py              # 基准基类
│   │   ├── StreamingBench.py         # 标准流式基准
│   │   ├── StreamingBenchProactive.py # PO 任务基准
│   │   ├── StreamingBenchSQA.py      # SQA 任务基准
│   │   └── StreamingOpenStreamText.py # 流式在线基准
│   ├── model/              # 模型实现
│   │   ├── modelclass.py             # 模型基类
│   │   ├── LLaVAOneVision.py         # LLaVA-OneVision
│   │   ├── MiniCPMV.py               # MiniCPM-V
│   │   ├── Qwen2VL.py                # Qwen2-VL
│   │   └── ...（其他模型）
│   └── utils/
│       ├── data_execution.py          # 数据加载与模型调用
│       └── video_execution.py         # 视频裁剪工具
├── scripts/
│   ├── eval.sh             # 评估脚本
│   ├── preprocess.sh        # 预处理脚本
│   └── stats.sh             # 统计脚本

5.1 主评估入口 `eval.py`

python 复制代码

def main(args):
    data = load_data(args.data_file)

    # 根据参数选择不同基准类型
    if args.benchmark_name == "Streaming":
        benchmark = StreamingBench(data)
    if args.benchmark_name == "StreamingProactive":
        benchmark = StreamingBenchProactive(data)
    if args.benchmark_name == "StreamingSQA":
        benchmark = StreamingBenchSQA(data)
    if args.benchmark_name == "StreamingOpenStreamText":
        benchmark = StreamingOpenStreamText(data)

    # 根据参数选择不同模型
    if args.model_name == "MiniCPM-V":
        model = MiniCPMV()
    if args.model_name == "MiniCPMo":
        model = MiniCPMo()

    # 运行评估
    benchmark.eval(data, model, args.output_file, args.context_time)

关键参数：

data_file：QA 数据 JSON 文件路径
model_name：待评估模型名
benchmark_name：基准类型（Streaming / StreamingProactive / StreamingSQA / StreamingOpenStreamText）
context_time：查询前的视频上下文时长（-1 表示全部，正整数表示只取最后 t 秒）

5.2 视频裁剪核心 `video_execution.py`

这是整个评估流程中最关键的底层操作------根据查询时间戳裁剪视频片段：

python 复制代码

def split_video(video_file, start_time, end_time):
    video_name = os.path.splitext(os.path.basename(video_file))[0]
    output_dir = os.path.join(os.path.dirname(video_file), "tmp_60")
    output_file = os.path.join(output_dir, f"{video_name}_{start_time}_{end_time}.mp4")

    # 用 ffmpeg 裁剪：从 start_time 开始，持续 (end_time - start_time) 秒
    ffmpeg
        .input(video_file, ss=int(start_time))
        .output(output_file, t=(int(end_time) - int(start_time)),
                vcodec='libx264', acodec='aac')
        .overwrite_output()
        .run()
    return output_file

设计要点：

将流式任务转换为离线评估的核心手段------只裁剪查询时间点之前的片段
context_time 参数控制裁剪起点：-1 表示从视频开头裁剪，60 表示只取查询前 60 秒
裁剪结果缓存在 tmp_60/ 目录，避免重复裁剪

5.3 标准基准实现 `StreamingBench.py`

python 复制代码

PROMPT_TEMPLATE = '''You are an advanced video question-answering AI assistant.
You have been provided with some frames from the video and a multiple-choice question.
Your task is to carefully analyze the video and provide the best answer,
choosing from the four options provided.
Respond with only the letter (A, B, C, or D) of the correct option.

Question: {}
Options:
{}
{}
{}
{}'''

def StreamingBenchEval(data, MODEL, output_path, context_time):
    for subset in tqdm(data):
        for question in subset["questions"]:
            # 跳过已有回答的问题
            if MODEL.name() in question and question[MODEL.name()]:
                continue

            video_path = subset["video_path"]
            timestamp = question["time_stamp"]
            # 时间戳转换："00:03:10" → 190秒
            timestamp = sum(int(x) * 60 ** i
                          for i, x in enumerate(reversed(timestamp.split(":"))))

            # 根据context_time确定裁剪起点
            if context_time > 0:
                time_start = max(0, timestamp - context_time)
            else:
                time_start = 0

            # 裁剪视频片段
            file = split_video(video_path, time_start, timestamp)

            # 构造 prompt
            ques = question["question"]
            options = question["options"]
            inp = PROMPT_TEMPLATE.format(ques, *options) + "\n\nThe best option is:"

            # 获取模型回答
            response = get_model_response(MODEL, file, inp)
            question[MODEL.name()] = response

            # 实时保存结果（支持中断恢复）
            with open(output_path, "w") as f:
                json.dump(data, f, indent=4)

代码亮点：

时间戳解析用了 reversed + enumerate 的技巧，简洁优雅
实时保存：每回答一个问题就写文件，支持断点续评
裁剪视频只取 [time_start, timestamp] 区间，模拟「模型只看到了查询时刻之前的内容」

5.4 PO 任务基准 `StreamingBenchProactive.py`

这是最有创意的实现------轮询策略：

python 复制代码

def StreamingBenchProactiveEval(data, MODEL, output_path, context_time):
    for subset in tqdm.tqdm(data):
        for question in subset["questions"]:
            start_time = parse_timestamp(question["time_stamp"])
            ground_truth_time = parse_timestamp(question["ground_truth_time_stamp"])
            max_time = ground_truth_time + 4  # 最大轮询到 ground_truth + 4秒

            # 构造查询：附加 "Is it the right time to output XXX?"
            query = f"{question['question']} Is it the right time to output \"{question['ground_truth_output']}\"?"

            current_time = start_time + 1
            while current_time <= max_time:
                clip_file = split_video(video_path, start_time, current_time)
                response = get_model_response(MODEL, clip_file, inp)

                if 'yes' in response.strip().lower():
                    # 模型说"是的"，再问它输出具体内容
                    inp = PROMPT_TEMPLATE_PROACTIVE.format(question['question'])
                    response = get_model_response(MODEL, clip_file, inp)
                    answered = current_time
                    break

                current_time += 1  # 每秒推进一次

核心机制：

从查询时间戳开始，每秒裁剪一个更长1秒的视频片段
对每个片段问模型「是否该输出？」
模型回答 "Yes" 时，追问输出内容
记录整个对话历史（dialog_history）
实际输出时间与 ground truth 的差距 <2s 才算对

5.5 SQA 任务基准 `StreamingBenchSQA.py`

顺序问答的独特之处在于上下文累积：

python 复制代码

def StreamingBenchSQAEval(data, MODEL, output_path, context_time):
    context = ""
    for video_data in tqdm.tqdm(data):
        for subset in video_data:
            for question in subset["questions"]:
                # 构造带上下文的 prompt
                inp = PROMPT_TEMPLATE.format(context, ques, *options)
                response = get_model_response(MODEL, file, inp)
                question[MODEL.name()] = response

                # 将当前QA加入上下文（使用ground truth answer，而非模型回答）
                if not context:
                    context += "Here are the contextual information..."
                context += f"At timestamp {question['time_stamp']}, QA: {ques}; Answer: {question['answer']}; "

关键设计 ：SQA 使用 ground truth answer 而非模型自身的回答作为上下文------论文假设「在真实流式场景中，人类会纠正模型的错误回答」。这是一个务实的设计选择。

5.6 模型基类与实现

基类 modelclass.py 极简：

python 复制代码

class Model:
    def __init__(self): pass
    def Run(self, file, inp): return ""
    def name(): return ""

以 MiniCPMV.py 为例的实现：

python 复制代码

class MiniCPMV(Model):
    def __init__(self, model_path='openbmb/MiniCPM-V-2_6'):
        self.model = AutoModel.from_pretrained(model_path,
            trust_remote_code=True, torch_dtype=torch.bfloat16)
        self.model = self.model.eval().cuda()
        self.tokenizer = AutoTokenizer.from_pretrained(model_path)
        self.MAX_NUM_FRAMES = 64

    def encode_video(self, video_path):
        vr = VideoReader(video_path, ctx=cpu(0))
        sample_fps = round(vr.get_avg_fps() / 1)
        frame_idx = [i for i in range(0, len(vr), sample_fps)]
        if len(frame_idx) > self.MAX_NUM_FRAMES:
            frame_idx = uniform_sample(frame_idx, self.MAX_NUM_FRAMES)
        frames = vr.get_batch(frame_idx).asnumpy()
        return [Image.fromarray(v) for v in frames]

    def Run(self, file, inp):
        frames = self.encode_video(file)
        msgs = [{'role': 'user', 'content': frames + [inp]}]
        answer = self.model.chat(image=None, msgs=msgs,
                                 tokenizer=self.tokenizer,
                                 use_image_id=False,
                                 max_slice_nums=1)
        return answer

    @staticmethod
    def name(): return "MiniCPM-V"

5.7 评估脚本 `eval.sh`

bash 复制代码

CONTEXT_TIME=-1  # -1 = 全部上下文，正整数 = 查询前t秒

# 四种基准分别运行
TASK="real"       && BENCHMARK="Streaming"
TASK="omni"       && BENCHMARK="Streaming"
TASK="sqa"        && BENCHMARK="StreamingSQA"
TASK="proactive"  && BENCHMARK="StreamingProactive"

# 还有流式在线评估选项
TASK="real"       && BENCHMARK="StreamingOpenStreamText"

六、踩坑点与深度思考

6.1 流式→离线的转换折衷

StreamingBench 的核心设计是将流式任务转换为离线任务来评估------只裁剪查询时刻之前的视频片段。这个折衷是必要的，因为当前大多数 MLLM 不支持流式视频输入。

但这带来一个问题：真实流式场景中，模型需要维护持续的记忆状态，而不是每个问题独立处理一段视频。论文的 SQA 任务部分解决了这个问题（通过累积上下文），但更复杂的流式状态维护（如持续更新记忆、注意力衰减等）还未被评估。

6.2 PO 任务的轮询策略开销

PO 任务的轮询策略意味着每个问题需要多达 10 次模型推理（±4秒区间内每秒一次），加上一次追问输出内容。对于闭源 API 模型来说，这是巨大的成本和时间开销。论文也承认这一点，目前只评估了 50 个 PO 问题（总共设计了 250 个）。

6.3 时间戳解析的时间成本

论文的时间戳解析公式： $T= ∑i=0n−1 di×60i T = \sum_{i=0}^{n-1} d_i \times 60^i$ T=∑i=0n−1di×60i

其中 $di d_i$ di 是从右到左的时间分量（秒、分、时）。代码实现为：

python 复制代码

timestamp = sum(int(x) * 60 ** i for i, x in enumerate(reversed(timestamp.split(":"))))

这比手动 h*3600 + m*60 + s 更优雅，但也更容易出 bug------如果时间戳格式不统一（比如 "3:10" vs "00:03:10"），split(":") 的结果长度不同，enumerate 的幂次也会不同。代码没有做格式校验。

6.4 视频裁剪的缓存策略

split_video() 函数把裁剪结果放在 tmp_60/ 目录，而且注释掉了 os.remove(file)------这意味着每次评估都会积累大量临时视频文件。对于 900 视频 × 5 问题 = 4500 个裁剪片段，磁盘占用不小。

6.5 ASR 信息的增益实验

论文附录中做了一个有意义的实验------给模型额外提供视频的 ASR（语音识别）文本：

模型	w/o ASR	w/ ASR	提升
LLaVA-OneVision	56.36%	58.79%	+2.43%
Qwen2-VL	54.14%	57.43%	+3.29%

ASR 信息确实带来了提升，但幅度不算大。这说明当前模型还不太擅长融合文本化的音频信息与视觉内容，真正的音频模态理解（直接从音频波形提取信息）仍然是个开放问题。

6.6 流式视频 MLLM 的表现

论文还评估了两个专门为流式视频设计的模型------Flash-VStream 和 VideoLLM-online。结果更惨：

模型	Overall
Flash-VStream	24.04%
VideoLLM-online	32.48%

Flash-VStream 在大多数情况下只输出 "A"，几乎无法正常回答问题。VideoLLM-online 能接受流式输入，但性能跟轮询策略差不多甚至更差。专门为流式设计的模型目前还不如通用模型，这说明流式视频理解的架构设计仍处于非常早期阶段。

七、效果对比与未来展望

7.1 核心发现总结

人类 vs 模型的差距巨大：最佳模型 Gemini 1.5 Pro 的 67.07% 比人类的 91.66% 低了近 25%
三个维度难度递增：实时视觉（75%）> 全源理解（60%）> 上下文理解（49%）
冗余信息是致命弱点：去掉冗余帧后 MCU 任务提升 18-41 个百分点
线索位置比线索数量更重要：Prior 类型远优于 Concurrent 和 Subsequent
主动输出几乎做不到：PO 任务是所有模型的短板
音频理解严重不足：GPT-4o 在全源理解上只有 44.5%

7.2 改进方向

论文基于实验分析提出了几个关键改进方向：

增强 Concurrent 和 Subsequent 类型任务的训练：当前训练数据偏重 Prior 类型
提升冗余信息过滤能力：模型需要学会从连续帧流中精准提取关键信息，而非被历史帧误导
改进引用解析能力：SQA 场景下模型需要自动处理跨问题的语义引用
实现真正的流式推理架构：而非把流式问题转换为离线问题来敷衍
原生音频理解：不只是用 ASR 文本替代，而是从音频波形中直接提取信息

7.3 后续进展（截至2025年5月）

根据 GitHub 仓库的最新更新：

时间	模型	成绩
2025.05	Seed1.5-VL	PO 任务 82.80%（SOTA）
2025.03	ViSpeeker	全源理解 61.60%（开源SOTA）
2025.01	MiniCPM-o 2.6	Overall 66.01%
2025.01	Dispider	Overall 53.12%（流式SOTA）

可以看出后续模型在 PO 任务上有显著突破（Seed1.5-VL 达到 82.80%），全源理解也在持续进步，但上下文理解维度仍然进展缓慢。

八、总结

StreamingBench 是一个定位精准、设计扎实 的基准------它不是在离线视频理解上继续卷分数，而是直接指向了一个更根本、更贴近真实应用的能力缺口：模型能不能像人一样边看边想边答？

从代码实现来看，项目结构清晰，评估流程合理（流式→离线的转换虽有折衷但务实），PO 任务的轮询策略虽有开销但解决了当前模型不支持流式输入的问题。

最让人印象深刻的是实验分析中的几个发现------冗余信息对模型的杀伤力、线索位置的重要性、PO 任务的时间精度问题------这些都是指引未来研究方向的重要信号。

一句话总结：StreamingBench 告诉我们，当前 MLLM 在视频理解上最大的问题不是「看不懂」，而是「看的时候想不明白」。

本文基于论文原文和 GitHub 代码仓库分析撰写，代码示例均来自实际源码。

StreamingBench：首个流式视频理解基准——多模态大模型离人类实时感知还有多远？

一、介绍：为什么需要「流式视频理解」？

二、原理：三大核心评估维度

2.1 Real-Time Visual Understanding（实时视觉理解）

2.2 Omni-Source Understanding（全源理解）

2.3 Contextual Understanding（上下文理解）

三、数据构建流程

3.1 视频选择

3.2 QA 生成

3.3 数据统计

四、实验结果与分析

4.1 整体表现

4.2 按维度拆解

4.3 时间线索类型的影响

4.4 冗余信息的影响

4.5 顺序问答中的引用问题

4.6 Proactive Output：最难的任务

五、GitHub 代码拆解

5.1 主评估入口 eval.py

5.2 视频裁剪核心 video_execution.py

5.3 标准基准实现 StreamingBench.py

5.4 PO 任务基准 StreamingBenchProactive.py

5.5 SQA 任务基准 StreamingBenchSQA.py

5.6 模型基类与实现

5.7 评估脚本 eval.sh

六、踩坑点与深度思考

6.1 流式→离线的转换折衷

6.2 PO 任务的轮询策略开销

6.3 时间戳解析的时间成本

6.4 视频裁剪的缓存策略

6.5 ASR 信息的增益实验

6.6 流式视频 MLLM 的表现

七、效果对比与未来展望

7.1 核心发现总结

7.2 改进方向

7.3 后续进展（截至2025年5月）

八、总结

5.1 主评估入口 `eval.py`

5.2 视频裁剪核心 `video_execution.py`

5.3 标准基准实现 `StreamingBench.py`

5.4 PO 任务基准 `StreamingBenchProactive.py`

5.5 SQA 任务基准 `StreamingBenchSQA.py`

5.7 评估脚本 `eval.sh`