今天，我们来一起学习一下 WebRTC，相信你已经对这个前端音视频网红儿有所耳闻了。

WebRTC Web Real-Time Communication 网页即时通信

WebRTC 于 2011 年 6 月 1 日开源，并在 Google、Mozilla、Opera 等大佬们的支持下被纳入 W3C 推荐标准，它给浏览器和移动应用提供了即时通信的能力。

WebRTC 优势及应用场景

优势

• 跨平台(Web、Windows、MacOS、Linux、iOS、Android)
• 实时传输
• 音视频引擎
• 免费、免插件、免安装
• 主流浏览器支持
• 强大的打洞能力

应用场景

在线教育、在线医疗、音视频会议、即时通讯工具、直播、共享远程桌面、P2P网络加速、游戏(狼人杀、线上KTV)等。

（有喜欢玩狼人杀的同学吗？有时间可以一起来一局，给我一轮听发言的时间，给你裸点狼坑，一个坑容错。）

WebRTC 整体架构

拉回来，我们看一看 WebRTC 的整体架构，我用不同的颜色标识出了各层级所代表的含义。

• Web 应用
• Web API
• WebRTC C++ API
• Session Management 信令管理
• Transport 传输层
• Voice Engine 音频引擎
• Video Engine 视频处理引擎

我们再来看下核心的模块：

Voice Engine 音频引擎

VoIP 软件开发商 Global IP Solutions 提供的 GIPS 引擎可以说是世界上最好的语音引擎，谷歌大佬一举将其收购并开源，也就是 WebRTC 中的 音频引擎。

• iSAC：WebRTC 音频引擎的默认编解码器，针对 VoIP 和音频流的宽带和超宽带音频编解码器。
• iLBC：VoIP 音频流的窄带语音编解码器。
• NetEQ For Voice：针对音频软件实现的语音信号处理元件。NetEQ 算法是自适应抖动控制算法以及语音包丢失隐藏算法，能够有效的处理网络抖动和语音包丢失时对语音质量产生的影响。
• Acoustic Echo Canceler：AEC，回声消除器。
• Noise Reduction：NR，噪声抑制。

Video Engine 视频处理引擎

VPx 系列视频编解码器是 Google 大佬收购 ON2 公司后开源的。

• VP8：视频图像编解码器，WebRTC 视频引擎默认的编解码器。
• Video Jitter Buffer：视频抖动缓冲器模块。
• Image Enhancements：图像质量增强模块。

WebRTC 通信原理

媒体协商

媒体协商也就是让双方可以找到共同支持的媒体能力，比如双方都支持的编解码器，这样才能实现彼此之间的音视频通信。

SDP Session Description Protocal

媒体协商所交换的数据就是 SDP，说是协议，其实 SDP 并不是一个真正的协议，它就是一种描述各端“能力”的数据格式。

上图所示就是 SDP 的一部分，详细内容请参考：SDP: Session Description Protocol

https://tools.ietf.org/html/rfc4566

或者参考卡神的这篇文章：WebRTC：会话描述协议SDP

https://zhuanlan.zhihu.com/p/75492311

网络协商

ICE Interactive Connectivity Establishment 互动式连接建立

想要建立连接，我们要需要拿到双方 IP 和端口的信息，在当下复杂的网络环境下，ICE 统一了各种 NAT 穿越技术(STUN、TURN)，可以让客户端成功地穿透远程用户与网络之间可能存在的各类防火墙。

STUN、TURN

STUN：简单 UDP 穿透 NAT，可以使位于 NAT(或多重 NAT) 后的客户端找出自己的公网 IP 地址，以及查出自己位于哪种类型的 NAT 及 NAT 所绑定的 Internet 端口。

我们知道，NAT 主要有以下四个种类：

• 完全锥型 NAT
• IP 限制锥型
• 端口限制锥型
• 对称型

前三种都可以使用 STUN 穿透，而面对第四种类型，也是大型公司网络中经常采用的对称型 NAT ，这时的路由器只会接受之前连线过的节点所建立的连线。

那么想要处理这种网络情况，我们就需要使用 TURN (中继穿透 NAT) 技术。

TURN 是 STUN 的一个扩展，其主要添加了中继功能。在 STUN 服务器的基础上，再添加几台 TURN 服务器，如果 STUN 分配公网 IP 失败，则可以通过 TURN 服务器请求公网 IP 地址作为中继地址，将媒体数据通过 TURN 服务器进行中转。

信令服务器 Signal Server

拿到了双方的媒体信息(SDP)和网络信息(Candidate)后，我们还需要一台信令服务器作为中间商来转发交换它们。

信令服务器还可以实现一些 IM 功能，比如房间管理，用户进入、退出等。

小结

本文我们了解了 WebRTC 优势及应用场景、WebRTC 的整体架构及主要模块构成以及 WebRTC 的通信原理。这些基础知识和概念是需要我们牢记的，大家要记牢～

参考

• 《从 0 打造音视频直播系统》 李超
• 《WebRTC 音视频开发 React+Flutter+Go 实战》 亢少军
• https://webrtc.github.io/webrtc-org/architecture/
• https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API
• https://www.w3.org/TR/webrtc/

本文转自公众号“前端食堂”，作者霍语佳

作者：融云 WebRTC 高级工程师 苏道

音视频实时通话首帧的显示是一项重要的用户体验标准。本文主要通过对接收端的分析来了解和优化视频首帧的显示时间。

流程介绍

发送端采集音视频数据，通过编码器生成帧数据。这数据被打包成 RTP 包，通过 ICE 通道发送到接收端。接收端接收 RTP 包，取出 RTP payload，完成组帧的操作。之后音视频解码器解码帧数据，生成视频图像或音频 PCM 数据。

本文参数调整谈论的部分位于上图中的第 4 步。因为是接收端，所以会收到对方的 Offer 请求。先设置 SetRemoteDescription 再 SetLocalDescription。如下图蓝色部分：

参数调整

视频参数调整

当收到 Signal 线程 SetRemoteDescription 后，会在 Worker 线程中创建 VideoReceiveStream 对象。具体流程为 SetRemoteDescription

VideoChannel::SetRemoteContent_w 创建 WebRtcVideoReceiveStream。

WebRtcVideoReceiveStream 包含了一个 VideoReceiveStream 类型 stream_ 对象，通过 webrtc::VideoReceiveStream* Call::CreateVideoReceiveStream 创建。创建后立即启动 VideoReceiveStream 工作，即调用 Start() 方法。此时 VideoReceiveStream 包含一个 RtpVideoStreamReceiver 对象准备开始处理 video RTP 包。接收方创建 createAnswer 后通过 setLocalDescription 设置 local descritpion。对应会在 Worker 线程中 setLocalContent_w 方法中根据 SDP 设置 channel 的接收参数，最终会调用到 WebRtcVideoReceiveStream::SetRecvParameters。

WebRtcVideoReceiveStream::SetRecvParameters 实现如下:

void WebRtcVideoChannel::WebRtcVideoReceiveStream::SetRecvParameters(

    const ChangedRecvParameters& params) {

  bool video_needs_recreation = false;

  bool flexfec_needs_recreation = false;

  if (params.codec_settings) {

    ConfigureCodecs(*params.codec_settings);

    video_needs_recreation = true;

  }

  if (params.rtp_header_extensions) {

    config_.rtp.extensions = *params.rtp_header_extensions;

    flexfec_config_.rtp_header_extensions = *params.rtp_header_extensions;

    video_needs_recreation = true;

    flexfec_needs_recreation = true;

  }

  if (params.flexfec_payload_type) {

    ConfigureFlexfecCodec(*params.flexfec_payload_type);

    flexfec_needs_recreation = true;

  }

  if (flexfec_needs_recreation) {

    RTC_LOG(LS_INFO) << "MaybeRecreateWebRtcFlexfecStream (recv) because of "

                        "SetRecvParameters";

    MaybeRecreateWebRtcFlexfecStream();

  }

  if (video_needs_recreation) {

    RTC_LOG(LS_INFO)

        << "RecreateWebRtcVideoStream (recv) because of SetRecvParameters";

    RecreateWebRtcVideoStream();

  }

}

