一文读懂 SmartMediaServer：功能全景、统一媒体核心与 SmartMediaKit 协同架构

音视频牛哥

327人浏览 · 2026-10-26 20:26:34

音视频牛哥 · 2026-10-26 20:26:34 发布

在大牛直播SDK（SmartMediaKit）的产品布局中，SmartMediaServer 承担的是中心媒体服务的角色：向下连接网络视频源、推流终端与边缘组件，向上提供实时观看、录像管理、访问控制和开发接口。它既可以独立部署，也可以与 SmartMediaKit 的推流、播放、转发及轻量级 RTSP 服务等模块组合，让终端能力与服务器能力各自发挥作用。

理解这款产品，可以从三个层面展开：功能层面，看它能够直接完成哪些工作；架构层面，看这些功能如何共享媒体资源并保持职责清晰；方案层面，看它如何与 SDK、设备和业务平台组合。 功能清单决定项目的接入范围，架构设计影响运行效率与维护成本，而模块之间的协同，则决定一套方案能否适应不同的交付形态。

一、功能全景：SmartMediaServer 提供哪些服务？

SmartMediaServer 的能力不局限于协议转换，而是覆盖视频来源接入、媒体分发、可视化操作、录像留存、访问管理和开发集成。对于选型和集成团队，可以先通过下面的功能矩阵判断需求覆盖情况，再根据具体视频来源、终端环境和部署条件确定使用组合。

功能分类	主要能力	面向的实际工作
主动拉流	RTSP、RTMP 来源接入	汇聚网络摄像机、NVR 提供的相应码流及已有媒体服务
推流接入	WHIP、RTMP、SRT 接入	接收移动应用、桌面程序、编码设备和其他系统发布的音视频
多协议分发	WHEP、HTTP-FLV、HLS、RTMP、SRT 输出	为浏览器、适配的原生播放器及下游媒体系统提供不同出口
音视频处理	H.264、H.265 视频处理，以及 Opus、AAC、G.711 等音频适配	按来源编码、目标协议和终端能力组织媒体处理
设备发现	ONVIF 设备发现、账号验证、媒体 Profile 读取	减少设备接入时手动查找取流信息的工作
通道组织	名称、分组、主子码流、设备凭据与批量操作	将设备地址和视频来源整理为可管理的通道
网页观看	单路预览、视频广场、多屏展示与轮巡	支持单路查看、多路观察和按分组浏览
分享嵌入	分享播放、嵌入页面、授权范围与有效期管理	将视频放入已有业务界面
录像管理	手动录像、计划录像、录制状态展示	组织临时录制和周期性留存任务
历史使用	按通道、日期和时间检索，录像回放与 MP4 导出	定位历史过程并交付所需视频资料
权限与审计	账号、角色、通道授权、播放票据、操作记录	管理视频访问范围并追溯相关操作
运行观测	运行状态、媒体指标、异常历史与通知对接	定位来源、连接、播放和存储环节的问题
开发集成	REST 风格 HTTP 接口、OpenAPI 说明与集成示例	程序化调用通道、播放、会话和录像能力
部署维护	Windows x64、Linux x86-64，服务管理、配置导入导出、备份与升级入口	在现有环境中部署，并持续维护配置与业务资料

这张表中的能力可以组合，但不能简单理解为所有输入、编码和输出都可以任意互换。例如，服务器能够接收某种视频编码，并不意味着所有观看终端都能解码；设备支持 ONVIF，也不意味着其所有管理功能都已经纳入服务器。选型时应关注具体链路是否成立，而不只是检查协议名称是否出现在列表中。

二、总体架构：媒体处理、业务控制与运行观测分别承担职责

从逻辑职责上看，SmartMediaServer 可以划分为协议接入、统一媒体核心、输出与留存、业务控制、运行观测五个部分。这里的划分用于说明模块之间的关系，不等同于五个独立进程，也不要求项目部署五套服务。

逻辑部分	核心职责	与其他部分的关系
协议接入	建立来源连接或接收发布，解析相应协议与媒体信息	将不同来源交给统一媒体核心组织
统一媒体核心	管理来源状态、音视频轨道、媒体缓存及消费关系	为分发、音频适配和录像提供共同基础
输出与留存	按目标协议组织输出，或将媒体交给录像任务	共享来源，分别维护发送与录制过程
业务控制	管理通道、权限、观看会话、录像计划与配置	通过明确操作控制媒体服务，而不是代替媒体传输
运行观测	汇总连接、任务、媒体指标、异常与审计信息	为控制台和外部业务提供可理解的运行状态

