1.直播流程

采集
音视频编码： 一般采用硬编
推流
流媒体服务器处理
拉流
音视频解码
播放

直播视频编码

直播推流视频编码是将音视频数据进行压缩和编码，然后通过网络传输到观众端的过程。常用的直播推流视频编码有以下几种：

H.264/AVC：H.264是目前最为广泛使用的视频编码标准之一，它具有较高的压缩效率和良好的视觉质量，适用于各种网络环境下的直播推流。

H.265/HEVC：H.265是H.264的升级版本，相比于H.264，它可以进一步提高压缩效率，降低带宽消耗，但同时也会增加编码和解码的计算复杂度。

VP9：VP9是由Google开发的开源视频编码器，具有良好的压缩性能和视频质量，适用于WebRTC等网络上的实时通信。

AV1：AV1是一种开源的视频编码标准，由Alliance for Open Media（包括Google、Apple、Microsoft等公司）开发，旨在提供更高的压缩比和更好的视觉质量。

硬编码
视频: VideoToolBox框架
音频: AudioToolBox 框架
软编码
视频: 使用FFmpeg,X264算法把视频原数据YUV/RGB编码成H264
音频: 使用fdk_aac 将音频数据PCM转换成AAC

直播音频编码

1. AAC（Advanced Audio Coding）： AAC 是一种高级音频编码格式，广泛应用于音频和视频领域。它具有较高的音频质量和压缩效率，是目前最常用的音频编码格式之一。AAC 提供了多个配置选项，包括不同的比特率、采样率和声道数，以适应不同的实际需求。

2. MP3（MPEG-1 Audio Layer 3）： MP3 是一种流行的音频编码格式，广泛应用于音乐和音频文件。虽然相对于 AAC，MP3 的压缩效率较低，但它支持广泛的平台和设备，同时保持良好的音频质量。

3. Opus： Opus 是一种开放标准的音频编码格式，被认为是网络语音通信的最佳选择。它提供了出色的音频质量、低延迟和较高的压缩效率，适用于实时通信场景，如直播和语音聊天。

4. PCM（Pulse Code Modulation）： PCM 是一种无损音频编码格式，在直播中很少使用。它将音频数据以原始的脉冲编码形式进行存储和传输，保留了音频的完整质量。由于 PCM 产生的数据量较大，一般需要进行压缩或转换为其他格式才能用于直播推流。

直播视频封装格式

视频封装格式是一种将视频和音频数据进行组合、压缩和打包的文件格式。它不仅包含了视频和音频数据流，还可以包括字幕、元数据和其他相关信息。视频封装格式的主要作用是将多媒体数据打包成一个单独的文件，在存储、传输和播放过程中提供统一的接口和结构。

视频封装格式和视频编码之间存在紧密关系。视频编码器通常会将原始视频数据进行压缩和编码，并将编码后的数据打包到视频封装格式中。封装格式提供了容器来存储编码后的视频数据、音频数据和其他相关信息，并定义了如何在播放器或解码器中进行解析和回放。

AVI: 是当时为对抗quicktime格式（mov）而推出的，只能支持固定CBR恒定定比特率编码的声音文件
MOV:是Quicktime封装
WMV:微软推出的，作为市场竞争
mkv：万能封装器，有良好的兼容和跨平台性、纠错性，可带外挂字幕
flv: 这种封装方式可以很好的保护原始地址，不容易被下载到，目前一些视频分享网站都采用这种封装方式
MP4：主要应用于mpeg4的封装，主要在手机上使用。

直播音频封装格式

1. AAC（Advanced Audio Coding）： AAC 是一种常用的音频编码格式，同时也可以作为音频封装格式。AAC 可以以不同的容器格式来封装音频数据，如 MP4、FLV、ADTS 等。AAC 封装格式通常被广泛应用于流媒体直播和点播场景，提供了高质量的音频编码和广泛的设备兼容性。

2. MP3（MPEG-1 Audio Layer 3）： MP3 是一种流行的音频编码格式，它也可以作为音频封装格式使用。MP3 封装格式通常与 MP3 音频编码结合使用，在一些旧版的流媒体直播系统或特定音频应用中仍然存在。