根据上图中 SetRecvParameters 代码，如果 codec_settings 不为空、rtp_header_extensions 不为空、flexfec_payload_type 不为空都会重启 VideoReceiveStream。video_needs_recreation 表示是否要重启 VideoReceiveStream。重启过程为，把先前创建的释放掉，然后重建新的 VideoReceiveStream。以 codec_settings 为例，初始 video codec 支持 H264 和 VP8。若对端只支持 H264，协商后的 codec 仅支持 H264。SetRecvParameters 中的 codec_settings 为 H264 不空。其实前后 VideoReceiveStream 的都有 H264 codec，没有必要重建 VideoReceiveStream。可以通过配置本地支持的 video codec 初始列表和 rtp extensions，从而生成的 local SDP 和 remote SDP 中影响接收参数部分调整一致，并且判断 codec_settings 是否相等。如果不相等再 video_needs_recreation 为 true。这样设置就会使 SetRecvParameters 避免触发重启 VideoReceiveStream 逻辑。在 debug 模式下，修改后，验证没有“RecreateWebRtcVideoStream (recv) because of SetRecvParameters”的打印, 即可证明没有 VideoReceiveStream 重启。

音频参数调整

和上面的视频类似，音频也会有因为 rtp extensions 不一致导致重新创建 AudioReceiveStream，也是释放先前的 AudioReceiveStream，再重新创建 AudioReceiveStream。参考代码:

bool WebRtcVoiceMediaChannel::SetRecvParameters(

    const AudioRecvParameters& params) {

  TRACE_EVENT0("webrtc", "WebRtcVoiceMediaChannel::SetRecvParameters");

  RTC_DCHECK(worker_thread_checker_.CalledOnValidThread());

  RTC_LOG(LS_INFO) << "WebRtcVoiceMediaChannel::SetRecvParameters: "

                   << params.ToString();

  // TODO(pthatcher): Refactor this to be more clean now that we have

  // all the information at once.

  if (!SetRecvCodecs(params.codecs)) {

    return false;

  }

  if (!ValidateRtpExtensions(params.extensions)) {

    return false;

  }

  std::vector<webrtc::RtpExtension> filtered_extensions = FilterRtpExtensions(

      params.extensions, webrtc::RtpExtension::IsSupportedForAudio, false);

  if (recv_rtp_extensions_ != filtered_extensions) {

    recv_rtp_extensions_.swap(filtered_extensions);

    for (auto& it : recv_streams_) {

      it.second->SetRtpExtensionsAndRecreateStream(recv_rtp_extensions_);

    }

  }

  return true;

}

AudioReceiveStream 的构造方法会启动音频设备，即调用 AudioDeviceModule 的 StartPlayout。AudioReceiveStream 的析构方法会停止音频设备，即调用 AudioDeviceModule 的 StopPlayout。因此重启 AudioReceiveStream 会触发多次 StartPlayout/StopPlayout。经测试，这些不必要的操作会导致进入视频会议的房间时，播放的音频有一小段间断的情况。解决方法同样是通过配置本地支持的 audio codec 初始列表和 rtp extensions，从而生成的 local SDP 和 remote SDP 中影响接收参数部分调整一致，避免 AudioReceiveStream 重启逻辑。另外 audio codec 多为 WebRTC 内部实现，去掉一些不用的 Audio Codec，可以减小 WebRTC 对应的库文件。

音视频相互影响

WebRTC 内部有三个非常重要的线程，woker 线程、signal 线程和 network 线程。

调用 PeerConnection 的 API 的调用会由 signal 线程进入到 worker 线程。

worker 线程内完成媒体数据的处理，network 线程处理网络相关的事务，channel.h 文件中有说明，以 _w 结尾的方法为 worker 线程的方法，signal 线程的到 worker 线程的调用是同步操作。如下图中的 InvokerOnWorker 是同步操作，setLocalContent_w 和 setRemoteContent_w 是 worker 线程中的方法。

bool BaseChannel::SetLocalContent(const MediaContentDescription* content,

                                  SdpType type,

                                  std::string* error_desc) {

  TRACE_EVENT0("webrtc", "BaseChannel::SetLocalContent");

  return InvokeOnWorker<bool>(

      RTC_FROM_HERE,

      Bind(&BaseChannel::SetLocalContent_w, this, content, type, error_desc));

}

bool BaseChannel::SetRemoteContent(const MediaContentDescription* content,

                                   SdpType type,

                                   std::string* error_desc) {

  TRACE_EVENT0("webrtc", "BaseChannel::SetRemoteContent");

  return InvokeOnWorker<bool>(

      RTC_FROM_HERE,

      Bind(&BaseChannel::SetRemoteContent_w, this, content, type, error_desc));

}

setLocalDescription 和 setRemoteDescription 中的 SDP 信息都会通过 PeerConnection 的 PushdownMediaDescription 方法依次下发给 audio/video RtpTransceiver 设置 SDP 信息。举例，执行 audio 的 SetRemoteContent_w 执行很长（比如音频 AudioDeviceModule 的 InitPlayout 执行耗时）, 会影响后面的 video SetRemoteContent_w 的设置时间。PushdownMediaDescription 代码:

RTCError PeerConnection::PushdownMediaDescription(

    SdpType type,

    cricket::ContentSource source) {

  const SessionDescriptionInterface* sdesc =

      (source == cricket::CS_LOCAL ? local_description()

                                   : remote_description());

  RTC_DCHECK(sdesc);

  // Push down the new SDP media section for each audio/video transceiver.

  for (const auto& transceiver : transceivers_) {

    const ContentInfo* content_info =

        FindMediaSectionForTransceiver(transceiver, sdesc);

    cricket::ChannelInterface* channel = transceiver->internal()->channel();

    if (!channel || !content_info || content_info->rejected) {

      continue;

    }

    const MediaContentDescription* content_desc =

        content_info->media_description();

    if (!content_desc) {

      continue;

    }

    std::string error;

    bool success = (source == cricket::CS_LOCAL)

                       ? channel->SetLocalContent(content_desc, type, &error)

                       : channel->SetRemoteContent(content_desc, type, &error);

    if (!success) {

      LOG_AND_RETURN_ERROR(RTCErrorType::INVALID_PARAMETER, error);

    }

  }

  ...

}

其他影响首帧显示的问题

Android图像宽高16字节对齐

AndroidVideoDecoder 是 WebRTC Android 平台上的视频硬解类。AndroidVideoDecoder 利用 MediaCodec API 完成对硬件解码器的调用。

MediaCodec 有已下解码相关的 API:

•  dequeueInputBuffer：若大于 0，则是返回填充编码数据的缓冲区的索引，该操作为同步操作。

• getInputBuffer：填充编码数据的 ByteBuffer 数组，结合 dequeueInputBuffer 返回值，可获取一个可填充编码数据的 ByteBuffer。

• queueInputBuffer：应用将编码数据拷贝到 ByteBuffer 后，通过该方法告知 MediaCodec 已经填写的编码数据的缓冲区索引。

• dequeueOutputBuffer：若大于 0，则是返回填充解码数据的缓冲区的索引，该操作为同步操作。

• getOutputBuffer：填充解码数据的 ByteBuffer 数组，结合 dequeueOutputBuffer 返回值，可获取一个可填充解码数据的 ByteBuffer。

• releaseOutputBuffer：告诉编码器数据处理完成，释放 ByteBuffer 数据。

在实践当中发现，发送端发送的视频宽高需要 16 字节对齐。因为在某些 Android 手机上解码器需要 16 字节对齐。Android 上视频解码先是把待解码的数据通过 queueInputBuffer 给到 MediaCodec。然后通过 dequeueOutputBuffer 反复查看是否有解完的视频帧。若非 16 字节对齐，dequeueOutputBuffer 会有一次 MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED。而不是一上来就能成功解码一帧。经测试发现，帧宽高非 16 字节对齐会比 16 字节对齐的慢 100 ms 左右。