其中最重要的关系，是统一媒体核心位于输入协议与输出能力之间。RTSP、RTMP、WHIP、SRT 等入口负责各自的协议差异，进入中心之后，来源、轨道和媒体消费关系由统一核心组织。输出模块再根据观看协议和编码条件完成适配，避免每增加一种入口，就为它重新建设一套观看、录像和状态管理逻辑。

实时分发与录像则是同一来源的不同消费方向。一路媒体进入服务器后，可以供浏览器观看，也可以进入录像任务；录像并不需要先经过浏览器，更不依赖某个观看页面持续打开。这样的组织方式，使实时使用与历史留存能够共享来源，同时保留各自的任务状态和资源生命周期。

业务控制走的是另一条协作路径。Web 控制台或外部应用通过接口查询通道、申请播放授权、管理会话和录像任务，媒体数据则按照对应播放协议传输。管理视频与传输视频需要协同，但不应被混成一条处理链路。 以 WHIP 为例，它使用 HTTP 完成 WebRTC 推流会话的协商，并不意味着音视频以普通业务接口响应的形式持续传送。

这种架构的意义，是让变化发生在相对清晰的位置：来源接入方式变化，主要由接入模块承接；观看方式变化，主要由输出模块适配；权限或录像规则变化，则由业务控制处理。不同层共享必要信息，而不必彼此复制整套功能。

三、数据与会话设计：通道、来源、观看和录像不是同一个对象

在产品界面中，用户通常只看到“一路通道”，但在服务器内部，这一路通道背后可能同时存在来源连接、音视频轨道、多个观看会话和录像任务。将这些对象区分开，是理解 SmartMediaServer 运行方式的重要一步。

通道承担业务组织，来源承担实际媒体输入。 通道名称、分组和接入配置属于相对持久的信息，而当前来源是否连接、是否持续产生音视频，属于运行时状态。来源暂时断开，不等于通道配置应当消失；重新建立连接，也不应要求业务系统重新创建全部关联关系。将持久配置与当前媒体状态分开，才能让设备维护和业务管理保持稳定。

媒体轨道与输出形式也需要分开。 同一路来源可能包含视频和音频，不同出口对两者的要求并不完全相同。服务器需要知道来源提供了什么、目标出口能够使用什么，以及哪些处理结果可以共享，而不是仅凭一个流地址就认定所有输出方式都能直接工作。统一媒体核心因此不仅管理“有没有流”，还需要组织流中的媒体信息及其使用关系。

观看会话和录像任务则分别表达不同需求。 例如，“实验台 A”可以同时被一个网页、一个原生客户端和一个录像任务使用。关闭网页对应的是结束该观看会话，停止录像对应的是结束录制任务，而修改通道配置又是另一类操作。将这些职责分别管理，可以避免某个客户端退出时误影响其他使用者，也让运行状态更容易解释。

这一设计还影响统计口径。实际观看者、内部协议转送和录像任务虽然都可能消耗媒体，却不是同一种业务对象。把它们全部计入“在线人数”，会掩盖真实使用情况；分别呈现来源、观看和内部处理需求，才能更准确地理解当前系统正在为哪些任务工作。

四、放回 SmartMediaKit 产品体系：不同模块应该部署在哪里？

SmartMediaKit 的产品矩阵包含推流、播放、转发、轻量级 RTSP 服务、录像和 GB28181 终端接入等模块，并通过 WHIP 推流与 WHEP 观看连接 SmartMediaServer。其组合方式不是将所有功能集中到一个程序，而是根据视频产生、传输、管理和呈现的位置选择相应组件。

模块	适合承担的角色	与 SmartMediaServer 的组合方式
采集与推流 SDK	在应用或终端中组织采集、编码和发布	通过所选模块支持的 RTMP、WHIP 等方式将媒体送入服务器
媒体转发组件	拉取已有来源，在现场或边缘完成协议衔接	将 RTSP、RTMP 等来源通过相应推流方式发布到中心
轻量级 RTSP 服务	在设备端或局域网内提供可访问的视频源	可以独立服务本地客户端，也可以作为服务器主动拉流的来源
低延迟播放 SDK	在原生应用中完成接收、解码和呈现	使用与服务器出口相匹配的播放方式；也可独立连接其他兼容来源
Unity3D 播放模块	将视频嵌入三维界面和交互应用	通过双方支持的协议接入中心分发的视频
端侧录像模块	在采集端或播放端进行本地留存	与服务器集中录像各自承担不同位置的记录需求
GB28181 接入 SDK	使终端按国标设备方式接入相应平台	按独立的国标接入链路选型，不据此推定服务器具有完整国标平台能力