3. Ogg： Ogg 是一种开放的多媒体封装格式，它支持音频、视频和字幕等多种类型的媒体。在直播中，Ogg 封装格式经常与 Vorbis 编码的音频数据结合使用，形成 Ogg/Vorbis 封装格式，用于实时流媒体传输。

4. WebM： WebM 是一种开放的音视频封装格式，由 VP8 或 VP9 视频编码和 Opus 音频编码组成。WebM 封装格式在基于 Web 的直播中得到广泛应用，特别是在使用 VP8 或 VP9 编码的情况下。

直播推流协议

1. RTMP（Real-Time Messaging Protocol）： RTMP 是一种实时消息传输协议，广泛应用于流媒体直播。它使用 TCP 协议进行数据传输，并提供了实时性较好的音视频流传输能力。RTMP 是一种较早的推流协议，在过去的直播领域中应用广泛。

2. HLS（HTTP Live Streaming）： HLS 是基于 HTTP 的流媒体传输协议，特别适用于移动设备和浏览器上的直播。HLS 将视频切片为多个小文件，通过 HTTP 协议动态下载和播放，具有较好的兼容性和自适应能力。

3. DASH（Dynamic Adaptive Streaming over HTTP）： DASH 也是一种基于 HTTP 的自适应流媒体传输协议，类似于 HLS。DASH 将视频切片为多个小文件，每个文件包含不同质量的视频内容，通过 HTTP 动态选择最佳质量的视频进行播放。

4. WebRTC（Web Real-Time Communication）： WebRTC 是一种支持浏览器之间实时通信的技术，也可用于直播推流。WebRTC 使用 UDP 或 TCP 协议进行音视频传输，具有较低的延迟和高质量的传输能力。

5. SRT（Secure Reliable Transport）： SRT 是一种可靠且安全的传输协议，适用于直播和实时视频传输。SRT 提供了抗网络抖动和丢包的功能，并支持加密和认证，以确保传输的稳定性和安全性。

H.264视频编码

I帧: 关键帧,采用帧内压缩技术.

举个例子,如果摄像头对着你拍摄,1秒之内,实际你发生的变化是非常少的.1秒钟之内实际少很少有大幅度的变化.摄像机一般一秒钟会抓取几十帧的数据.比如像动画,就是25帧/s,一般视频文件都是在30帧/s左右.对于一些要求比较高的,对动作的精细度有要求,想要捕捉到完整的动作的,高级的摄像机一般是60帧/s.那些对于一组帧的它的变化很小.为了便于压缩数据,那怎么办了?将第一帧完整的保存下来.如果没有这个关键帧后面解码数据,是完成不了的.所以I帧特别关键.
P帧: 向前参考帧.压缩时只参考前一个帧.属于帧间压缩技术.

视频的第一帧会被作为关键帧完整保存下来.而后面的帧会向前依赖.也就是第二帧依赖于第一个帧.后面所有的帧只存储于前一帧的差异.这样就能将数据大大的减少.从而达到一个高压缩率的效果.
B帧: 双向参考帧,压缩时即参考前一帧也参考后一帧.帧间压缩技术.

B帧,即参考前一帧,也参考后一帧.这样就使得它的压缩率更高.存储的数据量更小.如果B帧的数量越多,你的压缩率就越高.这是B帧的优点,但是B帧最大的缺点是,如果是实时互动的直播,那时与B帧就要参考后面的帧才能解码,那在网络中就要等待后面的帧传输过来.这就与网络有关了.如果网络状态很好的话,解码会比较快,如果网络不好时解码会稍微慢一些.丢包时还需要重传.对实时互动的直播,一般不会使用B帧.
如果在泛娱乐的直播中,可以接受一定度的延时,需要比较高的压缩比就可以使用B帧.
如果我们在实时互动的直播,我们需要提高时效性,这时就不能使用B帧了.

大家只要记住,在一组帧之前我们首先收到的是SPS/PPS数据.如果没有这组参数的话,我们是无法解码.

所以总结起来,花屏是因为你丢了P帧或者I帧.导致解码错误. 而卡顿是因为为了怕花屏,将整组错误的GOP数据扔掉了.直达下一组正确的GOP再重新刷屏.而这中间的时间差,就是我们所感受的卡顿