服务器需转发关键帧请求

iOS 移动设备上，WebRTC App应用进入后台后，视频解码由 VTDecompressionSessionDecodeFrame 返回 kVTInvalidSessionErr，表示解码session 无效。从而会触发观看端的关键帧请求给服务器。这里要求服务器必须转发接收端发来的关键帧请求给发送端。若服务器没有转发关键帧给发送端，接收端就会长时间没有可以渲染的图像，从而出现黑屏问题。这种情况下只能等待发送端自己生成关键帧，发送个接收端，从而使黑屏的接收端恢复正常。

WebRTC内部的一些丢弃数据逻辑举例

Webrtc从接受报数据到、给到解码器之间的过程中也会有很多验证数据的正确性。

举例1

PacketBuffer 中记录着当前缓存的最小的序号 first_seq_num_（这个值也是会被更新的）。当 PacketBuffer 中 InsertPacket 时候，如果即将要插入的 packet 的序号 seq_num 小于 first_seq_num，这个 packet 会被丢弃掉。如果因此持续丢弃 packet，就会有视频不显示或卡顿的情况。

举例2

正常情况下 FrameBuffer 中帧的 picture id，时间戳都是一直正增长的。如果 FrameBuffer 收到 picture_id 比最后解码帧的 picture id 小时，分两种情况：

• 1. 时间戳比最后解码帧的时间戳大，且是关键帧，就会保存下来；

• 2. 除情况 1 之外的帧都会丢弃掉；

代码如下:

auto last_decoded_frame = decoded_frames_history_.GetLastDecodedFrameId();

auto last_decoded_frame_timestamp =

 decoded_frames_history_.GetLastDecodedFrameTimestamp();

if (last_decoded_frame && id <= *last_decoded_frame) {

if (AheadOf(frame->Timestamp(), *last_decoded_frame_timestamp) &&

   frame->is_keyframe()) {

 // If this frame has a newer timestamp but an earlier picture id then we

 // assume there has been a jump in the picture id due to some encoder

 // reconfiguration or some other reason. Even though this is not according

 // to spec we can still continue to decode from this frame if it is a

 // keyframe.

 RTC_LOG(LS_WARNING)

     << "A jump in picture id was detected, clearing buffer.";

 ClearFramesAndHistory();

 last_continuous_picture_id = -1;

} else {

 RTC_LOG(LS_WARNING) << "Frame with (picture_id:spatial_id) ("

                     << id.picture_id << ":"

                     << static_cast<int>(id.spatial_layer)

                     << ") inserted after frame ("

                     << last_decoded_frame->picture_id << ":"

                     << static_cast<int>(last_decoded_frame->spatial_layer)

                     << ") was handed off for decoding, dropping frame.";

 return last_continuous_picture_id;

}

}

因此为了能让收到了流顺利播放，发送端和中转的服务端需要确保视频帧的 picture_id, 时间戳正确性。

WebRTC 还有其他很多丢帧逻辑，若网络正常且有持续有接收数据，但是视频卡顿或黑屏无显示，多为流本身的问题。

Ending

本文通过分析 WebRTC 音视频接收端的处理逻辑，列举了一些可以优化首帧显示的点，比如通过调整 local SDP 和 remote SDP 中与影响接收端处理的相关部分，从而避免 Audio/Video ReceiveStream 的重启。另外列举了 Android 解码器对视频宽高的要求、服务端对关键帧请求处理、以及 WebRTC 代码内部的一些丢帧逻辑等多个方面对视频显示的影响。这些点都提高了融云 SDK 视频首帧的显示时间，改善了用户体验。

见过直播卖汽车、房子，甚至卖火箭的，但你见过直播卖 PaaS 云服务的吗？对，就是这样一款既不是实物，又无法直观展示的技术型产品，究竟在直播间里该如何来带货呢？近日，国内领先的互联网通信云服务商融云，联合趣配音、极客邦和三基同创等品牌举办了一次别样的直播带货，首度将虚拟的 PaaS 通信云服务在直播中进行售卖。

值得一提的是，此次直播在目睹、虎牙、斗鱼以及 B 站等平台进行了同步的直播，其中，仅在虎牙平台就吸引了超过 43000 名观众进行观看，引起了行业内外的广泛关注。为无数直播平台提供了通信云能力的融云，首次借助“直播带货”这一形式成功出圈，也将自己的产品价值全面地展现在客户面前。

最低 6 折起，首席产品推荐官诚意带货 

结合直播带货这种时下最流行的营销方式，融云将产品优势在直播间进行了全面展示，降低了客户的接受门槛，从产品特性到套餐优惠都非常透彻的进行了介绍，客户也可以直接参与到互动当中，进行现场提问，并得到实时解答。

在直播中，现场观众可以用全年最低价格来购买融云年中大促套餐，其中价格最低的套餐 6 折起售，包含了融云的 IM 即时通讯和 RTC 实时音视频两大业务线的优势产品，同时赠送价值上万元的服务大礼包。当然，更引人关注的是多轮次的抽奖环节，当天直播间的观众不仅享受到融云提供的专属优惠，很多人还抽中了掌上游戏机以及开发者必备的技术图书套装等奖品。

融云首席产品推荐官“三三”与融云 CTO 杨攀

可以说，这场直播带货既是融云在线上营销的一次新尝试，也是融云首席产品推荐官“三三”的上任仪式。整场直播虽然是为虚拟的 PaaS 通信云服务带货，却并不枯燥，作为融云的颜值担当，首席产品推荐官无论是在产品介绍上还是直播间气氛的引导上，都展现除了超高的专业水准。

更为重要的是，融云 CTO 杨攀也作为特邀主播参与了此次直播活动，他对于融云产品和技术的理解最为深刻，所以当他描述产品亮点时，可以让客户更加清晰地了解 PaaS 通信云服务的价值所在，甚至愿意在直播过程中进行合作确认。

创新与跨界，多品牌联动营销

事实上，在品牌营销的思路上融云也在寻求新突破。为了丰富此次直播带货活动的内容，给直播间观众带来更有价值的福利，此次直播融云特别邀请了趣配音创始人兼 CEO 谭美红、极客邦科技创始人兼 CEO 霍泰稳以及三基同创产品总监刘鸿浩等业界大咖参与，为直播间的观众们带来了趣配音 VIP 月卡、极客时间礼品卡、智能儿童手表等极具价值的礼品，引发了一波波的直播间互动热潮。

融云特邀嘉宾：谭美红、霍泰稳、刘鸿浩（右侧从上至下）

几位嘉宾们所代表的企业在各自领域均已是行业内的头部品牌，同时他们又有着同一个身份，即融云的优质客户及伙伴，与融云有着天然的紧密联系。受邀参与此次直播带货活动的嘉宾纷纷表示，这样形式的“直播带货活动”很新鲜，融云组织地非常的用心，从主播妙语连珠的串词到优惠套餐的推荐，可以看到融云举办此次活动的满满诚意，对于未来与融云的继续合作也更加有信心。

结语：

在疫情深刻影响社会的当前时刻，线上营销正在成为主流，融云也在不断地构建与创新着自身的营销方式。此次直播带货活动，通过与多个品牌的跨界联动，融云产生了更具张力的品牌联想，不仅带动了融云直播间的人气，还加深了品牌在客户心中的印象。未来，融云也将继续探索更多创新模式，让融云品牌深入到开发者群体中去，以稳定可靠的互联网通信云服务实现更多应用的价值赋能。

活动推荐：

实时音视频技术的专业度和复杂度都很高，通过 PaaS 服务商来集成实时音视频，快速开发 App，是时下开发者的优先选择。所选 RTC 是否好用易用、契合所需场景，将直接影响项目开发进度和后期运维成本。

开发者需要了解实时音视频技术选型中要避开的坑点，以便提高开发集成效率。具体来说，以下四个方面要综合考虑。

一、实时音视频与 IM 能力不宜分散

几乎 100% 的实时音视频在线应用都有文字/语音消息、文件传输、图片显示等 IM 需求。

