一、为什么要重视鸿蒙 NEXT 下的音视频能力建设？

随着鸿蒙 NEXT 生态逐步走向独立演进，面向政企、能源、教育、医疗、应急、交通、军工、无纸化会议等行业场景，国产化系统平台的重要性正在持续提升。

对于实时音视频系统而言，操作系统不仅仅是一个运行环境，更是采集、编码、网络传输、渲染、权限、安全和设备能力调用的基础底座。尤其在国产化替代、信创终端适配、行业专网部署等场景中，是否具备鸿蒙 NEXT 原生音视频能力，已经逐渐成为 SDK 产品能否进入行业项目的重要前提。

大牛直播SDK（SmartMediaKit）在 Android、iOS、Windows、Linux 等平台已有成熟的 RTMP 推流、RTSP/RTMP 播放、轻量级 RTSP 服务、本地录像等模块。面向鸿蒙 NEXT，SDK 重点围绕推送端进行了系统性适配，逐步形成了以下能力组合：

1. 摄像头采集 + 麦克风采集 + RTMP 推流；
2. 屏幕采集 + 系统声音采集 + RTMP 同屏推送；
3. 采集端本地录像，支持 MP4 文件落盘；
4. 内置轻量级 RTSP 服务，可将采集流直接以 RTSP 方式对外分发；
5. 推流、录像、RTSP 服务可围绕同一采集源组合使用；
6. 支持软编码、硬编码以及 Surface 模式硬编码等不同编码路径；
7. 面向低延迟场景持续优化采集、编码、发送链路。

这类能力非常适合用于鸿蒙 NEXT 设备上的实时音视频采集、远程协作、国产化会议系统、移动执法、巡检终端、医疗会诊、教育录播、工业现场可视化等场景。

---

二、鸿蒙 NEXT 推送端整体能力概览

从产品能力看，大牛直播SDK 在鸿蒙 NEXT 下的推送端可以理解为一个“多源采集 + 编码封装 + 多协议输出 + 本地录像”的实时媒体内核。

典型链路如下：

摄像头采集 / 屏幕采集
        ↓
麦克风音频 / 系统声音采集
        ↓
音视频预处理
        ↓
H.264 / H.265 编码
        ↓
RTMP 推流 / 轻量级 RTSP 服务 / 本地 MP4 录像
        ↓
远端播放器 / 局域网客户端 / 录像文件回看

在实际项目中，开发者并不一定只需要单一能力。例如：

• 无纸化会议场景：需要屏幕采集 + 系统声音 + RTMP 同屏推送；
• 移动执法场景：需要摄像头采集 + 麦克风采集 + 实时推流 + 本地录像；
• 局域网巡检场景：需要设备端开启轻量级 RTSP 服务，局域网内客户端直接拉流；
• 医疗会诊场景：需要摄像头画面、麦克风声音、稳定录像和低延迟传输；
• 教育录播场景：需要屏幕内容、讲课声音、摄像头画面和录像归档。

因此，推送端能力的价值不只是“能推 RTMP”，而是能围绕真实业务形成稳定、低延迟、可组合的音视频链路。

---

三、RTMP 推流：面向公网和平台接入的主流低延迟链路

RTMP 仍然是很多直播平台、流媒体服务器、调度平台和业务系统接入的常用协议。对于鸿蒙 NEXT 设备来说，RTMP 推流能力可以将设备采集到的摄像头画面、屏幕内容、麦克风声音、系统声音等，实时推送到业务服务器。

大牛直播SDK 在鸿蒙 NEXT 下的 RTMP 推流模块主要关注以下几点：

1. 低延迟采集与编码链路
   尽量减少采集帧到编码器之间的拷贝和排队。
2. 稳定的音视频同步机制
   摄像头、屏幕、麦克风、系统声音等来源不同，时间戳管理必须清晰。
3. 适配鸿蒙 NEXT 权限与生命周期机制
   例如屏幕采集权限、麦克风权限、后台运行、横竖屏切换等。
4. 支持多种编码路径
   包括软件编码、硬件编码，以及更适合低延迟的 Surface 模式硬编码。