WebRTC（Web Real-Time Communication）之所以具有低延迟的特性，是因为它采用了一些优化技术和协议来提供实时通信能力。

下面是一些导致 WebRTC 延迟低的关键因素：

1. P2P（点对点）通信： WebRTC 使用了点对点的通信模型，允许直接在浏览器之间建立连接，而不需要经过服务器的中转。这消除了传统客户端-服务器-客户端通信模型中的中心化延迟，减少了数据传输的跳数和网络拥塞的潜在影响。

2. UDP 传输： WebRTC 使用 UDP（User Datagram Protocol）作为传输协议，而不是 TCP（Transmission Control Protocol）。相比于 TCP 的可靠传输，UDP 提供了更低的延迟和更高的吞吐量。尤其在实时通信场景下，UDP 具有更好的实时性能。

3. 媒体流优化： WebRTC 对音频和视频流进行优化，使用了编解码器、流量控制、拥塞控制和抖动缓冲等技术来提供更好的实时媒体传输性能。例如，使用有效的编解码器可以减小数据包大小，从而减少传输延迟。另外，拥塞控制算法可以根据网络条件动态调整传输速率，以避免网络拥塞导致的延迟增加。

4. ICE（Interactive Connectivity Establishment）： WebRTC 中使用 ICE 协议来建立和维护对等连接。ICE 通过候选地址探测、NAT 穿越和转发等技术，帮助浏览器找到最佳的通信路径，减少通信延迟。

总之，WebRTC 的设计和实现考虑了实时通信的特殊需求，采用了一系列优化技术和协议，从而实现了低延迟的实时通信能力。这使得 WebRTC 成为构建实时音视频通话、会议和其他实时应用的理想选择。

CDN 拉流是指从 CDN（Content Delivery Network，内容分发网络）服务器上获取媒体流数据的过程。在音视频直播或点播中，通常会使用 CDN 来提供高质量的内容分发和传输服务。

拉流是客户端从 CDN 服务器主动请求并获取媒体流数据的操作。具体步骤如下：

客户端（例如播放器应用）向 CDN 服务器发送一个拉流请求。
CDN 服务器接收到请求后，根据请求的 URL 或其他标识确定要提供的媒体流。
CDN 服务器将媒体流数据分发到离用户最近的边缘节点或缓存服务器。
客户端通过网络连接到离其最近的 CDN 边缘节点或缓存服务器，并开始拉取媒体流数据。
CDN 服务器将媒体流数据逐个数据包地传送给客户端。
客户端接收到媒体流数据后，进行解码和播放操作，实现音视频的展示。
通过使用 CDN 拉流，可以实现以下优势：

降低延迟： 由于 CDN 分布在全球各地并与用户更近，通过就近获取媒体流数据，可以减少传输延迟，提高播放效果。
提供高可用性： CDN 服务器通过复制和分发媒体流数据，提供高可用性和容灾能力，以应对服务器故障或网络拥塞等问题。
节省带宽消耗： CDN 可以缓存媒体流数据，使得多个用户可以共享同一份数据，从而减少总体的带宽消耗。
总之，CDN 拉流通过就近分发、缓存和高可用性等特性，提供了高效、稳定和低延迟的媒体流传输服务，为用户提供了更好的音视频体验。

WebRTC 和 CDN 拉流是两种不同的技术和传输方式，有以下主要区别：

1. 实时性和互动性： WebRTC 主要用于实时通信场景，如音视频通话、视频会议、实时游戏等，具有较低的延迟和高度的互动性。WebRTC 使用点对点（P2P）连接，直接在浏览器之间传输数据，避免了中心服务器的中转，从而减少了延迟。

CDN 拉流主要用于音视频直播和点播场景，其中实时性要求相对较低。CDN 通过在全球各地分布的服务器缓存和分发媒体流数据，提供高可用性和高质量内容分发服务。虽然 CDN 能够提供较低的延迟，但与 WebRTC 相比，其实时性和互动性较差。

2. 传输方式： WebRTC 使用实时数据传输协议（Real-Time Transport Protocol，RTP）来传输音视频数据。它使用 UDP 传输协议，以实现更低的延迟，并支持拥塞控制和丢包恢复机制。