目前市场上 PaaS 服务商这两方面能力强弱不一：有的大厂虽然两方面能力都提供，但不能确保两种能力同样高质量；有的专业 RTC 厂商，只能提供 RTC 能力，IM 能力还得由第三方专业服务商提供。

这样，便迫使开发者在集成过程中不得不分别选择服务商。当实时音视频与 IM 质量不稳定时，需要逐一协调各个服务商，逐一排查问题，无形中增加了后期的运营成本。其实，IM 和音视频在很多场景下有耦合，建议开发者在选型一开始就要考虑具有 RTC+IM 双重高保障能力的通信云厂商，尽量“用一套 SDK，解决所有通信场景”。

对开发者来说两项功能同时开发，开发包相对比较小；如果前期只用到了 IM，没有用到 RTC，那么只需要学习 IM 方面的开发文档就可以了，一旦有了 RTC 需求，再去学习 RTC文档，开发者只需接入相关接口，快速与 IM 能力做对接和匹配，即可完成两类功能在 App 生命周期里的全覆盖。

除了开发上的易快速上手外，选择“IM+RTC+推送”整合的解决方案，开发者还可以享受一致的网络架构，提高传输的效率和质量，获得一致的服务保障。例如，融云近期升级了实时音视频能力，RTC的通信信令是复用 IM 信令通道，可以确保消息 100% 的连通率和到达率，使底层的通信优势发挥到最大。

二、延时、卡顿、抖动的质量问题要解决好

通过调研发现，用户最不能接受实时音视频的三个质量问题是延时、卡顿、抖动。

低延时要靠两个方面解决，一个是传输协议，一个是优化整体传输环节。实时音视频的主流传输协议有 RTMP 和 UDP 两种，一种支持 CDN 技术，一种支持 WebRTC 技术,相对来说，CDN 技术延时性在 3-5 秒，WebRTC 可以在几百毫秒以内，现在很多厂商可以同时支持这两种技术，分别适用于不同的场景。

整体传输环节中，采集/渲染、编解码/网络往返都会有一定的延时,有些是硬件的物理延迟，需要靠 5G 这样底层网络技术的提升，或者布更多的数据中心、边缘结点，便于就近接入；有些要针对实际场景，在具体形态上做一些权衡，比如在处理粒度上粗细的考虑，越细的粒度传输的数据包相对较大，延迟也会更高。

当音视频出现卡顿时，有一个视频流畅优先的原则。我们通过降低一些码率和帧率，即使画面模糊一点，也要让用户视觉上是流畅不卡顿的。这样在选型时候，要考虑几个方面：一个是优化低码率下的视频清晰度；二是要有带宽估算能力，当预判到这个带宽没法承受高清晰视频传输时，自动转化成低码率并通过优化算法，使低码率视频清晰度能媲美高清视频。

另外，数据包通常会以错误的顺序到达，从而产生抖动相关问题，或者直接丢失，造成音视频空白。谷歌一份资料显示，视频聊天应用 Duo 99% 的通话都有数据包丢失、过度抖动或网络延迟情况。20% 的通话丢失了超过 3% 的音频，10% 的通话丢包率超过 8%，也就是说每次通话都有很多音频需要替换。

处理上述问题，很多厂商会采用抗丢包及抗网络抖动能力的 NACK（丢包重传）、FEC（前向纠错）、自适应带宽调整（动态调整码）、接收端 Jitter Buffer（媒体流平稳）等各种机制，有些是组合使用，有些是单独使用，开发者在选型前一定要做到深入了解。

• 拥有全球通信和场景化能力

    刚才谈到低延时、抗丢包的解决策略，有些是与网络接入路径长短直接相关的。比如中美两地的音视频连接，没有全球通信网络支持、数据中心和节点布局的厂商是提供不了服务的。开发者选型开发前，就要考虑到自己业务的所属范围。   

    选择全球化服务的云厂商，除了看数据中心和节点分布外，还要仔细考察全球网络布局的品质，简单说，有的厂商提供了全球网络优化能力，中美之间的音视频连接在未优化前要经过 100 多跳，而优化后仅 6 跳就能完成连通。这是由于，这些厂商拥有自有的路径最优算法，通过智能路由就近接入，即使在异国/地网络环境较差的情况下，仍然能够及时切换到更好的线路上去。比如融云拥有全球优化加速网络，实时音视频通话可做到全球端到端延时小于 400ms，最低延时 66ms，保障端到端之间延迟无感知的实时互动。

在场景化能力上，实际上相比 IM，实时音视频更加通道化，在各个场景中复用的程度也相对较高，能力也更基础。优秀的 PaaS 厂商会按场景提供不同的 Demo，音视频技术的升级也针对解决更多的应用场景去优化，便于开发者拿来即用，这种方式对入门级的开发者都十分友好。各种 API 接口相对独立，开发者只需关注和使用所需要的 SDK，就可以实现想要的场景，大大降低集成开发的难度。

四、开发者服务足够完善

在一些社区中，我们常常会看到一些技术文档下，开发者提出问题而没有回复。开发者为提高开发效率，越来越倾向于自助完成工作，因此，开发文档是否易懂，Demo 是否易用，都显得十分重要。

另外，工单回复的速度，微信群、社区的值守和响应程度等都能反映 PaaS 厂商服务意识的强弱。通常来说，7×24 小时技术支持服务，1 小时工单快速回复、快速远程接入、快速恢复的故障应急响应机制，这些都是对开发者很完善的服务支持。

有些厂商还会提供特色的质量监控服务，比如融云“北极星”的质量问题排查平台，通过可视化图表，快速定位卡顿位置，实时统计丢包率，使开发者可以自助排查每一次音视频通话过程中的丢包率、网络带宽等通信技术参数。可以直接定位用户问题，提高排查效率，提升用户体验。

【点击阅读原文】

最新活动推荐：

python能够支持视频的处理么？当然是肯定的，人生苦读，我用python。万物皆可python。

moviepy库安装

今天咱们需要使用的第三方是moviepy，moviepy是用于视频编辑的Python模块，可用于基本操作（例如剪切，串联，标题插入），视频合成（也称为非线性编辑），视频处理或创建高级效果。它可以读取和写入最常见的视频格式，包括GIF。

第一步：安装moviepy

安装的话首先需要使用pip命令进行安装

pip install moviepy

第二步：安装文本依赖库ImageMagick

安装完成后，我们需要安装依赖库，仅当我们要编写文本时，才严格要求ImageMagick。它也可以用作GIF的后端，但是可以在没有ImageMagick的情况下使用MoviePy进行GIF。我们将下载的exe文件双击运行即可。

第三步：配置路径

安装后，MoviePy将自动检测ImageMagick，但Windows除外！。Windows用户在手动安装MoviePy之前，进入moviepy/config_defaults.py文件并提供名为Magick的ImageMagick二进制文件的路径。它应该看起来像这样

这样我们的moviepy就算是完成安装好了。

使用方法

视频读取

VideoFileClip是从视频文件（支持大多数格式）或GIF文件读取的剪辑对象。可以按照以下方式加载视频：

myclip = VideoFileClip("菜鸟小白.wmv")

视频剪辑

可以通过subclip函数将视频的某几秒视频的剪出来

myclip2 = myclip.subclip(2,5)#将视频中2-5秒的内容剪切出来

将视频进行合并

列表中可以包含多个视频剪辑对象

final_clip = concatenate_videoclips([myclip2,myclip3]，method=‘compose’) #视频合并

需要注意的是：当视频列表中存在不同编码方式的视频对象时，

method=‘compose’是必要的，否则，如果输入编码方式不同的视频会报错。

对视频的播放区域进行剪辑

final_clip.crop(x_center=x_center, y_center=y_center, width=width, height=height)

改变视频的分辨率

final_clip.resize(newsize=(width, height))

将图片列表变为视频

其中images_list可以是图像名称列表，也可以是文件夹名称。提供文件夹名称或文件名称列表时，可以选择load_images=True指定所有图像都应加载到RAM中。同时所有图片都需要为同一个大小的图片