5. 便于上层 Demo 工程集成
   通过 ArkTS/ETS 封装业务控制逻辑，底层通过 Native 能力完成编码和推送。

一个典型的 ETS 层推流控制逻辑可以抽象如下：

async startRtmpPush() {
  if (this.isPushing) {
    return;
  }

  // 1. 初始化 Publisher
  let ret = SmartPublisherWrapper.open();
  if (ret !== 0) {
    console.error(`SmartPublisher open failed, ret=${ret}`);
    return;
  }

  // 2. 设置推流地址
  SmartPublisherWrapper.setRtmpUrl(this.rtmpUrl);

  // 3. 设置视频参数
  SmartPublisherWrapper.setVideoConfig({
    width: this.videoWidth,
    height: this.videoHeight,
    fps: 30,
    gop: 60,
    bitrate: this.videoBitrate
  });

  // 4. 设置音频参数
  SmartPublisherWrapper.setAudioConfig({
    sampleRate: 44100,
    channels: 1
  });

  // 5. 启动推流
  ret = SmartPublisherWrapper.startPublisher();
  if (ret !== 0) {
    console.error(`Start publisher failed, ret=${ret}`);
    SmartPublisherWrapper.close();
    return;
  }

  this.isPushing = true;
}

这里的代码只展示上层控制思路。真实工程中，还需要结合采集源状态、权限状态、横竖屏状态、编码模式、录像状态、RTSP 服务状态等进行更完整的状态管理。

---

四、轻量级 RTSP 服务：让鸿蒙设备成为局域网实时视频源

RTMP 更适合将流推送到服务器，而 RTSP 更适合局域网、专网、设备直连、安防监控、工业巡检等场景。

大牛直播SDK 在鸿蒙 NEXT 下支持轻量级 RTSP 服务能力。简单来说，鸿蒙设备不仅可以“推流到服务器”，也可以在本机启动一个轻量级 RTSP 服务，让局域网内的播放器、NVR、监控平台、测试工具直接拉取设备端实时流。

典型链路如下：

鸿蒙 NEXT 设备
  ├── 摄像头采集
  ├── 屏幕采集
  ├── 麦克风/系统声音采集
  ├── 编码
  └── 内置轻量级 RTSP 服务
          ↓
      RTSP 播放器 / 监控平台 / 局域网客户端

这种能力在很多行业场景中非常实用。

例如，在无纸化会议场景中，鸿蒙终端可以把当前屏幕内容通过 RTSP 分发给同一局域网内的大屏、会议主机或录制系统；在移动巡检场景中，终端可以将摄像头画面通过 RTSP 提供给附近的指挥终端；在设备调试场景中，工程师也可以直接用 RTSP 播放器拉取鸿蒙设备上的实时采集画面。

ETS 层可以将轻量级 RTSP 服务封装成一个独立按钮逻辑：

startRtspService() {
  if (this.isRtspServiceRunning) {
    return;
  }

  let ret = SmartPublisherWrapper.startRtspService({
    port: 8554,
    streamName: "live"
  });

  if (ret !== 0) {
    console.error(`Start RTSP service failed, ret=${ret}`);
    return;
  }

  this.isRtspServiceRunning = true;
  this.rtspUrl = `rtsp://${this.localIp}:8554/live`;

  console.info(`RTSP service started: ${this.rtspUrl}`);
}

在实际 Demo 中，可以将 RTSP 地址展示到界面上，方便用户复制到播放器中测试。

例如：

rtsp://192.168.1.100:8554/live

这种“设备即视频源”的能力，是鸿蒙 NEXT 在行业内网和国产化终端场景中非常有价值的一环。

---

五、推送端录像：实时链路之外的本地留存能力

对于行业场景来说，实时推送只是第一步，很多时候还需要本地录像。

比如：

• 执法过程需要留痕；
• 远程巡检需要归档；
• 医疗会诊需要保存过程；
• 教育录播需要课后回放；
• 会议同屏需要形成记录；
• 工业现场需要异常追溯。

因此，大牛直播SDK 在鸿蒙 NEXT 推送端也支持本地录像能力。录像可以与 RTMP 推流、轻量级 RTSP 服务并行工作，也可以单独使用。

典型控制逻辑如下：