在这一布局中，SDK 更接近应用与设备，SmartMediaServer 更接近共享媒体服务。采集程序需要调用摄像头、屏幕或外部编码数据时，选择端侧组件；多个观看者需要共享来源、统一授权或集中录像时，由服务器承接；需要将画面放进三维界面或定制客户端时，再选择相应播放模块。

轻量级 RTSP 服务与 SmartMediaServer 也不是互相替代的关系。前者可以解决局部范围的视频提供问题，后者组织多来源、多观看者及管理业务；项目完全可以保留本地直连，同时增加中心侧观看和录像。类似地，端侧录像可以服务于本地任务，服务器录像则用于统一留存与查询，两者的部署位置和业务目的不同。

这种模块化布局保留了方案选择空间：已有摄像机可以直接接入服务器，已有业务平台可以只调用服务器接口，新的智能终端则可以选择 SDK 与服务器联合接入。组合能力来自清晰的接口和职责，而不是要求每个项目安装全部模块。

五、技术优势：把重复处理、连接积压和问题定位放在正确的位置

第一，围绕来源复用，而不是围绕每个观看者重复建设媒体链路。 多个用户观看同一来源时，共享媒体输入和可复用处理结果，可以减少重复拉取与重复处理。需要强调的是，共享来源不等于没有并发成本：每个观看连接仍然需要发送、协议处理和网络带宽。SmartMediaServer 的设计重点，是减少可以避免的重复工作，而不是用一个“共享”概念掩盖实际资源消耗。

第二，优先保留编码数据，将转换用于确有需要的环节。 在兼容条件下，转封装可以改变媒体承载形式，而不必执行视频解码和重新编码。FFmpeg 对流复制处理的说明也明确区分了这一类路径：不经过解码与编码，可以减少相应处理，并避免重新编码引入的画质损失，但仍受到目标容器等条件约束。SmartMediaServer 在实时分发和适用格式的 MP4 导出中采用相应思路，将不必要的重复编码从链路中移除。

第三，音频适配按需要组织，相同处理结果尽量共享。 视频能够直接使用时，音频仍可能需要根据出口进行转换。服务器结合 Opus、AAC、G.711 等来源与目标要求组织处理，并在同源、相同目标编码条件下复用结果。这样，协议兼容工作更多围绕媒体本身展开，而不是随着观看者增加反复执行同一份转换。

第四，对观看连接分别管理，避免以无限缓存换取表面连续。 网络较慢的观看者与网络正常的观看者，不应被同一份积压状态绑定。SmartMediaServer 分别管理发送与缓存，并对过时媒体设置边界，使慢端处理、资源使用与实时性之间有明确的取舍。低延迟的重点由此从“尽快发出某一帧”，扩展为“持续控制媒体在各环节的停留”。

第五，将传输结果与播放结果分别观察。 接收到数据、成功解码和实际呈现不是同一状态。WebRTC 的统计体系也区分接收、抖动缓冲、解码等环节，说明终端内部处理同样是理解观看体验的重要部分。SmartMediaServer 的配套播放诊断与服务器状态结合使用，可以把问题定位到更具体的位置，而不是只展示一个笼统的“已连接”。

这些设计共同形成一种工程取向：可复用的工作集中处理，需要隔离的状态分别管理，能够观测的问题不留在模糊的连接状态里。 技术优势由此落实到媒体处理、资源组织与维护流程，而不只是某一个协议或某一次测试的数字。

六、交付形态：既能直接使用，也能成为业务系统的一部分

SmartMediaServer 可以按照不同开发投入和产品目标采用不同的使用方式，不必把所有项目都组织成同一种架构。

直接使用 Web 控制台，适合先建立可运行的视频服务。 设备发现、通道配置、单路预览、多屏轮巡、录像查询与权限管理均围绕可视化操作展开。项目可以先完成来源接入和实际观看，再逐步配置录像与访问范围；配置导入导出、批量操作和凭据维护，则用于后续设备增加和环境调整。