image_clip = ImageSequenceClip(['1.jpg','2.jpg','3.jpg'], fps=1)

将两个视频同时放在一个画面播放

CompositeVideoClip([myclip2.set_pos("left","center"),myclip3.set_pos("right","center")], size=(myclip2.w+myclip3.w, myclip2.h))

另外还支持渐进切换，下面示例说明myclip2对象在第5秒中切入，myclip3对象在第10秒中切入。

CompositeVideoClip([myclip2.set_start(5),myclip3.set_start(10)])

将多段视频以列表方式播放

final_clip = clips_array([[myclip2,myclip3],[myclip3,myclip2]])

————————————————

版权声明：本文为CSDN博主「菜鸟小白的学习分享」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_25535969/article/details/107305975

极客是一群什么样的人？他们大智若愚而富有科学精神，对一切常规的东西天然反感；他们天生热爱探索和创造，对于跟随和人云亦云深恶痛绝；他们特立独行，从不自我设置禁区；他们信仰自由，对于人为的限制极其不屑并热衷于挑战权威；在工作中他们推崇化繁为简，相信技术的力量并追求产品美学……

这是一个开发者们的技术乐园，也是国内首个全面覆盖了 IM、RTC 等通信云技术的极客社区。在移动互联网概念中，设想所有的客户端都“永远在线”，即每条消息发出必有回响。Online 既是一种态度，也是一种精神，正如 IM 所连接的每一个用户，极客永远在线。

不同于其他技术类社区体系的繁杂，GeekOnline 社区更专注于 IM 即时通讯、RTC 实时音视频以及与通信云相关领域的技术交流。在内容上 GeekOnline 社区提供了 IM、RTC、5G、出海等上百个热门话题让开发者们讨论和学习。目前 GeekOnline 社区与融云账号系统已全面打通，融云用户使用邮箱密码即可直接登录。

此外，关于更多互联网通信云领域的技术问题，开发者还可以通过社区中的“帮助”板块寻求解决。融云将 GeekOnline 社区打造成内容坚实的技术资料库，整理了针对通信云场景的各项技术资料，涵盖 IM 即时通讯、实时音视频、小程序、客服以及内容审核等众多维度。经过融云多年的技术积累，几乎所有关于通信云领域的常见问题都可以通过“帮助”板块来解决。

GeekOnline 社区上线初期就已经获得了国内外几十家社区及媒体伙伴的认可并建立了联系，其中包括开源中国、51CTO、SegmentFault、LiveVideoStack、ThoughtWorks 等国内外知名技术社区。

除此以外，还有多个活跃在技术社区的 KOL 已经入驻 GeekOnline，分享自己的经验观点并与用户们互动交流。还有一个秘密提前透露给你，一场由中国最专业的技术社区们共同发起的开发者活动，不久后也将与开发者朋友们见面。

相关调研数据显示，在技术开发过程中，大约 76% 的开发者都希望获得代码、数据的支持，而超过 81% 的开发者则需要更多技术经验和课程的学习。

在 GeekOnline 社区，开发者可以自行搜索想了解的问题，在技术大牛的文章或者问题回复中找到所需的答案，亦或是从其他人的讨论中获得新的灵感。如果在搜索结果中没有收获，还可以针对性地提出问题，@业界技术大牛来回复和解答。此外在疫情期间，不少开发者都面临着一些工作上的难题，在这里大家还可以“抱团取暖”，找寻新的合作点或者互相推荐工作机会。

在 GeekOnline 社区建设中，融云还将陆续注入更多资源，针对专属社区会员定制周边礼品，为开发者们提供专业技术类书籍、技术大会演讲 PPT 等资料下载，打造丰富多彩的开发者活动，并定期邀请来自于各领域的技术专家与开发者们在线上线下进行互动，期待有更多的开发者伙伴加入 GeekOnline，一起打造中国最 Geek 的技术社区。

传送门https://geekonline.rongcloud.cn/question/701

经历了疫情带来的半年“空窗期”，这个“618”购物狂欢节格外的热闹，各大电商平台和企业你方唱罢我登场。618当天，天猫和京东累计下单金额均创下纪录，分别为6982亿元和2692亿元。

而在国内疫情减弱后的首个全民大促节点，风口之上的电商直播带货也不出意外的从一众营销策略中脱颖而出。来自淘宝直播的薇娅在整个618活动共直播18场，累计带动GMV高达21.95亿；李佳琦直播带货GMV达13.35亿；快手辛巴6月14日创下直播带货新纪录，带货GMV12.5亿。

此外众多企业大佬和明星跨界直播，董明珠5场直播销售额超178亿，罗永浩抖音618当晚跨夜直播，斩获2597.3万.....电商直播成为当之无愧的主角，俨然成发展数字经济的新抓手。

在这些震撼人心的数据背后，是中国愈发庞大的电商直播用户群体，iiMedia Research(艾媒咨询)数据显示，2019年中国在线直播行业用户规模达5.04亿人，增长率为10.6%，而2020年用户规模预计达5.26亿人。

随着直播带货如火如荼的进行，如此大规模的用户量也给直播平台系统带来了更多挑战，一旦在实时互动中出现音视频不可用，高延时、高卡顿的情况，就会影响到直播的效果，如何用技术手段给用户以良好的观看体验，成为摆在电商直播行业面前的首要问题。

延时、高并发成为主要技术难题

在解决问题之前，我们首先需要了解下这些问题究竟是怎么产生的，以便对症下药。首先是音视频的延时问题，我们可以从一场电商直播中音视频流从主播端到用户端的传输过程来进行分析：

1、主播端延时

主播端的延迟很大程度来自视频流的前处理，例如开播时主播都会用到的美颜软件，美颜其实就是视频前处理的一种，在摄像头采集到人脸视频信息后，会先由美颜进行一个前处理工作，然后再将视频编码传送到服务器上，在这一过程中，无论是前处理还是编码都是需要耗费一定时间的。

2、传输过程延时

传输过程本身就因为网络状况等问题存在一定的延时，如果服务器与服务器之间的网络有丢包，或某台服务器负载过高，都会导致音视频的延时。

除此之外，编码压缩工作也还会耗费一定的时间，当然这部分时间根据不同厂商提供的平台能力、可用性都有些差别，这和系统架构设计、运维能力都息息相关。

3、用户端延时

用户端的延时一方面要考虑到用户的网络状况，另一方面也要考虑到用户的硬件系统能否支持，一些老旧的机型在进行解码处理时，由于CPU被大量占用，很容易发热发烫，导致手机卡顿。

直播的延时就是在这些过程中慢慢积攒的，美颜需要合成处理的时间、传输需要一定的时间，音视频压缩合成需要一定的时间，视频分发还需要一定的时间……在遇到网速和服务器出现问题时，延迟可能会进一步增加。

而电商直播系统开发中比较常见的“高并发”问题就比较好解释了。正常情况下，直播平台可以很稳定流畅地为用户提供服务。

但一旦遭遇618、明星直播等特殊情况，流量以平时的百倍、千倍甚至万倍的规模进入，所谓的高并发问题就出现了，如果在平台的开发过程中，没有考虑到并发量的问题，那么就会造成服务器的崩溃，导致观看失败，影响直播用户的使用体验。

WebRTC协议

解决直播延时的新武器

问题并非仅此而已，事实上当前中国仍旧有80%的移动环境处于弱网状态，基本上所有的移动直播，内容传输上都会很困难。相关数据显示，有超过7成的视频从业者认为，延迟和卡顿阻碍了直播行业的整体发展。

所以最理想的直播状态当然是在保证高清晰度的同时做到音视频的低延时和高流畅，这就意味着，延时最大不超过500ms，数值越小越好。而延时反应到包括电商直播在内的直播场景中时，主要看2个核心指标：首开时间和再缓冲时间。

首开时间即从打开到看到视频画面的时间，会受域名解析、连接、首包时间的影响，首播时间控制在1秒内算是不错的效果。其次是再缓冲时间，是用户观看视频时的卡顿时间。

既然延时对于直播如此重要，那么延时问题该如何解决呢？