startRecorder() {
  if (this.isRecording) {
    return;
  }

  const filePath = `/data/storage/el2/base/haps/entry/files/record_${Date.now()}.mp4`;

  let ret = SmartPublisherWrapper.startRecorder(filePath);

  if (ret !== 0) {
    console.error(`Start recorder failed, ret=${ret}`);
    return;
  }

  this.recordFilePath = filePath;
  this.isRecording = true;

  console.info(`Recorder started: ${filePath}`);
}

stopRecorder() {
  if (!this.isRecording) {
    return;
  }

  SmartPublisherWrapper.stopRecorder();

  this.isRecording = false;
  console.info(`Recorder stopped: ${this.recordFilePath}`);
}

在工程设计上，录像模块最好不要和推流按钮强绑定，而是作为一个独立能力存在。这样可以支持以下几种组合：

只推 RTMP
只启动 RTSP 服务
只录像
RTMP 推流 + 录像
RTSP 服务 + 录像
RTMP 推流 + RTSP 服务 + 录像

这种组合式能力，对于 SDK 产品化非常重要。因为不同客户的业务链路差异很大，SDK 不能只提供单一固定流程，而应该提供可组合、可裁剪、可集成的能力模块。

六、摄像头采集：面向移动直播、巡检和现场可视化

摄像头采集是推送端最常见的输入源。鸿蒙 NEXT 下，摄像头采集通常由 ArkTS 层调用系统 Camera Kit 完成预览、采集参数选择、前后摄切换、分辨率选择等逻辑，再将采集结果送入 SDK 的推送链路。

摄像头采集场景重点关注：

1. 采集分辨率和编码分辨率匹配；
2. 前置摄像头本地预览镜像逻辑；
3. 推流画面与本地回显的一致性；
4. 横竖屏方向处理；
5. Surface 模式硬编码下 producer 与 encoder surface 尺寸一致；
6. 后台返回后的相机恢复；
7. 摄像头切换后的编码器重配置。

在 Demo 工程中，可以将摄像头配置抽象为上层参数：

interface CameraPublishConfig {
  cameraPosition: 'front' | 'back';
  width: number;
  height: number;
  fps: number;
  enableMic: boolean;
  enableMirror: boolean;
  encoderType: 'soft_h264' | 'hw_h264' | 'hw_h265' | 'hw_h264_surface' | 'hw_h265_surface';
}

启动摄像头推送时，上层只关心业务配置：

async startCameraPublish() {
  const config: CameraPublishConfig = {
    cameraPosition: this.selectedCamera,
    width: this.selectedWidth,
    height: this.selectedHeight,
    fps: 30,
    enableMic: this.enableMic,
    enableMirror: this.enableFrontMirror,
    encoderType: this.selectedEncoderType
  };

  await this.cameraHelper.openCamera(config);
  SmartPublisherWrapper.configureCameraSource(config);
  SmartPublisherWrapper.startPublisher();

  this.isCameraPublishing = true;
}

底层则负责完成采集数据和编码推送链路的衔接。

对于行业客户而言，摄像头推送能力的价值不在于“能打开摄像头”，而在于能否长期稳定运行、能否适配不同设备、能否在横竖屏和前后摄切换时保持画面方向正确、能否做到低延迟和低功耗。

---

七、屏幕采集：无纸化会议和国产化办公场景的关键能力

屏幕采集是鸿蒙 NEXT 推送端非常重要的能力之一。

在无纸化会议、远程协作、国产化办公终端、教育培训、移动演示等场景中，用户希望将鸿蒙设备上的屏幕内容实时推送到远端播放器、大屏、会议系统或录制平台。

大牛直播SDK 在鸿蒙 NEXT 下支持屏幕采集推送，可以将屏幕图像编码后通过 RTMP 推送，也可以通过轻量级 RTSP 服务在局域网内分发，还可以同时进行本地录像。

屏幕采集链路通常如下：

AVScreenCapture
      ↓
屏幕图像帧
      ↓
编码器
      ↓
RTMP 推流 / RTSP 服务 / MP4 录像

如果需要采集系统声音，则还需要同时打通系统声音采集链路：

屏幕图像 + 系统声音
        ↓