通过 HTTP 接口集成，适合已经具备业务平台的团队。 上层系统可以围绕通道查询、播放授权、会话管理、录像检索和导出开展调用，而不必重新实现底层媒体服务。OpenAPI 用于描述 HTTP 接口及其请求、响应等结构，使不同开发语言的团队能够依据统一说明完成对接；它解决的是接口理解与调用契约，不代替账号授权和业务规则。

采用 SDK 与服务器联合方案，适合需要控制终端体验的产品。 采集端可以围绕摄像头、屏幕或外部数据定制，播放端可以围绕低缓冲、渲染和业务界面组织，服务器集中承接接入、分发、授权与录像。终端开发与中心服务因此能够围绕同一条实际媒体链路联调，而不是各自完成之后再寻找衔接方式。

部署层面，当前服务器提供 Windows x64、Linux x86-64 版本，并配套启动停止、服务管理、备份和升级入口。运行程序与配置、凭据、录像等业务资料分别管理，便于按照版本维护流程开展更新。这里的跨平台范围属于服务器交付版本，不能直接套用整个 SmartMediaKit SDK 产品矩阵的平台列表。

七、场景组合：从实验教学到机器人观察，如何组织不同方案？

场景设计不必停留在“哪个行业可以用”的罗列上。更有参考价值的方式，是说明视频由谁产生、谁负责接入、谁观看、在哪里留存，以及哪些能力仍由上层业务负责。基于前述模块，可以形成以下几类不同的组合方案。

1. 远程实验教学：把实验台变成可访问的视频资源

在实验教学或仪器操作展示中，可以将实验台摄像机作为独立通道接入服务器，教师或演示人员的屏幕则通过端侧推流组件单独发布。观看者根据授权进入对应画面，重要操作过程通过计划或手动录像保留，再按时间检索与导出。SmartMediaServer 承担视频接入、观看和记录，课程安排、实验预约及学习评价由教学平台负责；多个画面也可以作为独立通道管理，不必预设服务器已经具备画面合成功能。

2. 机器人研发与任务复盘：提供视觉通路，而不是替代控制系统

机器人研发可以将机载摄像头或配套计算单元提供的视频，通过兼容协议接入中心，供研发人员、测试人员和演示人员查看。需要回看某次任务时，再通过通道和时间范围定位录像，与机器人平台中的任务记录进行人工或业务层关联。这里的组合重点是视频传输、观察与留存；导航、运动控制、传感器融合和模型推理仍属于机器人自身系统，不能因为接入视频服务器就推定这些能力已经一并具备。

3. 三维展示与数字化界面：同一视频来源服务二维和三维终端

当项目需要在 Unity3D 场景中展示实时画面时，可以让 SmartMediaServer 汇聚来源，再通过双方支持的协议交给 Unity3D 播放模块，同时保留浏览器观看和中心录像。SmartMediaKit 已提供面向 Unity3D 的 RTMP／RTSP 播放模块；与本文服务器组合时，可以选择其支持的 RTMP 输出，而不应把端侧播放器支持 RTSP 误写成服务器已经提供 RTSP 输出。三维模型、交互逻辑和视频与对象的绑定，则由应用层完成。

4. 异地产品演示与软件验证：将现场画面和操作画面分别交付

对于需要异地展示设备、软件或原型系统的团队，可以通过摄像头展示实物，通过屏幕采集展示操作，两类内容分别发布为通道。服务器提供网页观看、访问有效期管理和必要的录像留存，演示结束后再导出对应资料。这类方案的价值，是把现场呈现、观看授权和演示记录放进同一套视频服务，而不是每次重新搭建临时链路；语音沟通、会议协作或多画面合成，则按项目需要选择其他相应组件。

这几类方案虽然业务不同，但使用的是相近的能力组合：端侧产生媒体，边缘按需衔接，中心组织服务，应用层赋予业务含义。服务器不需要预置每一种行业流程，也能够通过稳定的媒体与管理能力进入不同产品。

八、整体方案的价值：扩展一个环节，不必重做整套系统

从产品布局看，SmartMediaServer 的意义，是在 SmartMediaKit 的终端组件之外，建立可共享的中心媒体服务。推流模块不必承担全部观看管理，播放模块不必理解所有来源接入细节，业务平台也不必直接处理每种媒体协议。各部分通过明确的协议和接口协作，让项目可以选择最适合当前阶段的组合。