其实，经过这些年的发展，我国的直播技术已经趋于成熟，通过多种专为流媒体开发的协议和技术手段来优化延时问题。经过多年的沉淀，目前国内主流的有RTMP和WebRTC两大阵营。

RTMP 对底层的优化非常优秀，适合长时间播放，同时它 Adobe Flash 支持好，基本上所有的编码器（摄像头之类）都支持 RTMP 输出。

另外RTMP最大的特点是与CDN的强绑定，借助CDN的负载均衡系统将内容推送到接近用户的边缘节点，使用户就近取得所需内容，提高用户访问的响应速度和成功率，解决因分布、带宽、服务器性能带来的访问延迟问题，目前RTMP一般延时在 3s 左右，对于标准的直播场景来说是够用的。

当然，虽然RTMP具备集成方便、兼容性较好等优势，但在延时问题上依然不能满足日益攀升的需求，于是WebRTC因其低延时和无卡顿的特性而备受关注。

WebRTC是一种基于浏览器的实时通信的开源解决方案，使用UDP私有协议来进行媒体推流，而不需要创建离散的媒体段；并且它是面向无连接的，没有TCP连接断开时的挥手确认连接关闭的机制。 

基于这两点，WebRTC能够做到毫秒级的低延迟，远远低于基于RTMP协议的 CDN 分发的延迟。而且，它直接通过浏览器就可以完成推流和播放。

因此，WebRTC协议针对有高互动性要求的电商直播场景尤为适宜。以我们熟知的淘宝直播为例，其在19年推出的超低延时直播服务RTS方案就是基于WebRTC实现的，可以为用户带来端到端延时1秒内的低延时直播体验。

当然WebRTC要实时超低延时也是需要多种技术来辅助的，RTS服务就针对全链路直播指标进行监控和针对性优化，以及通过智能调度系统以及网络拥塞、抗弱网优化、缓冲策略等进行一系列底层核心技术优化。

另外，国内知名的第三方通信云服务商融云提供的RTC解决方案也是基于WebRTC来实现的。在通信协议层面保障音视频传输的稳定性和流畅性。

同时在底层架构设计上，融云RTC智能路由可以在复杂的互联网环境下，实现客户端实时网络探测，选择最近的Media Server（媒体服务）节点接入，大幅度提升连接速度。

对于弱网下如何解决延迟问题，融云也提供了一些公开的策略供开发者参考。其中最核心的策略就是迅速预估带宽变化，根据带宽自动适配码率，来确保音视频流畅优先。

准确来说就是在网络链路发生丢包以前就监测到网络拥塞情况，再通过 NACK（丢包重传）、FEC（前向纠错）和动态调整码实现自适应带宽控制，以及通过接收端 Jitter Buffer（媒体流平稳）实现自适应抖动缓冲控制，在提升速度的同时保障通话质量。

融云自研的丢包补偿策略还可使接收端定期通知发送端自己未接收到的包，发送端在发送缓冲区找到对应的数据包，重新发送到接收端，确保音视频的传输质量。

通过这些先进的技术架构和自研的多项技术策略，融云音视频全球范围内的端到端延时小于 400ms，最低延时 66ms，从而保障端到端之间延迟无感知的实时互动。

高并发引出的架构话题

高并发问题主要是考验音视频服务的设计架构，是否能够在激增的流量冲击下实现平稳运行。

从直播角度上来讲，若在某个时间点，直播平台能够承载大量的线上观看人数而不影响播放品质，说明该平台在出现高并发情况时，优化的比较到位。

举个例子，某平台邀请流量鲜肉进行直播带货，由于用户涌入过猛（如观看人数上升，弹幕消息爆发等），很容易导致画面卡顿甚至导致服务器宕机。

所以在融云首席架构师李淼眼中，一个优秀的架构应该具备以下特征：

第一、伸缩性

伸缩性就是保证在业务不中断的情况下，可以平滑地进行各种服务。优秀的架构应该具备良好的伸缩性，所谓的“伸”，是系统在运行中业务量上来了，这个时候需要添加服务器，在业务不中断的情况下，可以平滑地把整个集群扩大，承载相应的业务量。

所谓的“缩”，是指在服务器处于空闲状态，保证业务不中断的前提下，可以把资源再降下来，避免浪费。

第二、高可用

当服务出现问题时，可提供容灾、自动切换、自动恢复等机制，减少停工时间，保证服务不间断地持续对外提供支持。

第三、扩展性

很多人容易混淆扩展性和伸缩性这两个概念。所谓扩展性，就是灵活地对业务进行变更。比如，在保证业务不中断的情况下，可以平滑的上线新功能，对用户来讲如果感知最小，那它的扩展一定很灵活。

第四、高性能

是指在固定的资源下可以承载更多的业务，这个也是开发人员一直追求的。

此外，服务器耦合的问题也在音视频架构中长期存在。业界现有的实时音视频普遍基于分布式有级联的 RTC 架构——信令服务器与媒体服务器紧密耦合，这种设计模式下如果媒体服务与信令服务之间存在异常状态，就会导致整个音视频通话中断，用户间信息传输的稳定性、可靠性难以保障。

但在融云实时音视频服务中，分布式的去中心化RTC通信架构可使信令服务与媒体服务解耦，彼此无依赖，确保当用户数激增或者流量激增的时候，能够快速的去扩展这些节点，很好地解决了延时和稳定性问题，保证直播业务能够稳定的运行。

对于电商直播的高并发，还有很重要的一点是直播间聊天室的属性实时同步的问题，在线人数、累计人数、商品链接与列表等信息，需要不断访问和请求服务器，并将数值进行返还，而数值频繁变化，无论是轮询还是通知，都有高并发压力。

所有在聊天室里面的需要展现的内容，都可以通过融云的聊天室属性管理服务来实现，无需频繁地访问服务器即可自动获取相关信息，可大大缓解电商平台的服务器压力。

电商直播不仅仅是音视频技术的应用

实际上，除了音视频技术来保障直播质量之外，电商直播对于即时通讯和推送同样有着极高的需求。

比如说，电商直播中的聊天室，让用户可以在弹幕上与主播和粉丝互动，这就是很纯粹的即时通讯技术应用，用户在直播间的提问、点赞、下单等行为背后都需要即时通讯技术，而用户收到直播通知、购买成功通知等App的推送消息，同样是需要即时通讯技术来实现。

因此在应用内构建一套完整的直播体系，需要实时音视频、即时通讯等多种能力。对于直播系统的开发人员，还有一个痛苦是：如果通信的能力是分散的，集成了不同的厂商，如果出现问题，就要找好几个服务商去协调，这是很常见的。

比如说直播平台有时候碰到一个通信层面的问题，因为IM和音视频在很多场景下它是有耦合的，例如呼叫的信令，一般会通过IM消息去下发，然后把音视频呼叫起来，媒体流再进行一些中转。

如果是IM和音视频分别由两个厂商来提供能力，出现了这些问题之后，平台就要找不同的厂商去判断。

所以在服务体系上面，对于开发人员来说成本也很高，所以从业务集成和服务这两个角度，其实使用同一个厂商的一套SDK，这些东西对于平台来说成本都是最低的，集成的效率也最高。

融云在近期全面升级实时音视频服务能力的同时，也推出了“IM+RTC+推送”的通信一体化解决方案，致力于用一套SDK解决电商直播等通信场景，充分满足电商直播业务中对于即时通讯与实时音视频的多元化需求。

例如知名奢侈品电商寺库的直播平台就是依托于融云互联网通信云来实现的，通过融云“IM+RTC+推送”的通信一体化解决方案，为用户带来了稳定流畅的直播体验。

同样是在618期间，广州直播电商狂欢节思埠专场在全网顶级网红的号召力下，有海量客户进入直播间互动并购买商品。

当接到客户的需求后，融云技术服务人员动态调整服务器部署，并针对客户实际情况量身定制相应的保障方案，帮助平台平稳度过业务峰值期，确保直播活动的顺利进行。

电商直播的未来在何方？