音视频同步
        ↓
编码封装
        ↓
RTMP / RTSP / MP4

ETS 层可以将屏幕采集权限和推流动作拆开，避免用户每次横竖屏切换都重新授权：

async requestScreenCapturePermission() {
  if (this.hasScreenCapturePermission) {
    return;
  }

  const result = await this.screenCaptureAdapter.requestPermission();

  if (!result) {
    console.error('Screen capture permission denied');
    return;
  }

  this.hasScreenCapturePermission = true;
}

async startScreenPublish() {
  if (!this.hasScreenCapturePermission) {
    await this.requestScreenCapturePermission();
  }

  await this.screenCaptureAdapter.startCapture({
    enableSystemAudio: this.enableSystemAudio,
    width: this.captureWidth,
    height: this.captureHeight,
    fps: 30
  });

  SmartPublisherWrapper.configureScreenSource({
    width: this.captureWidth,
    height: this.captureHeight,
    fps: 30
  });

  SmartPublisherWrapper.startPublisher();

  this.isScreenPublishing = true;
}

屏幕采集相比摄像头采集更容易遇到横竖屏切换问题。比如设备从竖屏切到横屏后，采集分辨率发生变化，如果编码器、推流端、播放器端没有及时感知新的宽高，就可能出现画面拉伸、比例错误、局部黑边、花屏或播放端仍按旧分辨率显示的问题。

因此，屏幕采集 Demo 中建议把“采集状态”和“推流状态”解耦：

屏幕采集权限：只申请一次
采集源尺寸：可随横竖屏变化更新
编码器参数：根据实际采集宽高动态调整
推流状态：尽量不因为旋转而完全重启

这样可以减少用户感知上的中断，也更符合真实产品体验。

---

八、麦克风与系统声音：不同业务场景下的音频选择

鸿蒙 NEXT 推送端常见的音频来源主要有两类：

1. 麦克风采集
   适用于摄像头直播、移动执法、远程巡检、医疗会诊、教育讲解等场景。
2. 系统声音采集
   适用于屏幕同屏、会议演示、课件播放、终端操作录制等场景。

在 Demo 工程中，可以将音频源做成可选项：

enum AudioSourceType {
  None = 0,
  Microphone = 1,
  SystemAudio = 2,
  MicrophoneAndSystemAudio = 3
}

启动前根据用户选择设置音频采集方式：

configureAudioSource() {
  switch (this.audioSourceType) {
    case AudioSourceType.Microphone:
      SmartPublisherWrapper.enableMicrophone(true);
      SmartPublisherWrapper.enableSystemAudio(false);
      break;

    case AudioSourceType.SystemAudio:
      SmartPublisherWrapper.enableMicrophone(false);
      SmartPublisherWrapper.enableSystemAudio(true);
      break;

    case AudioSourceType.MicrophoneAndSystemAudio:
      SmartPublisherWrapper.enableMicrophone(true);
      SmartPublisherWrapper.enableSystemAudio(true);
      break;

    default:
      SmartPublisherWrapper.enableMicrophone(false);
      SmartPublisherWrapper.enableSystemAudio(false);
      break;
  }
}

需要注意的是，音频链路的稳定性对用户体验影响非常明显。视频偶尔卡顿，用户可能还能接受；但如果音频出现爆音、杂音、断续、不同步，就会明显影响业务可用性。

因此，在鸿蒙 NEXT 适配中，音频部分需要重点关注：

• 采样率是否统一；
• 声道数是否一致；
• PCM 格式是否明确；
• 是否按固定帧长送入；
• 音视频时间戳是否一致；
• 是否避免在实时回调中频繁分配内存；
• 是否处理好静音、停止、重启、后台恢复等状态。

---

九、推流、RTSP服务和录像的组合式工程设计

一个成熟的推送端 Demo，不应该只写成“点击开始推流、点击停止推流”的简单示例。更合理的方式，是把采集源、推流、RTSP 服务、录像拆成几个相对独立的状态模块。

可以抽象成如下状态：

interface PublishRuntimeState {
  captureStarted: boolean;
  rtmpPushing: boolean;
  rtspServiceRunning: boolean;
  recording: boolean;
}