CDN 拉流通常使用 HTTP 协议或类似的传输协议来传输音视频数据。它可以使用标准的 HTTP 或 HTTPS 连接进行数据传输，利用现有的网络基础设施和缓存机制。

3. 部署和管理： WebRTC 需要在每个客户端浏览器上支持和实现相关功能，包括媒体处理、网络连接等。这意味着需要额外的开发和管理工作，并且对浏览器的兼容性有一定要求。

CDN 拉流则是以服务器为中心进行部署和管理。内容提供商将媒体流数据上传到 CDN 服务器并配置相应的分发策略，用户通过 CDN 边缘节点或缓存服务器获取媒体流数据。

综上所述，WebRTC 和 CDN 拉流适用于不同的场景和需求。WebRTC 更适合实时通信和互动场景，而 CDN 拉流更适合音视频直播和点播场景，提供高可用性和广域分发能力。

是的，可以在直播中同时使用 WebRTC 和 CDN 以满足不同的需求。通常情况下，主播端使用 WebRTC 进行实时音视频采集和传输，而观众端则可以使用 CDN 拉流来接收和播放音视频数据。

主播端采用 WebRTC 的好处包括：

较低的延迟： WebRTC 可以提供较低的延迟，使主播的音视频信号几乎实时传输给观众。
更好的互动性： 主播可以通过 WebRTC 实时接收观众的反馈和互动，从而创建更具参与感的直播体验。
简化的部署和配置： WebRTC 提供了浏览器原生支持，无需额外的插件或软件，使主播可以轻松地进行直播。
观众端采用 CDN 拉流的优势包括：

稳定的内容分发： CDN 提供全球范围内的服务器分布，能够缓存和分发媒体流数据，提供高可用性和稳定的内容分发服务。
降低网络负载： CDN 可以将媒体流数据就近分发给观众，减少对主播端或中心服务器的网络负载，提高观众的播放体验。
适应大规模观众： CDN 可以通过负载均衡和缓存机制，有效处理大量观众的请求，并实现扩展和弹性。
因此，在直播中，主播端使用 WebRTC 进行实时采集和传输，而观众端利用 CDN 拉流来接收和播放音视频数据，可以实现较低延迟、高互动性以及稳定的内容分发。

RTMP（Real-Time Messaging Protocol）和 CDN 拉流是两种不同的技术和传输方式，有以下主要区别：

1. 传输协议： RTMP 是一种用于音视频传输的实时消息传输协议。它使用 TCP 协议作为底层传输，提供可靠的数据传输，并支持即时传输和流媒体播放。

CDN 拉流则通常使用 HTTP 协议或类似的传输协议，如 HLS（HTTP Live Streaming）或 DASH（Dynamic Adaptive Streaming over HTTP）。这些协议将媒体流数据分割为小的块，并使用 HTTP 进行分段传输，以适应不同网络条件和设备需求。

2. 实时性和延迟： RTMP 是一种实时传输协议，适用于需要较低延迟和高实时性的场景，如直播、视频聊天等。通过使用 TCP 协议，RTMP 可以提供相对较低的延迟，但可能无法满足极端低延迟的需求。

CDN 拉流通常在延迟方面相对较高。由于音视频数据被切割成小块并使用 HTTP 传输，每个小块的传输时间和缓冲时间会增加总体延迟。

3. 部署和管理： RTMP 需要在服务器端部署 RTMP 服务器，并在客户端使用 RTMP 客户端进行推流和拉流。这需要管理和维护专门的服务器和软件。

CDN 拉流则是以分布在全球各地的 CDN 边缘节点为基础，将媒体流数据缓存和分发给观众。内容提供商只需上传媒体流数据到中心服务器，并配置相应的分发策略，无需管理和维护额外的服务器。

4. 兼容性： RTMP 是一种专有协议，对于某些设备和浏览器可能不具备原生支持，需要使用特定的 RTMP 客户端进行播放。然而，RTMP 在广泛使用的桌面平台上得到良好支持。

CDN 拉流使用标准的 HTTP 协议，几乎所有的设备和浏览器都原生支持 HTTP 播放，因此具有更好的兼容性。

综上所述，RTMP 和 CDN 拉流适用于不同的场景和需求。RTMP 适合实时性较高的场景，如直播、视频聊天等；而 CDN 拉流适合更稳定分发大规模音视频内容的场景，如点播、音视频直播等。