一方面，新技术将继续变革直播的形态。随着5G、超高清、VR、边缘计算等技术发展，低时延、大流量、高并发将成为常态，主播与观众的互动将更加实时、丰富和有趣。特别是5G时代的到来，无疑将会给电商直播带来全新的变革。

1.更清晰

此前，淘宝主播“大大大雪梨”在浙江完成了全国首场5G电商直播。据报道，通过超清4K画面，消费者不仅能看到直播间的整体情况，还可以对局部细节进行放大，让商品实时展示更为清晰、直观。

2.更快速

使用5G技术直播，相对4G而言，5G用户上行平均速率可达4G的十倍至百倍以上，现场每一帧直播画面都能实时传递。

3.低延时

即使是目前最先进的技术，在最优的网络环境下，直播延时也会达到几十毫秒，而5G的毫秒级低延时让人们几乎感受不到网络延迟的存在。

4.更稳定

4G时代的网络需要同时一起传输各种数据，这些数据会互相争夺挤占带宽资源，体验感会变差。

而5G切片技术的出现可以直接将一个物理通道分成多个虚拟通道，直播信号可专用其中一个资源独享的虚拟通道，实现固定带宽和高可靠性，能够保障视频直播的正常进行。

另一方面，融云在长期的市场观察中还发现了一个新的趋势：小程序正在成为直播带货的新战场。

当前，淘宝、抖音、快手等各大平台的直播带货如火如荼，头部和腰部主播的热度居高不下，坑位费普遍上涨，卖货的佣金比例也有所增加，按照二八法则，后入者的门槛相对变高。于是，不少商户和品牌主把小程序作为直播带货的第二战场。

艾媒咨询数据显示，2019年微信小程序电商用户预计将达2.40亿人。微信平台红利及小程序的诞生，为移动电商发展提供强大助力。

背靠微信成熟的生态和巨大的流量池，兼具强社交和易传播的优势，借力小程序高效连接线上和线下，把零售电商的核心要素充分联结起来，实现私域流量池的建立和变现。

无需安装、触手可及、用完即走、裂变分享，小程序直播，无疑将成为电商的必争之地。

2019年，融云发布了全新的实时音视频 RTC 3.0 版，以更高的技术稳定性、通信质量与灵活性，适应不同业务场景下一对一、多对多的实时音视频通信需求，为广大企业和开发者提供一个适配新通讯时代的选择。

为了帮助开发者们快速掌握 RTC SDK 的接入方式，融云推出了一款 Demo——SealRTC。SealRTC 是基于融云实时音视频 RTCLib SDK的最新版本开发实现的，可以进行实时音视频通话体验，主要用于验证 RTCLib SDK 的功能实践，为开发者提供集成参考，其功能包括：身份验证、音视频会议、双人和多人音视频通话、大小流切换等。

1、Demo 下载

这里我们以移动版 SealRTC 举例实操演示，此外融云官网还提供Web 端的在线体验，大家可以登录融云官网了解更多产品特性。


2、Demo 体验

①首先打开 SealRTC，通过输入房间号模式进行实时音视频通话体验，需要通过手机号来验证身份。


②开始音视频通话前，可以先对视频分辨率、美颜效果等基础属性进行设置。


可能有部分开发者朋友对于“大小流”这一概念比较陌生。这其实是一种视频带宽节省技术，音视频通话开启后不必获取参会人完整的视频流，而是通过小视频流来进行展现。举个例子，大小流类似于我们生活中常见的照片缩略图，这样即使在网络状况不佳的情况下也可以进行流畅的视频交流。

③通过验证并设置好基础属性后，即可进入音视频通话页面。


在屏幕右侧，增加了多个功能按钮，包括开启音乐和小视频、切换前后摄像头、使用互动白板等功能。在开启小视频后，左上角会出现小视频窗口，点击即可进行大小屏的切换。当结束通话时，点击最下方的红色电话标志，即可退出音视频会议。

结语：

作为全球互联网通信云领域的领跑者，融云在实时音视频市场拥有多年研发经验，各项技术指标保持市场领先水平，如提供一对一、多对多音视频通话能力，视频支持分辨率1080P高清画质，音频可对抗70%丢包，视频可对抗30%丢包，音视频延时最低可达66ms等等。目前，对于使用融云 RTC 3.0 及以上版本的开发者，融云不仅免收月功能费，现在每月还免费赠送 20,000 分钟通话时长。

当然，SealRTC 仅提供了最基础的音视频通话服务，如果大家想要在应用中集成更完善的实时音视频功能，请登录官网注册融云，下载 RTC SDK 来体验更丰富的产品功能吧。

几乎所有技术团队都经历过服务选型问题，在最常见的 3 大云服务交付模式（IaaS、PaaS、SaaS）中，PaaS 是目前市场上增速最快的交付模式，选型过程也是最令开发者头疼的。而相同问题往往不止一种解决方案，如何才能正确选择，少趟坑，是件烧脑的事情。那么我们究竟该如何做出正确的选择？下面就以 PaaS 层的互联网通信云服务为例，借助几个具有通用性的角度来告诉大家如何避坑。

一：功能的灵活性和易用性

互联网通信云服务通常是将 IM 和实时音视频技术封装成 SDK/API 交付给开发者使用，在 App 功能的开发中占据了非常重要的地位，特别是对于社交、直播等行业而言，通信能力就是命脉。如果选择了不适合或不能满足自己业务场景的功能，初期由于业务复杂程度和业务量都比较小，可能问题不会十分明显，但是到了后期这可能成为一个噩梦，会导致系统问题频发，极不稳定，甚至导致项目迭代举步维艰，有的团队会停止新功能的开发，专门修复 bug，给业务造成重大的经济损失。

因此，寻找能够满足适合自身业务场景的产品，能够灵活地进行二次开发，同时支持多平台和开发语言，是开发者前期调研中需要考虑的首要问题。通常意义上来讲，SDK 接口的数量在一定程度上代表了可实现功能量级的多寡，SDK 接口越多，开发者在功能实现上就有更多的选择空间，可以根据不同接口的组合来打造符合自身产品思路的功能。

但同时也要看到，有的服务商不断增加 SDK 接口数量，但这并不代表越多就一定越好，有可能让新接触的开发者越发混乱，无从选择。所以有些厂商直接将符合某一业务场景需求的十几个或几十个 SDK 接口，打包成一个解决方案供开发者使用，这样不仅避免了开发集成的复杂度，还提高了功能的易用性。

此外，SDK 的体积也是一个需要注意的点，过大的 SDK 会造成最终 App 体积也随之变大，这对于用户的下载体验非常糟糕，需要避免。

二：开发工具的完备性

灵活的功能性确保了项目开发从一开始就能够走在正确的道路上。接下来要考虑的是真正进入项目实施阶段，开发工具的完备性。开发工具既包括开发文档、SDK 注释等基础性文档，也包括 Demo、视频教程等多种支持性工具。

开发者在写代码的时候是很不喜欢被打断的，特别是一些基础性的开发问题，比如怎么创建 ID，怎么创建群组，有文档之后直接扔 URL 链接就行了。因此，一个易读易懂的技术开发文档将有助于 Coding 事半功倍。一个好的开发文档至少要做到结构简单、逻辑清晰。

所谓结构简单就是用户能马上找到自己要查找的知识点在哪，分类清晰。有些文档爱用模棱两可的词，比如“1.常见问题”，“2.热点问题”，一旦开发中遇到了问题，无法快捷查找答案，所以就需要将具体问题合理归类。另一点是逻辑清晰，这样可以让开发者减少对业务和交互的思考，更专注于技术的逻辑与实现。

除了开发文档外，SDK 注释是一种更简便的文档说明方式。不需要开发者翻阅大量的技术文档，通过完美的注释，直接在代码上就可以方便了解 SDK 功能。此外，还有 Demo 产品和视频教程等支持性工具，辅助开发者更好地理解和应用开发，避免不停的试错后才完成开发。


三：抗弱网环境和 QPS 承载能力的稳定性