启动 RTMP、RTSP、录像时，共享同一个 Publisher 实例或同一套采集链路：

ensurePublisherOpened() {
  if (this.publisherOpened) {
    return true;
  }

  let ret = SmartPublisherWrapper.open();
  if (ret !== 0) {
    console.error(`Open publisher failed, ret=${ret}`);
    return false;
  }

  this.publisherOpened = true;
  return true;
}

停止时则不能简单粗暴地直接 close，而应该判断是否还有其他业务在使用：

tryClosePublisher() {
  if (this.state.rtmpPushing) {
    return;
  }

  if (this.state.rtspServiceRunning) {
    return;
  }

  if (this.state.recording) {
    return;
  }

  if (this.state.captureStarted) {
    return;
  }

  SmartPublisherWrapper.close();
  this.publisherOpened = false;
}

这种设计对产品非常关键。

例如用户当前正在：

RTMP 推流 + 本地录像

此时点击“停止 RTMP 推流”，不应该把录像也停掉；同理，如果正在：

轻量级 RTSP 服务 + 本地录像

停止 RTSP 服务时，也不应该影响录像。

这类状态管理看似是 Demo 层逻辑，但实际上直接影响 SDK 在客户项目中的可集成性和稳定性。

---

十、鸿蒙 NEXT 下低延迟几个关键点

实时音视频系统的低延迟不是某一个接口决定的，而是采集、编码、传输、播放整条链路共同决定的。

在鸿蒙 NEXT 推送端，低延迟优化通常要关注以下几个方面。

1. 尽量减少采集到编码之间的拷贝

对于摄像头和屏幕采集，如果能够走 Surface 模式硬编码，可以减少 CPU 侧图像转换和拷贝压力。尤其在高分辨率、30fps 以上场景中，Surface 模式对性能和功耗都有明显意义。

但 Surface 模式也对尺寸、方向、生产者和编码器之间的匹配要求更严格，需要在工程上处理好分辨率、横竖屏和生命周期。

2. 编码器输出要及时 drain

低延迟场景下，不能只关注输入帧送入编码器，还要及时取出编码后的数据。如果输出端 drain 不及时，会造成编码器内部排队，最终表现为延迟增加。

理想状态下，输入和输出应该有清晰的线程或事件驱动机制，避免“等输入时错过输出”的问题。

3. GOP、码率和帧率要合理

例如 30fps 场景下，GOP 可以设置为 1 到 2 秒范围内。过大的 GOP 不利于快速首帧和异常恢复，过小的 GOP 会增加码率压力。

码率也要根据分辨率和场景动态设置。例如屏幕采集中文字、PPT、表格较多时，码率过低会导致细节模糊；摄像头场景中运动较多时，也需要适当提高码率。

4. 音频链路要固定帧长

麦克风或系统声音采集后，建议按固定帧长送入，例如 10ms 或 20ms 一帧。这样更利于音频编码、同步和缓冲控制。

5. 横竖屏切换要避免全链路重启

屏幕采集场景中，横竖屏变化很常见。如果每次旋转都重新申请权限、关闭 Publisher、重开编码器、重连 RTMP，会造成明显中断。

更合理的设计是：

屏幕采集权限保持
采集尺寸更新
编码参数按需重配置
播放端感知分辨率变化
业务状态尽量保持

这样才能接近真实产品体验。

---

十一、典型行业应用场景

1. 国产化无纸化会议

鸿蒙 NEXT 终端可以采集屏幕内容和系统声音，通过 RTMP 推送到会议服务器，也可以通过轻量级 RTSP 服务在局域网内分发给会议大屏或录制终端。

这种场景下，重点是：

• 屏幕采集稳定；
• 横竖屏切换自然；
• 系统声音同步；
• 延迟足够低；
• 可本地录像留档；
• 与国产化软硬件环境适配。

2. 移动执法与现场巡检

执法终端或巡检终端可以采集摄像头画面和麦克风声音，实时推送到指挥中心，同时本地录像留存。

关键价值包括：

• 实时回传现场画面；
• 本地录像作为证据链；
• 弱网场景下尽量保持稳定；
• 支持专网或局域网 RTSP 拉流；
• 适配国产化移动终端。

