一、无纸化会议的下一阶段，不是“把纸搬到屏幕上”
早期无纸化会议系统解决的问题相对简单：把会议议程、Word、PDF、图片、表格等材料提前上传到服务器，再由会议终端进行阅读、批注和查阅。从这个阶段看，它本质上还是一套“电子文档分发系统”，主要价值是减少打印、简化材料管理。
但当无纸化会议进入政务、央国企、指挥调度、应急会商、能源交通、工业现场等场景后，需求已经发生明显变化。用户不仅希望“每个人都能看到文件”，还希望主席端可以一键发起同屏，所有参会终端同步看到某台电脑、某个应用、某路摄像机甚至某个业务系统的实时画面；需要会议终端在不同操作系统、不同CPU架构、不同显示设备之间协同运行；还要求系统能够在专网、内网甚至完全离线环境中部署，并兼顾权限、审计、录制和安全隔离。
这时候，无纸化会议的核心已经从 Document Distribution 转向了 Real-time Media Collaboration——实时媒体协同。
一套真正成熟的国产化无纸化会议系统，背后实际上同时存在三条技术链路：会议资料与业务数据链路、控制信令链路，以及实时音视频媒体链路。其中最容易被低估、同时又最决定用户体验的，恰恰是第三条。
从大牛直播SDK（SmartMediaKit）的角度看，这正是专业音视频技术进入无纸化会议系统的价值所在。
二、国产化真正困难的地方，在于底层异构而不是UI迁移
很多软件国产化项目最容易产生的误区，是认为把Windows程序重新编译到Linux，或者把原来的x86程序重新编译到ARM，就完成了国产化。
真实情况远比这复杂。
国产化环境意味着操作系统、CPU、GPU、硬件编解码器、显示驱动、浏览器内核以及系统多媒体框架都可能发生变化。目前银河麒麟等国产操作系统已经覆盖多种国产CPU平台，其官方资料显示，产品面向飞腾、鲲鹏、龙芯等平台，并在不同产品线上覆盖x86、ARM、RISC-V、LoongArch等架构。 统信UOS同样建立在Linux技术体系之上，并面向国产处理器及国产化软硬件环境进行适配。
这意味着音视频系统可能是：
Windows/x86 → 麒麟/ARM64
或者进一步变成：
Android/ARM → HarmonyOS NEXT/ARM + Surface/AVCodec
HarmonyOS NEXT自身也提供Camera、AVCodec、Media、Audio等媒体能力，音视频应用需要按照其原生媒体框架重新组织采集、编解码、播放和渲染链路。
因此，对一家做会议系统的厂商来说，最困难的并不是重新做几个按钮，而是底层媒体能力能不能跨平台保持一致。
SmartMediaKit长期采用的思路正好适合这一类场景：把RTSP、RTMP、HTTP-FLV以及WHEP/WHIP等协议处理，把H.264/H.265、AAC、G.711等媒体处理，把音视频同步、网络缓存、软硬解、像素转换以及渲染等能力尽可能沉到统一媒体内核中，上层应用更多负责会议业务逻辑。
这样做的价值在国产化过程中会被进一步放大。
三、“同屏”看起来简单，实际上是一条完整实时视频链路
用户点击一次“主席同屏”，从操作体验看只是一个按钮。
但从音视频工程角度看，它背后至少经历：
屏幕采集 → 图像预处理 → 视频编码 → 网络封装 → 媒体分发 → 网络接收 → 视频解码 → 图像渲染 → 显示同步。
假设主席电脑运行1920×1080、60fps桌面，仅按照BGRA原始图像计算：
1920 × 1080 × 4 × 60 ≈ 497MB/s
如果是4K：
3840 × 2160 × 4 × 60 ≈ 1.99GB/s
显然不能直接把原始桌面图像在会议室网络中广播出去，因此必须进行视频编码。
而一旦进入视频编码，又会引入另一个问题：延迟。
传统视频直播往往首先追求播放稳定，可以容忍数秒缓冲；会议同屏却完全不同。主席鼠标移动、翻页或者打开一张PPT以后，如果其他终端两三秒以后才变化，用户会明显感受到系统“很慢”。
因此，同屏会议真正需要优化的是：
Capture Delay + Encode Delay + Network Delay + Jitter Buffer + Decode Delay + Render Delay。
而不是单纯比较某个播放器“能不能播放H.264”。
这正是专业实时音视频SDK与普通播放器最大的区别之一。
对于局域网会议系统，工程目标往往应该从“秒级直播”转向百毫秒量级实时显示。与此同时，还必须避免为了降低延迟简单地把缓冲全部关掉，因为无线网络稍有抖动，画面就会出现卡顿、花屏甚至解码器等待关键帧的问题。
真正优秀的低延迟系统，本质上是在延迟、抖动容忍、丢包恢复、CPU占用和画面连续性之间寻找平衡点。
四、编码只是第一步，低时延真正考验整个媒体Pipeline
在无纸化会议场景中，H.264仍然是非常重要的基础编码格式。
原因并不复杂：兼容性好、硬件编解码覆盖广、生态成熟，对桌面分享这种大量文字、表格、线条和PPT内容的场景也比较友好。
国产化环境中尤其需要关注三个问题：终端是否具备稳定的H.265能力，GPU/VPU驱动是否成熟，以及操作系统暴露出来的硬件解码接口是否一致。
在Windows环境可以结合Direct3D等图形链路，在Android/HarmonyOS等移动平台则可以结合Surface和平台硬件解码能力，在Linux环境下根据实际GPU/VPU条件选择不同路径。对于无法保证硬解能力的平台，则仍然可以回落到软件解码。
更重要的是，播放器内部并不是简单的：
H.264 → Decoder → Screen
真正成熟的链路更接近：
Network → Demux → Video Packet Queue → Decoder → YUV/NV12 → GPU Texture → Render → Display
如果能够减少YUV/RGB之间不必要的数据转换和内存复制，并尽可能让解码输出直接进入GPU渲染路径，就能够同时降低CPU利用率、内存带宽和端到端延迟。
这也是为什么在音视频系统中，NV12、YUV420P、RGB、Surface、Texture这些看起来很底层的概念，最终会直接决定会议终端“顺不顺”。
五、会议系统选协议，不应该陷入“哪个协议最好”的误区
无纸化会议系统往往同时存在多种网络环境，因此很难依靠一种协议解决所有问题。
对于固定会议室和局域网同屏，RTSP依然具有很高的工程价值。它成熟、简单、容易部署，能够非常自然地构建：
主席端 → 会议媒体节点 → 参会终端
这样的拓扑。
SmartMediaKit长期支持RTSP播放，并支持TCP、UDP以及自动模式，因此对于局域网、专网和设备型场景，可以根据网络环境选择传输策略。结合轻量级RTSP服务，还可以让Android、Windows、Linux等设备直接成为媒体发布节点，而不一定依赖大型中心服务器。
RTMP的特点则不同。它的基础设施成熟、服务器生态完善，在需要录像、转发、跨网络汇聚或者与传统流媒体平台对接时依然具有实际价值。但如果目标是极低时延同屏，RTMP通常不应成为唯一选择。
HTTP-FLV更适合解决Web端和传统HTTP基础设施的兼容问题。
而当会议系统进一步走向浏览器化、跨网协同和亚秒级互动时，WHEP/WHIP的意义就会开始体现。浏览器、PC、移动终端甚至会议大屏，可以通过WebRTC媒体体系进入同一个实时媒体架构。
因此，更合理的架构不是押注一个协议，而是：
| 场景 | 更关注的技术目标 | 协议思路 |
|---|---|---|
| 本地会议室同屏 | 极低延迟、稳定 | RTSP/RTP类链路 |
| Web会议终端 | 浏览器兼容、低延迟 | WHEP/WebRTC |
| 传统平台汇聚 | 生态兼容 | RTMP |
| Web监看 | 部署简单 | HTTP-FLV |
| 多种终端混合 | 协议转换 | Media Server统一分发 |
SmartMediaKit的价值因此不是简单地“支持协议很多”，而在于可以把这些协议接入统一的音视频Pipeline，让上层会议系统不用围绕每一种协议重新实现一套播放器。
六、真正的同屏会议，还必须解决“时间一致性”
很多系统能够做到“大家都能看到”，却不一定能做到“大家同时看到”。
这是完全不同的技术问题。
如果会议室里有20台终端，每台终端根据自己的网络状态积累不同长度的缓存，就可能出现主席已经翻到下一页，而部分终端仍停留在上一页的情况。
对于普通直播来说，200ms、500ms甚至1秒的客户端差异未必明显；但同一个会议室中几十块屏幕同时摆在眼前，这种差异非常容易被观察到。
因此会议同屏需要关注两个层次。
第一层是单终端低延迟，尽可能降低采集、编码、网络、解码、渲染整条链路的延时。
第二层则是多终端一致性。
这需要播放器正确处理PTS/DTS、音视频时钟、网络抖动和渲染节奏，同时服务器侧也需要避免不同用户因为队列深度不同而不断积累延迟。
对于严重落后的终端，很多情况下“继续把历史帧慢慢播完”反而是错误策略，更合理的方法是根据实时媒体策略丢弃已经失去价值的数据，重新追赶直播点。
这也是实时会议和点播播放器之间一个非常本质的区别：
点播关注的是每一帧都不能丢；实时会议关注的是此刻看到的内容必须尽可能接近“现在”。
SmartMediaKit长期在低延迟播放、网络缓冲、关键帧处理、音视频同步和实时渲染方面积累的工程经验，在此类场景中的价值会远大于单纯的协议支持。
七、跨平台能力，决定国产化系统最终能不能真正落地
大型无纸化项目几乎不会只有一种终端。
主席台可能是Windows PC，普通会议终端可能是Android平板，会议室大屏可能运行Linux，移动领导终端可能是HarmonyOS或者iOS，一些可视化系统甚至基于Unity3D。
因此，真正有价值的媒体SDK必须解决一个问题：
同一条媒体流，在不同平台上保持尽可能一致的行为。
SmartMediaKit目前形成的Windows、Linux、Android、iOS、HarmonyOS NEXT以及Unity3D等多平台能力，在这种系统中具有非常明显的架构价值。
尤其值得注意的是国产Linux生态。
银河麒麟官方目前强调其桌面系统面向国产软硬件平台并支持多种处理器架构；其工业产品也已经覆盖x86、ARM、RISC-V和LoongArch等架构。
但这里必须强调一个非常重要的工程判断：
支持Linux，并不等于天然支持所有国产化平台。
例如x86_64 Linux程序迁移到ARM64，需要重新处理编译链、汇编优化、第三方库和硬件编解码；进一步迁移到LoongArch，还必须重新验证编译器、依赖库、SIMD优化以及GPU/VPU接口。
因此SmartMediaKit现有Linux、ARM64等能力更重要的意义，不是宣传一句“支持国产化”，而是已经建立了一套操作系统抽象层、媒体内核和平台适配层分离的架构基础。
真正的国产化适配应该逐个平台完成：
编译通过只是第一步，后面还要验证长时间播放、CPU占用、硬解稳定性、内存增长、多实例并发、网卡切换、GPU兼容以及异常网络恢复。
这才是工程意义上的国产化。
八、安全可控，应该从“媒体平面”重新设计
政务、央国企以及高等级会议系统还有一个明显区别：系统不能默认依赖公网云服务。
文件、音视频、会议控制数据甚至会议记录，都可能要求完全运行在本地机房或者专网中。
这恰好也是轻量化、自部署媒体架构的优势。
例如一套完整会议系统可以采用：
会议业务服务器 + SmartMediaServer媒体节点 + SmartMediaKit终端SDK
的方式构建。
会议业务服务器负责人员、议题、文件、权限和会议流程；媒体服务器负责实时流注册、转发、录制和会话管理；SmartMediaKit负责各类终端上的采集、推送、播放、硬解和渲染。
这样可以把媒体面和业务面适当解耦。
安全体系还可以继续向下延伸，包括TLS/HTTPS、鉴权Token、一次性播放地址、终端身份认证、访问控制、操作日志、会议水印、录制审计以及会后数据销毁。
如果项目本身要求国密体系，还可以在系统集成层进一步结合SM2、SM3、SM4以及国产密码模块完成认证、签名和数据保护。部分国产操作系统本身也已经提供国密及可信计算相关能力，例如银河麒麟服务器系统公开资料中即包含SM2及可信计算相关支持。
这里需要把边界讲清楚：
音视频SDK解决的是媒体实时性和媒体数据处理问题；身份体系、国密、会议权限和安全审计则应该由整个会议平台共同完成。
把所有功能强行塞进一个SDK，反而不是好的架构。
九、SmartMediaKit的优势，本质上是把“复杂媒体能力”变成基础设施
如果只从功能列表看SmartMediaKit，很容易把它理解成一个播放器SDK或者推流SDK。
但在国产化同屏会议这样的场景中，它更合适的定位其实是：
实时音视频基础能力层。
向上，上层应用不需要理解复杂的RTP、RTCP、SPS/PPS、PTS/DTS、关键帧、网络抖动和硬件解码问题，只需要通过统一接口完成播放、推流、录像、截图以及媒体数据回调。
向下，SmartMediaKit负责处理协议、编解码、缓冲、同步、像素格式和渲染等复杂问题。
目前SmartMediaKit已经能够覆盖RTSP、RTMP、HTTP-FLV等传统媒体体系，并持续向WHIP/WHEP等实时WebRTC体系扩展；视频侧覆盖H.264、H.265、MJPEG，音频侧覆盖AAC、PCMA、PCMU等，同时提供软硬解、YUV/RGB回调、Surface/Texture/OpenGL/D3D等不同播放和渲染路径。
这种能力在普通互联网直播产品中可能只是“功能很多”，但放到国产化会议系统中，其意义完全不同。
因为会议终端最大的现实问题就是异构。
当Windows、Linux、Android、HarmonyOS和iOS需要进入同一套会议系统时，如果每个平台分别维护一套媒体框架，后期测试和维护成本会快速失控。
统一媒体内核带来的真正优势，是：
上层业务不同，底层媒体行为尽可能一致。
尤其在HarmonyOS NEXT方向，SmartMediaKit已经围绕Surface硬件解码建立原生播放链路，在已有测试场景下实现约100～200ms级端到端体验。这类实践说明，真正影响国产化会议体验的往往不是UI框架，而是视频数据从网络包进入系统以后，能否高效穿过解码器、Surface和显示管线。
十、从无纸化会议走向智能会议，音视频会成为长期基础设施
未来几年，无纸化会议很可能还会经历一次更深层次的变化。
第一阶段解决的是：
Paper → Screen
第二阶段正在解决：
Screen → Real-time Collaboration
而下一阶段很可能是：
Real-time Collaboration → AI Meeting
会议摄像机、麦克风、主席同屏、远程参会、会议录制、本地文件，本质上都会成为AI系统的数据入口。
语音可以实时转写，会议内容可以自动摘要，摄像机画面可以进行人员检测和发言人识别，屏幕共享内容可以结合OCR和视觉大模型理解，录制的视频则可以进一步生成会议纪要、知识库和可检索的时间轴。
到了这个阶段，AI模型固然重要，但AI之前仍然存在一个非常现实的问题：
如何稳定、低延迟地把音视频数据送给AI。
摄像机采集、屏幕采集、编码、网络传输、解码、YUV/RGB转换、音频PCM获取、时间戳同步，这些看起来传统的技术，并不会因为大模型出现而消失。
相反，它们会成为AI系统最底层的数据基础设施。
这也是我们观察国产化无纸化会议市场时，一个容易被忽略的趋势：竞争的重点正在从“谁的会议界面功能更多”，逐渐走向“谁拥有更完整的实时媒体底座”。
对于SmartMediaKit而言，这恰恰是一个非常适合发挥多年技术积累的方向。
从RTSP、RTMP，到HTTP-FLV、再到WHIP/WHEP；从Windows、Linux，到Android、iOS、macOS、HarmonyOS NEXT；从软件解码，到硬件解码、GPU渲染；再从单纯的播放器、推流器，逐步走向轻量RTSP服务、实时媒体服务器以及未来AI媒体数据管线，其背后的技术演进实际上遵循着同一条主线：
把实时音视频能力做成可复用、可部署、可跨平台的基础设施。
国产化无纸化会议最终比拼的，也不会只是“有没有电子桌牌、能不能看PDF、能不能一键同屏”。
真正决定产品上限的，是当几十块屏幕、几种操作系统、多种CPU架构和不同网络环境同时存在时，系统依然能够做到：
画面传得过去、播放足够低延迟、终端保持同步、资源占用可控、长时间运行稳定，并且整个媒体链路能够掌握在自己的技术体系中。
这才是国产化无纸化同屏会议背后，真正值得长期投入的技术底座。