产品稳定性至关重要，直接关乎用户体验。在地铁、电梯等相对密闭的弱网环境，常常面临信号不畅，App 稳定性失常、无法使用的问题。因此，开发者需要考虑的是，如果遭遇弱网环境，能不能在系统运行中通过最优算法实施智能调度，择优选择最佳链路进行用户无感知切换。

在平时业务压力不大的情况下，系统看似运行的很平稳了，但是当遇到双十一、大型直播、春晚等特殊事件，瞬时的激增流量有可能直接导致系统瞬间崩塌，那么，开发者在一开始选择的时候，就需要考量 QPS 承载能力，要求服务商必须有应对高并发的能力。此外，还要考核消息到达率和准确率，一些 App 中，消息“半路失踪”，漏发、错序的事件时有发生，这些大概率都因为架构设计存在缺陷，是 App 使用者所无法容忍的。

要规避上面的这些坑，需要有良好的系统架构做支撑。如果，开发者因为产品上线前的经验不足，导致产品在研发架构，或者风险漏洞方面存在隐患时，我们最好选择能够全程提供业务方案咨询和技术方案咨询服务的厂商，以他们的最佳实践帮助我们做出最优方案，在 App 上线前即规避可能存在的风险。

四：全球化能力

业务前景和技术前景也是开发人员应优先考虑的因素。比如初创企业优先布局在国内，但未来发展也许会出海，那么所选择的服务商就必须具备全球化服务能力。

想要拥有稳定的全球通信能力，不仅要有基础 IaaS 架构的支持，还要有海外数据中心、多路动态节点及稳定的全球链路做支撑，才可以有效解决跨国、跨运营商、大规模用户访问导致的响应慢、丢包高、服务不稳定等诸多痛点。

还有些服务商构建了私有加密协议的全球通信加速网络，针对性的进行全球链路优化，这对开发者来说，通信安全性和质量稳定性便有了双重保障。

五：服务

目前，绝大多数厂商都能给开发者提供便利的服务，以满足产品开发、上线前后以及产品运营阶段的各种需求。但也有极少数的厂商只提供 SDK 技术及开发文档，而后续无任何服务支持，这对开发者而言，当然不是一个好的选择。

虽然，知名度高一点的通信云服务商都提供 7*24 小时的运维保障服务，但仍有服务意识的强弱之分。以客服工单为例，业界平均工单回复时间为 4-6 小时，而优质的服务商则可以做到 1 小时内回复。

产品上线后，如果有自动故障排除工具类的服务支持，可以帮助开发者极大节省与厂商之间的沟通成本。除了这些工具类服务外，人的服务也是必备保障之一。比如，有的服务商从项目开发之前，便配备 CTO 或首席架构师级别的顶级技术团队进行全方位答疑，帮忙开发选择适合场景的技术架构和解决方案。还有的服务商，在项目上线运营时，针对可能出现的突发流量状态，通过人工方式帮开发者制定相应的保障方案，动态调整服务器部署，这样就可以有效地帮助开发者顺利避开“坑”点。

选型填“坑”后，最优性价比的胜出

价格将是选型过程中“最后的试金石”。通常来讲，选择好的技术和服务，意味着选择更多的成本投入，而在当下的复工复产期间，行业回暧需要过程，节省开支就成了企业发展中的头等大事，选型者往往因为价格因素，不得不退而求其次。

对于正处于选型当口的企业和开发者而言，好消息来了。互联网通信云行业的领导者融云针对全体开发者推出了“199 元 IM 商用版首购限量开放”活动，充值优惠有效期为 2020 年 5 月 1 至 12 月 31 日。这是融云自成立以来，推出的优惠幅度最大的一次活动，特别一提的是，由于疫情期间，受 IaaS 层带宽资源成本均有提升等多重因素影响，加之确保最后一公里通信的稳定、可靠、安全，绝不降品质的执着，融云为此承担了巨大的成本负担。但是，活动仍然不惜打破成本底线，以最大优惠让利于开发者，誓为全行业复工“输血”。也是因为以上原因，本次活动限量名额 1000 个，额满即止。了解更多详情请点此进入融云官方活动页面。


结语

总体说来，互联网通信云 PaaS 平台越来越成熟的技术能力为开发者提供了极大便利。作为技术选型，开发者根据自己的业务需求和行业特性，通过对通信云厂商在技术、服务、全球化方面的全面考量，再结合价格进行综合判断，答案自然水落石出。

近日，由艾瑞咨询旗下艾瑞研究院发起的“2020 艾瑞企业服务奖”评选结果正式揭晓，作为互联网通信云行业的领军企业，融云凭借着技术研发实力和优质服务，荣膺 2020 艾瑞“开发与技术企业服务奖”。与融云共同获奖的还有阿里云、百度、用友、360 等企业级服务的巨头。


近年来，随着人口红利消失，互联网流量见顶以及资本市场寒冬的影响，企业越来越注重内生增长，倡导业务的专业化、精细化，把大量的支撑性工作通过采购企业服务的形式来实现降本增效，企业服务因此逐渐受到创业者和投资人的广泛关注，服务形式日趋多样，服务规模不断壮大。特别是 2020 年，由于疫情的冲击，以提供互联网数字化产品和能力为特征的企业服务，更是迎来爆发式增长。

基于此，权威市场研究机构艾瑞咨询怀着“好服务应该被需要的企业知道并接受”这一初衷，开启“2020 艾瑞企业服务奖”评选活动。此次活动自 2020 年 3 月启动以来，众多行业的优秀企业参与了奖项申报，由艾瑞专家团队依据企业 2019 年产品版本迭代速度、产品美誉度、营收规模、整体客户数量、付费客户数量、续约率、功能完备度等指标综合评估，最终评选出在企业服务行业 14 个细分领域有突出贡献的杰出企业 84 家。此次荣膺 2020 艾瑞“开发与技术企业服务奖”，正是行业对于融云在品牌影响、技术研发和服务品质上的充分认可与肯定。

一直以来，在融云内部都有一个共识，“核心是技术，本质是服务。”这句话道出了融云高速成长背后所蕴含的企业发展之道。

在技术层面，融云依托于源自飞信团队和三星中国研究院的强大技术研发力量，不断提升产品的性能和场景支持能力。在这个过程中，融云 SDK 接口数量提升了 2 倍以上，并根据不同行业的属性，通过融云多年来的最优实践，形成模块化的行业场景解决方案，满足开发者快速集成，简捷可靠的需求。同时融云对性能的极致追求，使消息的接收速度提升了 30 倍，启动速度提升了 5 倍，智能设备能耗实现了 3 倍的优化，在技术标准上实现了在通信云赛道的领先。

在服务层面，融云是业内最先完成服务逻辑升维的通信云服务商，实现了从被动服务向主动服务，从接受客户提需求到主动和客户探讨需求的升级。通过磐石、锦囊等五大云服务体系，为客户产品提供全生命周期的护航式服务。同时融云将业界普遍的 4 小时工单回复升级为 1 小时内快速响应，并提供北极星质量问题排查平台，帮助客户快速定位并解决问题，提升客户的服务满意度，进一步夯实了融云的领先地位。

截止目前，已有汽车之家、丽兹行、寺库、哈啰出行、核桃编程、易车网、编程猫以及 Castbox、Opera 等超过 30 万款海内外 App 通过融云实现了全球化的互联网通信能力，根据艾瑞发布的《2019 年全球互联网通信云行业研究报告》显示，融云在 IM 即时通讯领域稳居市场份额第一。而融云也将以本次上榜为契机，继续加强在产品研发上的投入，不断迭代和升级技术能力，提升产品的安全性、稳定性，为开发者们提供更便捷、更贴心的服务。

为了更好地助力各行业在疫情期间实现高效的复工复产，拓展新的发展机遇，融云在日前还特别推出了“199 元 IM 商用版首购专享”活动，希望以通信云技术赋能各行业，助力全行业业务回暖。此次活动针对全体开发者，无论是个人用户还是企业用户，只要新注册并充值 199 元即可获得价值 1500 元/月的IM商用版服务，限量 1000 个名额，购完即止，先到先得！