3. 医疗会诊与远程指导

医疗设备或移动终端可以采集摄像头画面、操作过程、讲解声音，并推送到远程专家端。

重点能力包括：

• 低延迟；
• 画面清晰；
• 音视频同步；
• 可录像归档；
• 可接入院内局域网系统。

4. 教育录播与培训演示

鸿蒙设备可以采集屏幕课件、系统声音和讲师麦克风声音，推送到直播平台或录制成 MP4 文件。

这种场景下，屏幕文字清晰度、音频稳定性和录像文件完整性非常关键。

---

十二、Demo 工程建议界面设计

为了方便客户理解 SDK 能力，鸿蒙 NEXT 推送端 Demo 可以设计成几个清晰区域。

1. 采集源选择

采集源：
[ 摄像头采集 ]
[ 屏幕采集 ]

2. 音频源选择

音频源：
[ 不采集音频 ]
[ 麦克风 ]
[ 系统声音 ]
[ 麦克风 + 系统声音 ]

3. 编码模式选择

编码模式：
[ 软编 H.264 ]
[ 硬编 H.264 ]
[ 硬编 H.265 ]
[ 硬编 H.264 Surface ]
[ 硬编 H.265 Surface ]

4. 业务能力控制

[ 开始 RTMP 推流 ]
[ 停止 RTMP 推流 ]

[ 启动轻量级 RTSP 服务 ]
[ 停止轻量级 RTSP 服务 ]

[ 开始录像 ]
[ 停止录像 ]

5. 状态展示

RTMP URL:
rtmp://xxx.xxx.xxx/live/stream

RTSP URL:
rtsp://192.168.1.100:8554/live

录像文件:
record_20260428_153000.mp4

当前状态:
采集中 / 推流中 / RTSP服务运行中 / 录像中

这种界面不只是 Demo，更像是一个小型推送端控制台。客户可以通过它快速验证 SDK 的核心能力，也方便后续集成到正式项目中。

---

十三、对国产化音视频 SDK 的几点思考

鸿蒙 NEXT 的价值，不只是“又多了一个平台”。对于实时音视频 SDK 来说，它代表着国产化终端生态中的一个重要基础入口。

未来很多行业项目可能会越来越关注：

1. 是否支持鸿蒙 NEXT 原生系统；
2. 是否支持摄像头、屏幕、麦克风、系统声音等完整采集能力；
3. 是否支持 RTMP、RTSP 等成熟协议；
4. 是否支持本地录像；
5. 是否支持内置轻量级流媒体服务；
6. 是否能适配国产化终端和内网环境；
7. 是否具备低延迟和长期稳定运行能力；
8. 是否具备清晰的 SDK、Demo、文档和远程技术支持体系。

大牛直播SDK（SmartMediaKit）在鸿蒙 NEXT 下持续补齐 RTMP 推流、RTSP/RTMP 播放、轻量级 RTSP 服务、录像、屏幕采集、摄像头采集、麦克风和系统声音采集等能力，本质上是在为国产化实时音视频场景提供一套更完整的基础能力。

---

十四、总结

基于鸿蒙 NEXT 的系统能力，大牛直播SDK 正在构建一套适合国产化终端场景的实时音视频推送端方案。

它不仅支持传统意义上的 RTMP 推流，还进一步扩展到：

摄像头采集
屏幕采集
麦克风采集
系统声音采集
H.264 / H.265 编码
RTMP 推流
轻量级 RTSP 服务
本地 MP4 录像
低延迟传输
国产化终端适配

对于开发者而言，这意味着可以在鸿蒙 NEXT 设备上更快速地构建实时直播、同屏推送、远程巡检、会议录制、教育培训、医疗会诊等业务系统。

对于行业客户而言，这意味着鸿蒙 NEXT 终端不再只是业务应用的承载设备，也可以成为实时音视频采集、编码、推送、分发和留存的一体化节点。

在国产化生态加速发展的背景下，围绕鸿蒙 NEXT 构建稳定、低延迟、可组合、可集成的音视频 SDK 能力，将会成为未来行业音视频系统建设中的重要方向。

---

📎 CSDN官方博客：音视频牛哥-CSDN博客