根据 PR body 描述，目的是 'avoid DoS vulnerabilities'，防止攻击者通过发送成千上万的 base64 JPEG 帧来耗尽服务器内存，从而避免潜在的内存耗尽攻击。
建议精读此 PR，重点关注 load_base64 方法中如何处理 num_frames 边界条件的设计决策，以及安全漏洞修复的代码实现，可作为多模态输入验证的参考案例。
review 中，gemini-code-assist[bot] 指出初始实现有逻辑错误：当 num_frames 为 -1（表示无限制）时，使用 split 和切片会错误地移除最后一帧；num_frames=0 会导致空列表引发 np.stack 异常。DarkLight1337 建议为 -1 创建单独处理，最终实现中通过条件分支解决了这些问题，确保正确性和安全性。
实现主要分两部分：
1) 修改 vllm/multimodal/media/video.py 中的 load_base64 方法，根据 self.num_frames 的值处理帧截断：num_frames > 0 时使用 split 截断，=0 时抛出 ValueError，<0 时无限制加载所有帧；
2) 在 tests/multimodal/media/test_video.py 中添加新测试函数（如 test_load_base64_jpeg_enforces_num_frames_limit）和辅助函数 _make_jpeg_b64_frames 来验证限制执行和边界情况。
| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
vllm/multimodal/media/video.py |
multimodal/media | modified | 7.0 |
tests/multimodal/media/test_video.py |
tests/multimodal/media | modified | 5.0 |
分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。
gemini-code-assist[bot] 指出初始实现中，当 self.num_frames 为 -1 时，data.split(",", self.num_frames)[:self.num_frames] 会错误地移除最后一帧；self.num_frames=0 会导致空列表，引发 np.stack ValueError。
结论：通过添加条件分支解决：num_frames > 0 时截断，=0 时抛错，<0 时无限制加载，确保逻辑正确。 · 已解决
风险包括：
1) 截断逻辑可能导致数据丢失，如果用户意外提交超限帧；
2) 边界条件处理（如 num_frames 为负数或零）需谨慎，初始实现已通过 review 修复；
3) 测试覆盖虽增加，但需确保在真实多模态工作流中兼容性，无回归风险。具体到 video.py，修改后的 split 逻辑和错误处理减少了 OOM 风险，但可能影响视频处理的完整性。
影响范围：用户端，多模态输入（如视频/jpeg）的安全性提升，防止恶意输入导致服务中断；系统端，减少内存耗尽风险，增强可靠性；团队端，需维护新增的帧限制逻辑，可能影响后续多模态功能开发。影响程度中等，主要针对使用 VideoMediaIO 的特定场景。
当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。
参与讨论