在使用 CDN 进行推流时，您需要按照以下步骤进行设置和配置：

选择CDN提供商： 首先，选择一个可靠的 CDN 提供商，例如 Akamai、Cloudflare、Tencent Cloud 等。根据您的需求和预算，选择最适合您的提供商。

准备推流源： 准备您要推流的音视频源，可以是直播摄像头、录制设备或其他实时音视频源。

获取流密钥或URL： 在 CDN 提供商的管理控制台上，创建一个直播流并获取推流密钥或URL。这将用于将您的音视频数据推送到 CDN 服务器。

配置推流软件或编码器： 使用支持推流功能的软件或硬件编码器（例如 OBS、FFmpeg、XSplit等），配置其推流设置。您需要提供 CDN 的推流密钥或URL，并设置相应的音视频编码参数和传输协议。

开始推流： 打开推流软件或编码器，并点击“开始推流”按钮。该软件将开始将您的音视频源编码并发送到 CDN 服务器。

验证推流： 在 CDN 提供商的管理控制台上，查看推流状态和质量指标，以确保推流正常工作。此外，您还可以使用观众端设备尝试拉取直播流，确认从 CDN 服务器上成功获取到音视频数据。

配置域名和加速： 可以在 CDN 提供商的控制台上配置自定义域名和加速功能。这有助于提高直播的可用性和传输效率，同时增强观众端的访问速度和体验。

请注意，具体的设置和步骤可能会因所选的 CDN 提供商和推流软件而有所不同。建议参考您所选择的 CDN 提供商的文档和支持资源，以获取更详细的配置指南和操作说明。

总结起来，进行 CDN 推流需要选择合适的 CDN 提供商，准备推流源，获取流密钥或URL，配置推流软件或编码器，开始推流，并验证推流的状态。通过这些步骤，您可以使用 CDN 实现高效、稳定的音视频推流服务。

将 WebRTC 推流到 CDN 服务器通常需要经过一些额外的步骤和配置。以下是一个基本的工作流程：

设置 WebRTC 推流服务器： 首先，您需要设置一个 WebRTC 推流服务器，该服务器将接收来自发布者的 WebRTC 流，并将其转发到 CDN 服务器。这可以使用开源解决方案如 mediasoup、Janus、Kurento 等进行实现。

获取 CDN 的推流 URL 或密钥： 在 CDN 提供商的管理控制台上创建直播流，并获取相应的推流 URL 或密钥。这将用于将 WebRTC 流发送到 CDN 服务器。

建立 WebRTC 连接并采集流： 发布者（采集端）使用 WebRTC 技术与推流服务器建立连接，并通过摄像头或屏幕共享等方式，从本地采集音视频流。

将 WebRTC 流发送到推流服务器： 使用 WebRTC 的信令机制，将采集到的音视频流发送到推流服务器。这可以通过将媒体流分割为小块并通过 WebSocket 或其他协议传输到服务器来实现。

在推流服务器上处理流： 推流服务器接收到 WebRTC 流后，可以对音视频进行处理（例如编码、转码等），然后将流数据按照 CDN 的要求封装成特定的格式，准备发送到 CDN 服务器。

将流数据推送到 CDN 服务器： 推流服务器使用 CDN 提供商提供的 API 或工具，将处理后的流数据推送到 CDN 服务器。这可能涉及使用推流 URL、密钥或其他身份验证信息进行身份认证和授权。

配置 CDN 加速和域名设置： 在 CDN 提供商的控制台上配置加速功能和自定义域名等设置，以便观众可以通过 CDN 加速节点访问直播流。

请注意，具体的设置和配置步骤可能会因所选的 WebRTC 推流服务器和 CDN 提供商而有所不同。建议参考您所选择的解决方案的文档和支持资源，以获取更详细的配置指南和操作说明。

总结起来，将 WebRTC 推流到 CDN 服务器需要设置 WebRTC 推流服务器，建立 WebRTC 连接并采集流，在推流服务器上处理流，并将处理后的流数据推送到 CDN 服务器。通过这些步骤，您可以将 WebRTC 流传输到 CDN 并实现高效的直播分发。